OpenSSLのOCSP脆弱性、影響は3.6と4.0のみ

【更新 2026-08-09】本記事を見直し、修正しました。主な修正点：(1) メモリリークの発生箇所を、修正コミット（OpenSSL git d8c5104）の記載に合わせ、証明書検証側の check_cert_ocsp_resp() における早期リターンである旨に訂正。(2) JVNVU#92139835 はJPCERT/CCの「注意喚起」一覧には掲載されていないため、参照先の記述をJVNに訂正。

OpenSSL Projectが2026年8月5日、セキュリティアドバイザリを公開し、CVE-2026-54876（クライアント側のメモリリーク）を明らかにしました。JPCERT/CCも8月7日にJVNVU#92139835として注意喚起しています。

結論を先に書きます。影響を受けるのは OpenSSL 4.0.0〜4.0.1 と 3.6.0〜3.6.3 だけで、3.5系以前（3.5・3.4・3.0・1.1.1・1.0.2）は該当しません。さらに、原因となるOCSPレスポンス検証機能は既定では無効で、明示的に有効化したクライアントアプリケーションだけが対象です。多くの組織は「非該当」で終わります。

この記事でわかること

• CVE-2026-54876の中身と、自社が該当するかを2段階で判定する手順
• OpenSSL公式が「Low」としているのに、NVD上で「7.5 HIGH」と表示される理由
• 修正版（4.0.2 / 3.6.4）が執筆時点で未公開であること、その間に何をすべきか
• OpenSSL 3.6の新機能で3か月に3件の脆弱性が出ている事実と、その読み方

何が起きたのか

悪意あるTLSサーバーが、1件も応答エントリを含まないOCSPレスポンス（空のSEQUENCE OF SingleResponse）を返すと、それを検証するクライアント側でメモリが解放されずに残ります。アドバイザリは「攻撃者が調整可能な量のメモリを、TLSハンドシェイク1回ごとに被害クライアントからリークさせられる」と説明しています。

技術的には、証明書検証側の関数（check_cert_ocsp_resp()）が OCSP_response_get1_basic() で確保した構造体を保持したまま、応答エントリが空のときに早期リターンしてしまい、末尾に置かれた解放処理を飛ばすというものです。攻撃者はレスポンス内の証明書フィールドにダミーの証明書を詰め込むことで、1回あたりのリーク量を増幅できます。ハンドシェイクを繰り返させればメモリ枯渇（DoS）に至る、という筋書きです。

自社は影響を受けるのか（判定は2段階）

バージョンだけでは判定できません。「該当バージョンを使っている」かつ「OCSPレスポンス検証フラグを明示的に有効化している」の両方が揃ったときだけ影響を受けます。

段階1：OpenSSLのバージョンを確認する

対象は 4.0.0〜4.0.1 と 3.6.0〜3.6.3 に限られます。OpenSSL 4.0.0のリリースは2026年4月14日、3.6系も比較的新しい系列です。安定志向でバージョンを据え置いている環境ほど、そもそも該当しません。

注意したいのは、確認対象がOSのパッケージだけではないことです。

• OS標準パッケージ（openssl version で確認）
• アプリケーションやランタイムが同梱するOpenSSL（Node.js、Python、各種エージェント、商用ミドルウェアなど）
• コンテナイメージ内のOpenSSL。ベースイメージが新しいディストリビューションだと、ホストより先に新系列に上がっていることがあります

段階2：OCSPレスポンス検証を有効にしているか

この機能は既定で無効です。アドバイザリは、X509_V_FLAG_OCSP_RESP_CHECK または X509_V_FLAG_OCSP_RESP_CHECK_ALL という証明書検証フラグを明示的に立てたクライアントアプリケーションだけが影響を受ける、と明記しています。典型的には、TLSハンドシェイク時にサーバーがステープリングしたOCSPレスポンスをクライアント側で検証する構成です。

つまり、この脆弱性の被害者はサーバーではなくクライアントです。「サーバーを直せ」という普段の脆弱性対応とは向きが逆になります。自社から外部サービスへTLS接続しにいく処理（APIクライアント、バッチ、監視エージェント、プロキシ）のうち、証明書失効確認を厳格に行うよう作り込んだものがあれば、そこが該当候補です。自社開発アプリなら開発チームに、パッケージ製品ならベンダーに、OCSP検証フラグの利用有無を確認するのが確実です。

なぜ「Low」なのにNVDでは7.5 HIGHと出るのか

評価者が違うからです。OpenSSL公式は自ら Low と評価していますが、NVDのページには別のスコアが並びます。

CISA-ADPのベクタは「ネットワーク経由・攻撃条件が低い・権限も利用者操作も不要・可用性への影響が高い」と読めます。メモリ枯渇によるDoSという結果だけを見れば理屈は通りますが、「既定で無効な機能を明示的に有効化した場合に限る」という前提条件がスコアに反映されていません。

ここが実務上いちばん厄介な点です。「CVSS 7.0以上は緊急対応」といったスコア駆動のトリアージを運用していると、この案件は自動的に緊急として鳴ります。しかし実際には、大半の組織で該当ゼロです。逆に、スコアだけを見て一律に緊急扱いすると、本当に急ぐべき案件に人員を割けなくなります。

スコアではなく、①成立条件を自社が満たすか ②影響を受ける資産の重要度、の2点で判断してください。今回はこの判断がしやすい部類の脆弱性です。成立条件が「フラグを立てているか」という一点に絞られているので、開発・運用に問い合わせれば白黒がつきます。

修正版はまだ出ていない

アドバイザリは「4.0.2 / 3.6.4 がリリースされ次第アップグレードすること」と書いています。裏を返すと、公表時点で修正版は出ていません。執筆時点（2026年8月9日）でも、公開されている最新リリースは2026年6月9日の 4.0.1 / 3.6.3 のままです。修正そのものはgitコミット（4.0系は d8c5104、3.6系は 155b5fe）として公開されています。

したがって、現時点で取れる手は「待つ」ことではありません。

• 段階1・段階2の該当判定を先に済ませる。非該当と分かれば、それ以上の作業は不要です
• 該当する場合は、修正版が出るまでの間、OCSPレスポンス検証フラグを一時的に外すかを検討する。ただし失効確認を弱めるトレードオフがあるため、CRLなど代替の失効確認手段と併せて判断してください
• ディストリビューションを利用している場合は、上流の修正がバックポートされるため、ベンダーのセキュリティ情報を追う

3か月で3件目——新機能をどう扱うか

今回いちばん見落とされやすい事実がこれです。OpenSSL 3.6で入ったOCSPレスポンス検証まわりでは、3か月のうちに3件の脆弱性が公表されています。いずれも3.6系と4.0系だけに影響し、それ以前のバージョンは「当該機能が存在しないため影響なし」です。

個々は Low / Moderate ですが、並べると「新しく入った機能が、まだ枯れていない」という傾向が見えます。1件ずつのアドバイザリを追っているだけでは気づけない情報です。

ここから引き出せる実務的な示唆は2つあります。ひとつは、新機能を有効化する判断は、機能の価値と「初期の不安定さを引き受けるコスト」を天秤にかけるべきだということ。もうひとつは、最新バージョンへの追随が常に安全側とは限らないということです。今回は3.0系や3.5系を使い続けている環境が、結果として非該当になりました。もちろん古いまま放置してよいという意味ではありません（サポート期限切れは別のリスクです）。ただ「新しい＝安全」という単純な図式は成り立たない、という一例です。

現場目線の課題

この種の案件で本当にしんどいのは、判定作業そのものです。OpenSSLはOSのパッケージ、アプリケーション同梱、コンテナイメージ、ベンダー製アプライアンスの内部と、あらゆる階層に散らばっています。openssl version を叩いて終わり、とはいきません。限られた人員で資産の細部まで日常的に把握しておくのは、現実には難しいのが実情です。

加えて今回は、判定の第2段階が「アプリケーション側でフラグを立てているか」という、情シス単独では答えを出せない領域に入っています。自社開発なら開発チーム、パッケージ製品ならベンダーに聞くほかなく、返事を待つ数日のあいだ、上長からは「で、うちは大丈夫なの」と聞かれ続けます。

だからこそ、「非該当である」と説明できる根拠を残しておくことに価値があります。「当社の該当システムはOpenSSL 3.0系であり、本脆弱性の対象バージョンに含まれない」の一文と、その確認記録。スコア7.5という数字だけが独り歩きしたときに、落ち着いて説明できる材料になります。

情シスはどうすべきか

個別の脆弱性対応の前に、土台となる運用の整備を公的機関の指針に沿って進めるのが結局は近道です。自前で長いチェックリストを作るより、次の資料を出発点にしてください。

• 中小企業の情報セキュリティ対策ガイドライン（IPA） …… 資産の把握と脆弱性対応の体制づくりの基本形が示されています。「どの資産に何が入っているか」を持っていないと、今回のような判定は毎回ゼロからになります
• 脆弱性対策（IPA） …… 脆弱性情報の収集元と、届出・公表の流れを確認できます
• JPCERT/CC 注意喚起 …… 国内向けに緊急度の高いものが日本語で整理されます。なお今回のJVNVU#92139835はこの注意喚起一覧ではなく、JVNで公開されています

そのうえで効いてくるのは地味な作業です。ソフトウェア構成の棚卸し（SBOMの整備を含む）、開発チームとの連絡経路の確保、「スコアではなく成立条件で判断する」というトリアージ方針の共通認識化。この3つが揃っていれば、次に同種のアドバイザリが出たときの初動が数日単位で短くなります。

OpenSSLの脆弱性対応については、過去の事例も参考になります。OpenSSL脆弱性CVE-2026-45447（署名検証でのRCE）やOpenSSLに18件の脆弱性（PKCS#7処理）では、今回とは逆に影響範囲が広く、優先度も高い対応が必要でした。同じ「OpenSSLの脆弱性」でも判断がまったく違うことが分かります。OCSPや証明書失効確認の仕組みそのものは公開鍵基盤（PKI）とは？仕組みと証明書運用を解説で整理しています。また、メモリ枯渇を狙うDoSという点ではHTTP/2のフロー制御を悪用したDoS脆弱性と構造が似ています。

まとめ

• 該当条件は2つ揃ったときだけ。OpenSSL 4.0.0〜4.0.1 / 3.6.0〜3.6.3 を使っており、かつOCSPレスポンス検証フラグを明示的に有効化しているクライアントのみが影響を受けます。3.5系以前は非該当です
• NVDの7.5 HIGHはCISA-ADPによる暫定評価で、成立条件が反映されていません。OpenSSL公式の評価はLowです。スコアではなく、成立条件と資産の重要度で優先度を決めてください
• 修正版4.0.2 / 3.6.4は執筆時点で未公開です。待つのではなく該当判定を先に終わらせ、非該当なら記録を残して終了、該当するなら回避策の可否を検討します

出典

• OpenSSL Security Advisory [5th August 2026] — CVE-2026-54876
• OpenSSL Vulnerabilities（CVE-2026-35188 / CVE-2026-42765 の情報を含む）
• JVNVU#92139835 OpenSSLのOCSPレスポンス検証におけるクライアント側のメモリリークの脆弱性
• NVD – CVE-2026-54876
• oss-security メーリングリストへの投稿（2026年8月5日）
• OpenSSL Releases（GitHub）

※本記事は2026年8月9日時点の公開情報に基づいています。修正版4.0.2 / 3.6.4のリリース状況は、対応前に必ず一次情報で最新の状態をご確認ください。