Netty の OCSP 応答検証が甘く失効チェックを回避できる

Critical（CVSS 9.1）に分類されるNetty Nettyの脆弱性です。Netty の OcspClient が、OCSP 応答の CertificateID が自分が問い合わせた証明書の CertificateID と一致するかを検証していない。このため OcspClient.validateResponse は、同じ認証局が発行した無関係な証明書に対する正当に署名された GOOD 応答を受け入れてしまう。攻撃者は、失効済みの証明書を「有効」と判定させるために、同じ CA が出した別の生きている証明書の OCSP 応答を再生（リプレイ）すればよく、失効チェックは実質的に無効化される。影響範囲は 4.2.0.Final から 4.2.15.Final、および 4.1.135.Final より前で、修正版は 4.1.136.Final と 4.2.16.Final である。NVD の CPE も同じ範囲を示す。CVSS は評価元で割れており、NVD（Primary、nvd@nist.gov）は 3.1 で 9.1 Critical（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N）、CNA の GitHub（security-advisories@github.com）は 3.1 で 7.4 High（AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N）としている。差は攻撃条件の難易度のみで、同一 CA の応答を用意して経路に入る前提を GitHub 側は AC:H と見る。CWE は CWE-295（不適切な証明書検証）。CISA KEV には未収載。NVD の vulnStatus は Analyzed。

まず自分が OCSP 検証を Netty の OcspClient でやっているかを確かめるのが第一歩で、ここが該当条件になる。Netty を使っていても OCSP による失効確認を有効にしていなければ、この経路は通らない（ただしその場合は失効確認そのものをしていないという別の課題になる）。判定は依存ツリーの版から入るのが早く、Maven なら mvn dependency:tree、Gradle なら gradle dependencies で io.netty の版を出し、4.1 系は 4.1.136.Final 未満、4.2 系は 4.2.16.Final 未満が該当と見る。見落としやすいのは、Netty を自分で書いていない場合、つまり Spring Boot（Reactor Netty 経由）、gRPC-Java、Elasticsearch のクライアント、Cassandra ドライバといった上位のライブラリが内部で Netty を引いているケースである。この場合は上位ライブラリの版を上げるか、Maven の dependencyManagement や Gradle の resolutionStrategy で Netty の版を明示的に引き上げることになる。すぐに更新できない場合、失効チェックの回避が起点なので、証明書の失効に頼らない形で相手を絞るのが現実的な緩和になる。信頼するクライアント証明書を明示的に列挙したトラストストアに限定する、CRL による失効確認を併用する、証明書の有効期間を短くして失効に頼る場面を減らす、といった方向である。完了条件は、（1）依存ツリー上の io.netty が 4.1.136.Final 以降または 4.2.16.Final 以降になっていること、（2）上位ライブラリ経由で古い Netty が混ざっていないこと、この 2 点が全アプリケーションで確認できた時点である。加えて、失効させたはずの証明書で接続が成立していた可能性があるので、失効処理をした証明書のアクセスログを遡り、失効後の接続が無いかを確認しておく。

Netty Netty を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-56820）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。