OpenSSLは、AISLEの研究者が特定した新たな一連の脆弱性にパッチを適用し、緊急のセキュリティアップデートを公開した。
このうち1件は重大度が高く、信頼できない暗号化データを処理するアプリケーションで、リモートの攻撃者が悪意のあるコードを実行できる可能性がある。
大半の問題はサービス拒否状態につながるものだが、最も深刻なバグは、広く信頼されているセキュリティライブラリでさえ、コードの奥深くに危険な欠陥を潜ませる可能性があることを浮き彫りにしている。
「主要なOpenSSLリリースで、真に新規のCVEを100％捕捉することは、歴史的に前例がありません。サイバー防御で可能なことの新たなベンチマークを事実上打ち立てるものです」と、AISLEの共同創業者兼主任科学者であるStanislav Fort氏は、eSecurityPlanetへのメールで述べた。
同氏はさらに、「場合によっては1990年代から検出されないまま潜んでいた脆弱性を発見することで、数十年にわたって存在してきた技術的負債を体系的に解消しています。AI主導の防御の時代は、疑いなく到来しています」と述べた。
OpenSSLの解析に潜む体系的なリスク
OpenSSLは世界のデジタルインフラを支える基盤コンポーネントであり、Webサーバー、VPN、メールプラットフォーム、証明書管理システムをはじめ、数え切れないほどのアプリケーションに暗号機能を提供している。
OpenSSLはソフトウェアスタックの深部に組み込まれているため、その解析ロジックの脆弱性は連鎖的な影響を及ぼし、下流のシステムをクラッシュやサービス拒否状態、リモートコード実行（RCE）にさらす可能性がある。
2026年1月のOpenSSLセキュリティリリースは、3.6から1.0.2までのOpenSSLバージョンに影響する。つまり、最新の環境とレガシーシステムの双方が影響を受ける可能性がある。
脆弱性の多くは、CMS、PKCS#7、PKCS#12、タイムスタンプ応答、さまざまなTLS拡張など、信頼できない暗号化データ形式をOpenSSLが解析する方法に起因している。
一部の脆弱性は、細工した入力を用いなければ発動しないが、複雑な解析ロジックや、ほとんど実行されないコードパスが、成熟し入念に監査されたライブラリでさえ危険なエッジケースを依然として潜ませる可能性を示している。
OpenSSLの主な脆弱性を解説
CVE-2025-15467は、特定の条件下でリモートコード実行を可能にする恐れがあるため、OpenSSLによって重大度「高」と評価された。
この脆弱性は、AES-GCMなどのAEAD暗号が使用されている場合のCMS AuthEnvelopedDataの解析に影響する。
ASN.1パラメーター内に過大な初期化ベクトルを供給すると、攻撃者は暗号認証のチェックが実行される前に発生する、スタックベースのバッファーオーバーフローを引き起こせる。
つまり、悪用に暗号鍵の保有や有効な認証情報は必要ない。
信頼できないCMSまたはPKCS#7コンテンツを解析するアプリケーション、たとえばS/MIME対応のメールサービスや、署名付きメッセージまたは暗号化メッセージを処理するシステムは、影響を受ける可能性がある。
アドレス空間配置のランダム化（ASLR）やスタック保護など、プラットフォームレベルの防御によって異なるが、悪用に成功するとアプリケーションのクラッシュや任意コード実行につながる可能性がある。
もう1件の注目すべき脆弱性であるCVE-2025-11187は、PKCS#12ファイルの処理中に行われるPBMAC1の検証に影響する。
この場合、鍵導出時の境界チェックが欠落しているため、細工されたファイルで過度に大きな鍵長が指定されると、攻撃者はスタックオーバーフローやNULLポインター逆参照を引き起こせる。
悪用には通常、ユーザーが提供するファイルが必要だが、外部の証明書、鍵バンドル、またはID情報をインポートする環境では、意味のあるリスクとなる。
発見された残りのCVEは重大度が低く、PKCS#12処理、QUIC暗号検索、TLS 1.3の証明書圧縮、BIOの行バッファリングに影響する、境界外書き込み、型混同バグ、NULL参照、サービス拒否状態などが含まれる。
OpenSSLは、脆弱なコードパスが検証済みの暗号境界の外側にあるため、FIPSモジュールには影響しないと強調している。
12件すべての脆弱性はAISLEによって発見された。同社の自律分析システムは、複数のOpenSSLサブシステムにまたがって欠陥を特定しており、その一部は数十年にわたり残存していた。
これは、微妙なロジックエラーや、ほとんど発生しないエッジケースが、広範な手動レビューさえすり抜ける可能性を浮き彫りにしている。
OpenSSLは、問題の大半には細工した入力と特定の構成が必要だと指摘しているものの、重大度の高い脆弱性については概念実証（PoC）エクスプロイトが存在する。
OpenSSLの脆弱性によるリスクを低減する
アップグレード、露出の低減、ランタイム保護を組み合わせた多層的なアプローチが、悪用可能性と影響の双方を抑えるうえで重要となる。
- 影響を受けるすべてのOpenSSLデプロイメントを直ちにアップグレードしてパッチ適用済みバージョンに移行し、脆弱なビルドが使用されていないことを確認する。
- システムパッケージのアップデートでカバーされない可能性がある、組み込みまたは静的リンクされたOpenSSLライブラリを特定し、修正する。
- 信頼できないCMS、PKCS#7、PKCS#12、タイムスタンプデータの不要な解析を制限または無効化して、露出を低減する。
- 暗号化データがOpenSSLのパーサーに到達する前に、厳格な入力検証、ファイルサイズ制限、境界チェックを徹底する。
- 暗号解析コンポーネントを、サンドボックス化された、または最小権限の環境に分離し、悪用による影響を抑える。
- 監視アプリケーションの異常なクラッシュ、メモリ障害、または悪用の試みを示す可能性がある解析エラーの繰り返しを監視する。
- インシデント対応計画を定期的にテストし、更新して、暗号ライブラリの脆弱性にチームが効果的に対応できるようにする。
これらの対策を組み合わせることで、組織はリスクを低減し、全体的なレジリエンスを強化できる。
広く使われる暗号ライブラリに潜むリスク
OpenSSLの脆弱性を総合すると、広く利用されている暗号コンポーネントでは、エッジケースの欠陥が長期間検出されないまま残存すると、リスクが生じ得ることが分かる。
今回の発見は、定期的な監査だけに依存するのではなく、セキュリティ上重要なライブラリを継続的にテストし、検証することの重要性を改めて示している。
暗号ワークフローが複雑化する中、組織はタイムリーなパッチ適用、信頼できない入力の厳格な取り扱い、異常な挙動の早期検知を優先すべきだ。
こうした課題はゼロトラストの原則に沿っている。ゼロトラストの原則では、いかなるコンポーネントや入力も本質的に信頼できるとは見なさず、ソフトウェアスタック全体で継続的な検証を求める。