暗号通信の事実上の標準ライブラリOpenSSLに、重要度「High（重要）」の脆弱性CVE-2026-45447が公開されました（2026年6月9日公開）。PKCS#7／S/MIME形式の署名付きメッセージを検証する処理でheap use-after-free（解放済みメモリの再利用）が発生し、最悪の場合リモートコード実行（RCE）に至る恐れがあります。OpenSSLは自社開発のアプリだけでなく、サーバOS・各種アプライアンス・メール製品などに広く組み込まれているため、「自社が使っているあの製品は大丈夫か」を一度棚卸しすべき案件です。同日にはこのHighを含む十数件の脆弱性がまとめて公表されており、各系統で更新版が提供されています。
この記事でわかること
- CVE-2026-45447とは何か（どこに、どんな不具合があるのか）
- 影響を受けるバージョンと、影響しない条件
- 情シスが今すぐ確認・判断すべきポイントと、参照すべき公的指針
何が起きたのか
OpenSSL Projectは2026年6月9日、複数の脆弱性を一括で公表しました。その中で唯一「High（重要）」に分類されたのがCVE-2026-45447です。共通脆弱性評価システムのスコアはCVSS 8.8とされています。
不具合があるのは、PKCS#7構造の署名を検証するPKCS7_verify()関数です。PKCS#7とは、署名・暗号化されたデータを表現する暗号メッセージ形式で、S/MIME（メールの署名・暗号化方式）の土台になっている規格です。細工された署名付きメッセージで、署名データ内のdigestAlgorithmsフィールドが空のASN.1 SETとして渡されると、本来は呼び出し側が所有するBIO（入出力オブジェクト）が誤って解放され、その後の参照で解放済みメモリにアクセスしてしまう、という流れです。
この脆弱性は、ある研究者がAI（Anthropic／Claudeとの協働）を活用して発見したと報告されています。発見手法そのものも、今後の脆弱性調査のあり方を考えるうえで興味深いトピックです。
具体的に何が危ないのか？
結論から言えば、ヒープ破壊によるクラッシュ（サービス停止）に加え、条件次第でリモートコード実行につながり得る点が危険です。攻撃者が用意した署名付きメッセージを、OpenSSLのPKCS#7 APIで検証するアプリに処理させることが攻撃の起点になります。たとえばS/MIME署名メールを自動検証する仕組みや、署名付きデータを受け取って検証するサーバ機能などが想定経路です。ただしRCEは「可能性」であり、実際に成立するかはアプリの実装やメモリ配置に依存します。本稿執筆時点で、広範な悪用に関する公開情報は限定的です。
影響を受ける環境と、影響しない条件
どのバージョンが影響を受けるのか？
1.0.2／1.1.1／3.0／3.4／3.5／3.6／4.0と、現在サポートされている主要系統のほぼ全てが影響を受けます。OpenSSL Projectは各系統について更新版を公開済みです。自社の正確な修正バージョンは、後述の公式アドバイザリで利用中の系統を確認してください。
| 区分 | 内容 |
|---|---|
| CVE | CVE-2026-45447 |
| 重要度 | High（重要）／CVSS 8.8 |
| 影響箇所 | PKCS7_verify()（PKCS#7／S/MIME署名検証） |
| 影響系統 | 1.0.2, 1.1.1, 3.0, 3.4, 3.5, 3.6, 4.0 |
| 不具合種別 | heap use-after-free（解放済みメモリの再利用） |
| 想定影響 | クラッシュ／ヒープ破壊／RCEの恐れ |
| 公開日 | 2026年6月9日 |
影響しない条件は？
OpenSSL Projectによれば、PKCS#7 APIではなくCMS API（CMS_verify等）を使って署名検証している場合は本脆弱性の影響を受けません。また、多くのケースでFIPSモジュールは影響範囲外とされています。とはいえ、自社製品やOSが内部でどちらのAPIを使っているかをエンドユーザーが把握するのは困難なため、基本は「使っているOpenSSLを更新版へ上げる」方針で考えるのが現実的です。
このHigh以外に何が公開されたのか？
同日には、QUICのPATH_CHALLENGE処理でメモリを枯渇させられるCVE-2026-34183（Moderate）、CMSのAuthEnvelopedDataで偽造メッセージを受理し得るCVE-2026-34182（Moderate）など、Moderate／Lowの脆弱性も多数まとめて公表されています（公表件数は情報源により十数件と幅があります）。個別の深刻度はHighほどではありませんが、QUIC（HTTP/3等で使う新しいトランスポート）やCMSを使う構成では併せて確認が必要です。
情シス目線での課題
OpenSSLの脆弱性が厄介なのは、「自社のどこで、どのバージョンが動いているか」を正確に把握しきれない点に尽きます。自前のWebサーバやアプリは管理下にあっても、ネットワーク機器・ストレージ・複合機・メールセキュリティ製品・各種SaaSのオンプレ版などに同梱されたOpenSSLまで、現場の限られた人員で一台ずつ追うのは正直なところ容易ではありません。とくにS/MIMEメールを扱う仕組みは、メールゲートウェイやアーカイブ製品など「裏側で静かに署名検証している」ことが多く、影響経路として見落としやすいのが実感です。
こうしたときに頼りになるのが、各ベンダーが出す「自社製品が本CVEの影響を受けるか」の個別アドバイザリです。OSや製品のベンダー情報を待ち、出そろった段階で適用計画に落とし込む——この地道な追跡を、平時から回せる運用に組み込めているかが分かれ目になります。
情シスはどうすべきか
やることはシンプルで、(1) 利用中のOpenSSLと、それを同梱する製品の棚卸し、(2) 公式アドバイザリで自系統の修正版を確認し更新、(3) S/MIME／PKCS#7やQUIC・CMSを使う構成の優先確認、の3点です。優先度は「外部からの入力（メール・通信）を署名検証している箇所」を高くするのが妥当でしょう。
個別の対策チェックリストを長々と自作するより、まずは一次情報と公的指針にあたるのが近道です。脆弱性対応の体制づくりや、経営層・他部署への説明材料としては、IPA（情報処理推進機構）の資料が役立ちます。
- OpenSSL公式 脆弱性情報（修正版・影響条件の一次情報）: https://openssl-library.org/news/vulnerabilities/
- JPCERT/CC（国内向けの注意喚起・関連製品情報）: https://www.jpcert.or.jp/
- IPA 中小企業の情報セキュリティ対策ガイドライン（脆弱性対応・運用体制の参考に）: https://www.ipa.go.jp/security/guide/sme/index.html
あわせて、署名付きメールを安易に「署名があるから安全」と扱わないよう、利用部門への地道な注意喚起・啓発も継続したいところです。攻撃は正規の処理経路を逆手に取るため、技術的対策と利用者教育の両輪が効いてきます。
まとめ
- CVE-2026-45447はHigh（CVSS 8.8）。PKCS#7／S/MIME署名検証のheap use-after-freeで、RCEの恐れがある（2026年6月9日公開）。
- 主要系統（1.0.2〜4.0）がほぼ影響。CMS APIのみ利用なら影響外だが、把握が難しいため「更新版へ上げる」を基本方針に。
- まずはOpenSSL公式アドバイザリで自系統の修正版を確認し、同梱製品のベンダー情報を追って計画的に適用する。
出典
- OpenSSL Library「Vulnerabilities」: https://openssl-library.org/news/vulnerabilities/
- NVD「CVE-2026-45447 Detail」: https://nvd.nist.gov/vuln/detail/CVE-2026-45447
コメント