Java 証明書 脆弱性 CVE-2026-91403 として、Oracle が2026年10月21日に緊急の Java セキュリティアップデートを公開しました。中身は、認証局 eMudhra の中間CA（その秘密鍵が弱かった）を、Java の JSSE（Java Secure Socket Extension）が信頼してしまう問題です。これは先に当サイトで扱ったpip をいますぐ26.2.2へ更新（eMudhra 弱鍵CA）と同じ根の事案で、今回はその Java 側の現れ方です。Oracle は CVSS 3.1 で 9.1（Critical）と評価し、該当する中間CA証明書を distrust しました。依存するランタイムの信頼が崩れる全体像は、サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にもまとめています。この記事は、何が起きたか・どこで露出するか・直し方・自分の JDK の確かめ方を、一次情報と当サイトの実機点検で整理します。

JAVA EMUDHRA何が起きたか

eMudhra 弱鍵CAを、Java が信頼ストアで遮断する

  1. 根の問題

    eMudhra の中間CAの秘密鍵が弱い

    MITM 位置の相手が偽証明書を作れる余地

  2. 各社

    ブラウザ・CAが失効へ

    pip（certifi）も同梱証明書を差し替え済み

  3. 10/21

    Oracle が緊急アラート

    CVE-2026-91403・CVSS 9.1・JSSE コンポーネント

  4. 対処

    該当中間CAを distrust

    根（root）は残し、中間だけ遮断。HTTPS は外さない

  5. 現状

    悪用の確認なし

    とはいえ更新・緩和が確実策

出典: Oracle セキュリティアラート（2026-10-21）、Red Hat・cybersecuritynews ほか（2026-10-23 確認）

30秒でわかる

  • ・何が：弱い鍵の eMudhra 中間CAを Java(JSSE) が信頼してしまう（CVE-2026-91403・CVSS 9.1）
  • ・いつ危ない：MITM 位置の相手が偽証明書で偽サーバーを本物に見せられる。暗号化だけでは守れない
  • ・直し方：最新の Java 更新が本筋。当て直せない時は blocked.certs 差し替え・失効チェック・jarsigner の緩和3択
  • ・範囲：Oracle Java SE・GraalVM。OpenJDK・Temurin など他ビルドも同じ。pip/certifi と同じ根

まずやること

・java -version を各 JDK・各コンテナで確認し、Oracle の Patch Availability Document の修正ビルドへ上げる
・すぐ上げられないなら、lib/security/blocked.certs をベンダー配布版で差し替える（JDK 8 は blacklisted.certs）
・それも難しければ、TLS 失効チェックを有効化して時間を稼ぐ

CVE-2026-91403 で何が起きたか：eMudhra 弱鍵CA の Java/JSSE 側

HTTPS は、接続先が本物かを「証明書」で確かめ、その証明書に署名して保証するのが認証局（CA）です。今回の根は、CA である eMudhra が弱い秘密鍵で中間CA証明書を発行していたことにあります。Red Hat の説明によると、弱い鍵を復元した攻撃者は、任意のホスト名向けの証明書を自分で作れてしまいます。

CVE-2026-91403 は、この弱い鍵の中間CAを Java の JSSE が信頼のチェーンの一部として受け入れてしまう問題です。Oracle は2026年10月21日に緊急アラートを出し、CVSS 3.1 で 9.1（Critical）、攻撃の複雑さは低、認証・ユーザー操作は不要と評価しました。成功すると機密データの露出・改ざんが起こりうる一方、可用性への影響はなし、としています。

観点 内容 位置づけ
影響コンポーネント JSSE（Java Secure Socket Extension） Oracle 公式
深刻度 CVSS 3.1 で 9.1（Critical） Oracle 公式
前提 MITM（経路に割り込む）位置が必要 Red Hat・報道
対処 該当中間CAを distrust（根は残す） Oracle 公式
悪用 確認された攻撃の報告なし 報道（2026-10-22 時点）

直すのは「HTTPS をやめる」ことでも「証明書の仕組みを入れ替える」ことでもありません。Java が受け入れる証明書を変える、つまり該当する中間CAだけを信頼しないようにする修正です。CVSS 9.1 という高い値も、機密性（露出）と完全性（改ざん）への影響が大きい一方、可用性（止まる・落ちる）への影響は無い、という内訳になっています。サービスを落とす種類の脆弱性ではなく、通信相手を偽られる種類だ、と読むと対処の優先度を決めやすくなります。

どこで露出するか：JSSE が信頼する証明書チェーン

露出するのは、Java が外部と TLS で通信し、相手の証明書チェーンを検証する場面です。攻撃者が経路上にいることが前提になります。

WHERE IT HITSどこで露出するか

JSSE が信頼チェーンを検証する所が入口

  1. MITM 位置の攻撃者

    公衆Wi-Fi・ISP・経路上に座る

  2. 弱い鍵で偽の中間CA証明書

    任意ホスト名の証明書を自作

  3. JSSE が信頼と判定

    チェーンが eMudhra 根につながり通る

  4. 偽サーバーを本物と誤認

    機密データの露出・改ざん

出典: Red Hat の説明（2026-10-23 確認）。暗号化だけでは相手が本物かは守れない（識別の問題）

Oracle は、JSSE にデータを渡すサービス経由でこの API に到達しうるとし、信頼できないコードを読み込むサンドボックスの Java Web Start アプリケーションやアプレットも対象に挙げています。要するに、暗号化そのものは効いていても、「通信相手が本物か」という識別が崩れるのがこの問題の怖さです。経路上の攻撃者が偽の証明書を本物として見せられれば、暗号化された通信ごと偽のサーバーへ導かれます。

直す：最新版・blocked.certs・失効チェックの3択

HOW TO FIX直し方（いずれか）

最新版が本筋、当て直せない時は緩和3択

  1. 1.最新の Java 更新を入れる（本筋）

    Patch Availability Document の修正ビルドへ。各イメージ・各JDK個別に

  2. 2.blocked.certs を差し替える

    ベンダー配布版で（JDK 8 は blacklisted.certs）。手編集に頼らない

  3. 3.TLS 失効チェックを有効化

    -Dcom.sun.net.ssl.checkRevocation=true ＋ enableCRLDP=true

  4. 4.署名JARは revcheck 付きで検証

    JDK 17+：jarsigner -verify -revcheck -strict <JAR>

出典: Oracle の緩和案内（2026-10-23 確認）。3択は代替であって全部を同時に行うものではない

本筋は、修正ビルドへの更新です。Oracle の勧告は対象として Java SE 8u511・8u511-perf・11.0.33・17.0.21・21.0.13・25.0.5・27.0.1、GraalVM for JDK 17.0.21・21.0.13、GraalVM Enterprise Edition 21.3.20 を挙げています（より古い・サポート外の版は未検証ながら影響しうる）。実際に入れる修正ビルドは Oracle の Patch Availability Document に示されるので、それに従います。すぐに上げられないときの緩和は、次の3つのいずれかで、全部を同時に行うものではありません。

・blocked.certs を差し替える：JDK の lib/security/blocked.certs を、ベンダーが配布する版に置き換える。既存のカスタム項目は残す。JDK 8 ではファイル名が blacklisted.certs
・TLS 失効チェックを有効化：-Dcom.sun.net.ssl.checkRevocation=true と -Dcom.sun.security.enableCRLDP=true
・署名JARの検証：JDK 17 以降で jarsigner -verify -revcheck -strict <SIGNED_JAR>

自分の JDK を確かめる（当サイトの実機点検つき）

確認は版と失効リストの2点です。コンテナ・CI・本番で別々の JDK が入るので、環境ごとに見ます。

# JDK の版（修正ビルドかどうかは Oracle の Patch Availability Document で突き合わせる）
java -version

# 失効リスト blocked.certs の場所と、登録されているフィンガープリントの数
JH=$(java -XshowSettings:properties -version 2>&1 | awk -F'= ' '/java.home/{print $2}')
head -1 "$JH/lib/security/blocked.certs"
grep -cE '^[0-9a-fA-F]{64}$' "$JH/lib/security/blocked.certs"

これは判定ではなく構成の確認で、この結果だけでは安全とは言えません。blocked.certs は証明書を名前ではなくフィンガープリント（SHA-256）で識別するため、emSign や eMudhra という文字列で探しても一致しません。何件登録されているかは分かっても、「今回の中間CAが確実に入っているか」は目視では分からない、という性質があります。

当サイトで確かめたこと（2026-10-23）

この記事を書いた環境には OpenJDK 21.0.12.1 が入っていました。JDK 同梱の blocked.certs は 1 行目が Algorithm=SHA-256 で、以降は SHA-256 フィンガープリント（16進64桁）が 38 件登録されていました。失効リストの実物です。予想どおり、emSign／eMudhra という文字列では 0 件で、名前での grep は効きません。JDK 同梱の cacerts と、この環境がトラストストアに指定している /etc/ssl/certs/java/cacerts のいずれにも、別名に emsign／emudhra を含むルートは見当たりませんでした（別名が異なる可能性までは否定できません）。偽証明書の作成など、脆弱性を発動させる操作は一切行っていません。だからこそ、フィンガープリントを手で足すのではなく、ベンダーが配布する blocked.certs ファイルで差し替えるのが確実です。

独立した検証でも、blocked.certs にフィンガープリントを手で書き足しただけでは該当ホストに接続できてしまい、配布ファイルで差し替えて初めて止まった、という報告があります。手編集に頼らないのが肝心です。

影響範囲と、pip/certifi との関係

影響を受けるのは、Oracle Java SE と GraalVM で、外部と TLS 通信して証明書チェーンを検証する処理です。そして重要なのは、これが Oracle の JDK だけの話ではない点です。問題の根は eMudhra という CA の鍵の弱さなので、同じコードベースの OpenJDK や Temurin など他のビルドも同様に対応が要り、各ベンダーが自前のビルドや blocked.certs を出しています。

さらに広く見ると、これは pip（certifi）で起きたのと同じ根の、別ランタイムでの現れ方です。eMudhra の弱い鍵の中間CAを、どの実行環境の信頼ストアが受け入れてしまうか——それぞれで塞ぐ必要があります。pip では同梱 certifi を差し替える pip 26.2.2 の更新、Java では中間CAの distrust、という形です。実行環境の信頼そのものが攻撃面になるこの構図は、同じ月に相次いだNode2shell（Node.js の Brotli RCE）のような「ランタイムの処理が入口になる」話とも地続きで、ランタイムを一つずつ最新に保つことが、結局いちばん効く備えになります。

参照ソース

・Oracle Issues Emergency Java Update for Critical 9.1 HTTPS Trust Vulnerability（cybersecuritynews） — Oracle アラートの内容・対象版・緩和策（2026-10-23 確認）
・CVE-2026-91403 - Red Hat Customer Portal — 根本原因（eMudhra の弱い鍵の中間CA）と OpenJDK での対応
・Does Java Trust eMudhra’s Compromised Intermediate CAs?（lilting.ch） — OpenJDK・Temurin での独立検証と blocked.certs の手編集の落とし穴
・pip をいますぐ26.2.2へ更新（eMudhra 弱鍵CA・当サイト） — 同じ根のCA問題の Python 側