STOP Inc.
サーバ監視運用事業

「OpenSSLに9件の脆弱性」──見出しほど怖くない話と、それでもやるべき対策

#OpenSSL #インフラセキュリティ #サーバ監視 #セキュリティ #セキュリティ運用

2026年8月25日、暗号ライブラリ「OpenSSL」のプロジェクトは、4.0.2／3.6.4／3.5.8／3.4.7／3.0.22という5つの修正バージョンを一斉に公開しました。今回まとめて直されたのは9件の脆弱性です。

「二重解放」「ヒープ破壊」といった単語が並ぶと身構えてしまいますが、結論から言うと、今回の9件に緊急（Critical）や重要（High）に区分されるものはありません。最も高いランクでも「中程度（Moderate）」で、悪用が報告されているものもありません。とはいえOpenSSLはWebサーバーからスマホアプリ、IoT機器まであらゆるところで使われている基盤ソフトなので、「大した話じゃない」と読み飛ばしてよいものでもありません。中身を整理してみます。

そもそも何が起きたのか

OpenSSLは、通信の暗号化（TLS）や電子署名、証明書関連の処理を担う、世界で最も広く使われているオープンソースの暗号ライブラリです。開発チームは定期的にセキュリティレビューを行っており、今回はその過程で見つかった9件の不具合をまとめて修正し、影響を受ける各バージョン系統向けに一斉リリースしました。これは新しい種類の攻撃が発生したというより、通常の脆弱性対応プロセスが動いた、というのが実態に近い出来事です。

深刻度の内訳：「中程度」が3件、「低」が6件

公式のセキュリティアドバイザリによる深刻度の内訳は次の通りです。

  • Moderate（中程度）：3件
  • Low（低）：6件
  • Critical／Highはゼロ

「二重解放」「ヒープ破壊」という言葉自体は物騒に聞こえますが、いずれも大半は特定の機能（QUICサーバー、CMSでのメッセージ復号、証明書管理プロトコルなど）を使っている場合に限って影響が出るもので、OpenSSLを使ったソフトウェア全てが即座に危険にさらされるわけではありません。

9件の内訳

QUIC関連（QUICサーバーとして動かしている場合のみ影響）

  • CVE-2026-18798（Moderate）：QUICの初期パケットを処理する際、内部オブジェクトが二重に解放（double free）される可能性がある不具合。ヒープ破壊につながり、悪用されるとサーバープロセスがクラッシュ（サービス停止）する恐れがあります。今回の記事見出しにもなっている一件です。
  • CVE-2026-63075（Low）：QUICのACK専用パケットを必要以上に保持し続けることで、メモリを消費し続けてしまう不具合。

CMS関連（S/MIMEなどメッセージの暗号化・復号）

  • CVE-2026-63072（Moderate）：CMS（Cryptographic Message Syntax）の鍵アンラップ処理で、8バイト分がヒープ領域外に書き込まれる不具合。細工されたメッセージをCMS_decrypt()などで復号する際にヒープ破壊が起こり得ます。今回の9件の中では実害の想定がしやすく、注意したい一件です。

CMP関連（証明書管理プロトコル）

  • CVE-2026-63076（Moderate）：CMPサーバーが応答の保護アルゴリズム（protectionAlg）を検証する際に、不正なポインタを参照してしまう不具合。認証前の処理で起こるため、未認証の遠隔攻撃者がサーバーをクラッシュさせられる可能性があります。
  • CVE-2026-63073（Low）：CMP応答の検証処理にある書式文字列がらみの問題。
  • CVE-2026-63074（Low）：CMPで受け取った追加証明書をキャッシュする際、上限なく増え続けてしまう可能性（メモリリーク）。

そのほか

  • CVE-2026-14457（Low）：Raw Public Key（RPK）を使う構成で、サーバー側の署名アルゴリズム選択時にNULLポインタを参照してしまう不具合。
  • CVE-2026-54874（Low）：DTLS（UDP上のTLS。VPNやIoT機器などで利用）で、将来のエポックに属するレコードをバッファする処理が、メモリを過剰に使ってしまう不具合。
  • CVE-2026-75803（Low）：ChaCha20-Poly1305やAES-OCBで、空の暗号文を復号する際に本来行うべき認証タグの検証をスキップしてしまう可能性がある不具合。

自社に関係あるか、まず確認したいポイント

影響の有無は「OpenSSLを使っているかどうか」ではなく「どの機能を使っているか」で変わります。次のような使い方に心当たりがあれば優先度を上げて確認する価値があります。

  • 自社のサービスやサーバーで、どのバージョンのOpenSSLを使っているか棚卸しできているか（OS標準パッケージ、コンテナイメージ、アプリの依存ライブラリを含む）
  • HTTP/3などQUICをサーバー側で提供しているか
  • S/MIME等、CMS形式で暗号化されたメッセージを自社システムで復号しているか
  • 社内外の証明書発行・更新にCMP（Certificate Management Protocol）を使っているか
  • TLSでRaw Public Keyを使う構成をとっているか
  • DTLSを使う機器・サービス（VPN、IoT機器など）を運用しているか
  • OpenSSL 1.1.1系・1.0.2系（レガシー版）や3.1〜3.3系（サポート終了済み）をまだ使っていないか

対策：やるべきことはシンプル

  1. 使用バージョンの棚卸し：自社のサーバーやアプリケーションが依存しているOpenSSLのバージョンを洗い出します。
  2. 該当バージョンへのアップデート：使用中の系統に応じて、4.0系は4.0.2、3.6系は3.6.4、3.5系は3.5.8、3.4系は3.4.7、3.0系（LTS）は3.0.22へアップデートします。
  3. サポート終了ブランチからの移行：3.1〜3.3系はすでにサポートが終了しているため、この機会にサポート対象のバージョンへ移行を検討します。
  4. レガシー版を使っている場合の確認：1.1.1系・1.0.2系は、プレミアムサポート契約者向けにのみ修正版（1.1.1zi、1.0.2zr）が提供されています。契約状況の確認、または移行の検討が必要です。
  5. 継続的なウォッチ体制：OpenSSLに限らず、主要なOSSコンポーネントのセキュリティアドバイザリを継続的に追える体制（メーリングリストやCVEフィードの購読など）を整えておくと、次回以降の対応が速くなります。

まとめ：ショッキングというより「いつもの宿題」

見出しの「二重解放」「ヒープ破壊」という言葉のインパクトに反して、今回の9件はCritical・Highに該当するものがなく、悪用が確認されているものもありません。過度に恐れる必要はなさそうです。

一方で、OpenSSLはインターネットのあらゆる場所で使われている基盤ソフトウェアです。「深刻度が低いから後回し」にしてしまうと、気づかないうちに古いバージョンが社内のあちこちに残ってしまいがちです。今回のような一斉リリースのタイミングは、自社のOpenSSL利用状況を棚卸しし、パッチ適用の仕組みそのものを見直すよい機会と捉えるのがよさそうです。

本記事は2026年8月25日付のOpenSSLプロジェクトによるセキュリティアドバイザリ、および2026年8月26日配信の報道をもとに、一般向けに整理したものです。CVE番号・深刻度・対象バージョンなどの詳細は変更される可能性があるため、実際の対応にあたっては必ず一次情報（OpenSSL公式のセキュリティアドバイザリ）をご確認ください。

関連記事