TITLE

OpenSSLに11件の脆弱性、2026年8月アドバイザリの要点と対応の優先順位

投稿日：2026.08.27

OpenSSLアドバイザリの全体像 — 2026年8月25日公開

今回のアドバイザリで OpenSSL は 4.0.2 / 3.6.4 / 3.5.8 / 3.4.7 / 3.0.22 をリリースし、premium support 向けに 1.1.1zi / 1.0.2zr も提供しています。新規9件の内訳は Moderate が3件、Low が6件です。9件に加えて、先行して公開されていた2件を含め計11件に対処した形になります(先行公開分の CVE 番号・詳細は未確認のため、本記事では踏み込みません)。

9件の中で唯一「二重解放」というメモリ破損の欠陥(CWE-415)を持つのが、次に説明する CVE-2026-18798 です。cybersecuritynews.com・cyberpress.org・gbhackers.com など海外セキュリティメディア各紙も同日付でこの点を最も注目度が高い問題として報じています。

QUICの二重解放が最優先(CVE-2026-18798)

QUIC サーバーが初期パケットの処理中にチャネル作成に失敗すると、QUIC record layer(QRX)オブジェクトを二重に解放してしまう問題です(CWE-415)。同じメモリ領域を二重に解放する処理は、そこに割り当てられるはずの別データを巻き込んでヒープを破損させ、サービス停止や予期しない動作につながります。倉庫から一度運び出した荷物を、記録が残ったままもう一度運び出してしまい、棚の在庫データが狂うようなものだとイメージすると分かりやすいかもしれません。

対象は 4.0 系 / 3.6 系 / 3.5 系で、修正版は 4.0.2 / 3.6.4 / 3.5.8 です。QUIC サーバー機能を有効にして OpenSSL を使っている場合は、今回のアドバイザリの中で最優先で確認すべき項目になります。

倉庫から同じ木箱を二度運び出してしまい、棚に空欄ができるイメージ図。OpenSSLのQUIC二重解放(CVE-2026-18798)の比喩

残り8件の内訳 — Moderate 2件とLow 6件

CVE-2026-18798 以外の8件は、次のように機能領域ごとに分かれています。

CVE	深刻度	対象機能	内容
CVE-2026-63072	Moderate	CMS(暗号化メッセージ)	AES-WRAP-PAD のアンラップ処理でヒープ領域外に最大8バイト書き込み・消去(CWE-787)
CVE-2026-63076	Moderate	CMP(証明書管理プロトコル)	protectionAlg の型チェック不足による不正ポインタ参照。未認証でリモートから DoS 可能(CWE-476)
CVE-2026-14457	Low	Raw Public Keys(RFC7250)	証明書なし・秘密鍵のみの構成で NULL ポインタ参照(CWE-476)
CVE-2026-54874	Low	DTLS	読み取りバッファ全体を保持し最大約1.7MBを消費、増幅係数は約1200倍(CWE-405)
CVE-2026-63073	Low	CMP	送信者の識別名を検証せずフォーマット文字列として使用(CWE-134)
CVE-2026-63074	Low	CMP	extraCerts キャッシュが無制限に成長(CWE-770)
CVE-2026-63075	Low	QUIC	ACK のみのパケットのメタデータが接続中ずっと保持されメモリ増大(CWE-770)
CVE-2026-75803	Low	ChaCha20-Poly1305 / AES-OCB	次の見出しで説明

いずれも対象バージョンは 4.0 系を中心に 3.6 / 3.5 / 3.4 系まで及び、一部(CVE-2026-54874・63072・63074・63076・75803)は 3.0 系にも影響します。修正版は先述の 4.0.2 / 3.6.4 / 3.5.8 / 3.4.7 / 3.0.22 に含まれています。

見落としやすい認証迂回のCVE(CVE-2026-75803)

CVE-2026-75803 は深刻度こそ Low ですが、性質が他の8件と異なります。ChaCha20-Poly1305 と AES-OCB という暗号方式で、暗号文が空の場合に認証タグの検証をスキップしてそのまま成功を返してしまう問題です(CWE-354)。認証付き暗号は「復号できた内容が改ざんされていないこと」を認証タグで保証する仕組みですが、この条件下ではその保証が働きません。サービス停止に直結する他の問題と違い、この脆弱性は改ざんされたメッセージを受理してしまう可能性がある点で、影響の種類そのものが異なります。対象は 4.0 / 3.6 / 3.5 / 3.4 / 3.0 系で、修正版は 4.0.2 / 3.6.4 / 3.5.8 / 3.4.7 / 3.0.22 です。

対応の優先順位をどう決めるか

9件のうち自社に関係するのはどれかを絞り込む軸は、まず「対象機能を実際に使っているか」です。その上で、同じ機能に複数の CVE が該当する場合は深刻度で順位をつけます。私たちは、運用しているサイトの WordPress プラグイン・コアに脆弱性情報が出るたびに、バージョンの遅れと該当する脆弱性情報を照合し、サイトの運用状況を踏まえて優先順位をつけて更新する運用をしています。今回の OpenSSL のように影響が機能ごとにはっきり分かれているアドバイザリでは、対象機能の絞り込みという同じ考え方がそのまま活きます。

OpenSSL脆弱性への対応優先度を3段で示した図。QUICの二重解放CVE-2026-18798が最優先、CMS/CMPのModerate2件が次点、残りのLow6件は通常のアップデートサイクル

今日から確認できることは3つです。

バージョンを確認する: openssl version で稼働中のバージョンを調べ、4.0.2 / 3.6.4 / 3.5.8 / 3.4.7 / 3.0.22 のいずれかより古いかを確認します。
利用機能を棚卸しする: QUIC サーバー機能(HTTP/3 対応など)・CMP によるクライアント証明書管理・CMS 暗号化メッセージ・DTLS を使う通信機能・Raw Public Keys・ChaCha20-Poly1305 や AES-OCB での暗号化、のうちどれを自社のサーバー構成・アプリケーションで実際に使っているかをチェックします。
優先順位をつけて更新する: QUIC サーバーを運用しているなら CVE-2026-18798 を含む更新を最優先に、該当機能を使っていない場合でも通常のアップデートサイクルで反映します。

まとめ

今回の3ステップ(バージョン確認・機能棚卸し・優先順位づけ)を一度やっておくと、次にアドバイザリが出たときは棚卸しの結果を更新するだけで数分で判断できるようになります。今回の OpenSSL のケースでは、最も深刻な CVE-2026-18798 でも QUIC サーバー機能を使っていなければ緊急度は下がり、逆に Low とされた CVE-2026-75803 も認証の保証が絡む分、暗号方式の使い方次第では軽視できません。件数の多さに身構えるより先に、自社の構成と照らし合わせることが、対応の優先順位を正しく決める最短経路です。