OpenSSL Projectが2026年6月9日、18件の脆弱性を一括で公表しました。
最も深刻なのはCVE-2026-45447（深刻度High、CVSS v3.1で9.8）で、PKCS#7／S/MIME署名の検証処理に潜むUse-After-Free（解放済みメモリの使用）です。アプリケーションの実装次第ではクラッシュやメモリ破壊にとどまらず、リモートコード実行（RCE）に至る恐れがあります。OpenSSLは暗号通信のほぼあらゆる場所で使われる土台であり、自社のサーバ・製品・組み込み機器に広く影響しうるため、影響有無の棚卸しを早めに始めたいところです。
この記事でわかること
- 今回の18件のうち、情シスがまず注目すべき脆弱性はどれか
- 最も深刻なCVE-2026-45447の中身と「自社が影響を受ける条件」
- 影響を受けるバージョンと修正版の対応表
- サポート終了（EOL）系列を使っている場合の現実的な選択肢
- 現場目線での棚卸しの進め方と、参照すべき公的指針
何が起きたのか
OpenSSLは、Webサーバ・メールサーバ・VPN・各種ネットワーク機器・社内開発アプリなど、TLS通信や暗号処理を行う製品の内部で広く利用されているオープンソースの暗号ライブラリです。今回のアドバイザリ「OpenSSL Security Advisory [9th June 2026]」では、深刻度Highが1件、Moderateが5件、Lowが12件の計18件が公表されました。
注目すべきは、最も深刻なCVE-2026-45447がAIを活用した脆弱性調査で発見された点です。OpenSSLの公式発表およびSecurityWeek等の報道によれば、本脆弱性はある研究者がAI（Anthropicの研究）と協働して見つけたとされています。攻撃側だけでなく防御・発見の側でもAIの活用が現実になりつつある、という象徴的な事例と言えます。
最も深刻なCVE-2026-45447とは
CVE-2026-45447とは、PKCS#7／S/MIME署名メッセージの検証時に、呼び出し側が所有するBIOを誤って解放してしまい、その後の利用でUse-After-Freeを引き起こす脆弱性です。具体的には、SignedDataの digestAlgorithms フィールドが空のASN.1 SETとして渡された場合に、PKCS7_verify() の処理内でメモリの二重解放に近い不正状態が発生します。
影響の度合いはメモリアロケータの挙動やアプリケーション側のBIOの使い方に依存し、クラッシュで済む場合もあれば、文脈によってはリモートコード実行に悪用されうるとされています。CVSSは9.8と極めて高く、外部から渡された署名付きメッセージを検証する処理を持つシステムでは特に警戒が必要です。
自社が影響を受ける条件は？
ポイントを絞ると、影響を受けるのは次のような実装です。
- OpenSSLのPKCS#7 API（PKCS7_verify等）を使って署名付きメッセージを検証しているアプリケーション。
- 外部から渡される（攻撃者が細工できる）PKCS#7／S/MIMEメッセージを処理する経路があること。
一方で、OpenSSLの公式情報によればCMS APIを使って同等の処理を行っている場合は影響を受けません。また、4.0／3.6／3.5／3.4／3.0のFIPSモジュールは、該当コードがFIPSモジュール境界の外側にあるため影響を受けないとされています。自社製品やSaaSがどのAPI経路で署名検証しているかを開発元・ベンダーに確認することが、影響判定の近道です。
影響を受けるバージョンと修正版
主要な脆弱性の影響バージョンと、アップグレード先の対応表です。まずは自社が使っている系列を確認してください。
| 利用中の系列 | 修正版 | 備考 |
|---|---|---|
| 4.0.x | 4.0.1 | — |
| 3.6.x | 3.6.3 | — |
| 3.5.x（LTS） | 3.5.7 | 2030-04-08までサポート |
| 3.4.x | 3.4.6 | — |
| 3.0.x（LTS） | 3.0.21 | 2026-09-07でサポート終了予定 |
| 1.1.1.x | 1.1.1zh | EOL。商用の拡張サポート契約者のみ入手可 |
| 1.0.2.x | 1.0.2zq | EOL。商用の拡張サポート契約者のみ入手可 |
最優先はCVE-2026-45447（High）の修正適用です。なお最も深刻なこの脆弱性は、1.0.2／1.1.1も含む7系列という広い範囲に影響します。
Moderate以下も「軽視できない」ものがある
残る17件はModerate／Lowですが、自社環境によっては効いてきます。代表例を挙げます。
- CVE-2026-34183（Moderate）：QUICサーバがPATH_CHALLENGEフレームの大量送信でメモリを際限なく消費し、サービス妨害（DoS）に至る。QUIC/HTTP3を有効化している場合は要注意。
- CVE-2026-35188（Moderate）：悪意あるTLSサーバがOCSPステープリングを悪用し、クライアント側の証明書検証でDouble-Freeを誘発。クライアント実装にも影響しうる点に注意。
- CVE-2026-45445（Moderate）：AES-OCBがEVP_Cipher経由でIVを無視し、(鍵, ノンス)の再利用による機密性低下を招く。
- CVE-2026-42764（Moderate）：検証を無効化したQUICサーバが不正トークンでNULLポインタ参照によりクラッシュ。
「Lowだから後回し」と一括りにせず、QUICを使っているか、署名・暗号メッセージ（CMS/PKCS#12/CMP）を扱うか、といった自社の利用形態に照らして優先度を判断するのが実務的です。
サポート終了（EOL）系列を使っている場合
頭が痛いのが1.1.1／1.0.2です。これらはすでにサポート終了済みで、今回の修正版（1.1.1zh／1.0.2zq）は基本的に商用の拡張サポート契約者しか入手できません。さらに3.0系も2026年9月7日でサポート終了が予定されており、いま3.0.21に上げても“延命”の意味合いが強い状況です。
現場の本音として、古いOpenSSLは「アプリに静的リンクされている」「ベンダー製アプライアンスの内部に埋まっていて自分では更新できない」といった形で、棚卸しすら難しいことが少なくありません。だからこそ、この機会にサポート系列（3.5 LTSや4.0など）への移行計画をロードマップに載せておくことが、中長期のコスト削減につながります。
現場目線の課題と、情シスはどうすべきか
OpenSSLの脆弱性は「どこで使われているか分からない」ことが最大の壁です。自社サーバのパッケージ版だけでなく、開発アプリが同梱するライブラリ、ネットワーク機器やIoT機器のファームウェア内部にまで広がっており、限られた人員ですべての端末・機器の細部まで目を届かせるのは容易ではありません。率直に言って、SBOM（ソフトウェア部品表）の整備が進んでいない組織では、影響範囲の特定そのものが一仕事です。
まずやるべきことを順に整理すると、次のとおりです。
- 棚卸し：OSのパッケージ管理（
openssl version等）、製品ベンダーへの問い合わせ、SBOMの確認で、利用中のOpenSSLバージョンを洗い出す。 - 切り分け：PKCS#7署名検証やQUICなど、深刻な脆弱性の“発動条件”に自社が当てはまるかを確認する。
- 適用：High（CVE-2026-45447）を最優先に、OSベンダーの提供する更新パッケージを適用する。自前ビルドしている場合は修正版へ。
- 恒久対策：EOL系列の利用を可視化し、サポート系列への移行とSBOM運用を計画に落とし込む。
具体的な対策手順や脆弱性管理の進め方は、自前でチェックリストを抱え込むより、公的機関の体系立った指針を起点にするのが効率的です。脆弱性対応の基本姿勢はIPA「脆弱性対策」、中小規模での進め方はIPA「中小企業の情報セキュリティ対策ガイドライン」が参考になります。あわせて、利用者・運用担当への地道な啓発も忘れずに（IPA「対策のしおり」）。
まとめ
- OpenSSLが2026年6月9日に18件の脆弱性を公表。最優先はCVE-2026-45447（High／CVSS 9.8）で、PKCS#7／S/MIME署名検証のUse-After-FreeによりRCEの恐れがある。
- 影響条件は「PKCS#7 APIで外部の署名メッセージを検証している」こと。CMS API利用やFIPSモジュールは対象外。まずは自社の利用形態を切り分けて優先度を判断する。
- 1.1.1／1.0.2はEOLで修正版は商用契約者のみ、3.0も2026年9月にサポート終了予定。この機会にサポート系列への移行とSBOM整備を計画化したい。
コメント