Javaの臨時アップデートCVE-2026-91403とは？eMudhra問題と10月CPU、JDKごとの対応状況と確認手順

2026年10月、Javaには2日続けてセキュリティの更新が出ました。ひとつは10月20日（米国時間）に出た、3か月に1度の定例の更新「Critical Patch Update（クリティカル・パッチ・アップデート、略してCPU）」です。もうひとつは、その翌日の10月21日に、定例の枠の外で出された臨時の更新でした。

臨時の更新が対象にしたのは、CVE-2026-91403という番号の付いた欠陥で、深刻度は10点満点で9.1とされています。

臨時の更新が必要になった原因は、Javaのプログラムそのものの書き間違いではありません。インドの認証局（ウェブサイトの身元を保証する証明書を発行する会社）であるeMudhra（イーマドラ）が使っていた「中間証明書」の秘密の値が、ほとんどでたらめさのない作り方をされていて、外から計算で求められる状態だったことが分かったのです。

この記事では、10月20日の定例のCPUと10月21日の臨時の更新を順に整理し、CVE-2026-91403がどういう欠陥なのか、Oracleがどう直したのか、そしてTemurin、Corretto、Zulu、Microsoft Build of OpenJDK、Red Hatといった各社のJava（JDK）がどこまで対応しているのかを、一次情報をもとにまとめます。

そのうえで、自分のパソコンやサーバー、コンテナ、Spring Bootなどのアプリで何を確かめればいいのかを、具体的なコマンドとともに書いていきます。

先に結論を書いておくと、次の5つです。

10月20日と21日、2日続けて出たJavaの更新

まずは、この1週間ほどの流れを日付の順に並べておきます。Javaの話と、その原因になったeMudhraの証明書の話が並行して進んだので、両方を1つの表にまとめました。日付は、主に各社が発表した日（米国や欧州の時間）です。資料によって1日ずれているものは、そのことを書き添えています。

表のとおり、Javaの臨時の更新は、ブラウザが証明書を止めてから4日後に出ています。この4日の差には理由があります。

ChromeやFirefoxは、「この証明書はもう信用しない」という情報を、ブラウザ本体を更新しなくても配れる仕組み（ChromeのCRLSetや、FirefoxのOneCRL、CRLiteなど）を持っています。一方のJavaには、こうした遠隔で信頼を取り消す仕組みが標準では入っていません。Java自身を新しい版に入れ替えるか、設定ファイルを手で書き換えるまでは、Javaは古い判断のまま動き続けます。

ここで、言葉を2つ整理しておきます。CPUは、Oracleが1月・4月・7月・10月の決まった火曜日に出す、まとめての修正のことです。Javaだけでなく、データベースやMySQLなど、Oracleの製品全体が対象になります。

これに対して「セキュリティアラート」は、次の定例を待っていられないほど急ぐ欠陥のために、定例の外で出す臨時の修正です。Oracleがアラートを出すのは珍しく、しかも定例の翌日に出たことからも、急いでいたことがうかがえます。

もうひとつは「JDK（ジェイディーケー）」です。JDKはJava Development Kitの略で、Javaのプログラムを作って動かすための道具一式のことです。

中身の設計図はOpenJDKという公開のプロジェクトで作られていて、それをもとに、Oracle、Eclipse財団（Temurin）、Amazon（Corretto）、Azul（Zulu）、Microsoft、Red Hat、BellSoft（Liberica）などが、それぞれ自分の名前を付けて配っています。この「配っている会社」のことを、この記事ではディストリビューションと呼びます。設計図は同じでも、更新を出す日や、同梱する証明書の一覧には違いがあり、今回はその違いが表に出ました。

なお、eMudhraの証明書の事件そのもの（研究者がどう見つけたのか、ブラウザやGo、Tailscale、OSの証明書ストアがどう対応したのか）は、関連記事「eMudhra CA鍵の事件そのもの」で詳しく扱います。この記事では、Javaに関わる部分に絞って掘り下げます。

10月20日の定例CPU：Java SEで55件の修正

臨時の更新の話に入る前に、前日の定例CPUを見ておきます。臨時の修正は定例の版の上に重ねて出されているので、定例の版を知っておくと、自分が今どこにいるのかを判断しやすくなります。

窓の杜（Impress）の10月21日の記事によると、Oracleは米国時間の10月20日に、製品全体で1,295件の新しいセキュリティ修正を含むCPUを公開しました。

• そのうちJava SEは55件で、49件は認証なしでネットワーク越しに悪用できる種類のものとされています。
• Java SEの中で最も深刻度が高いものは、CVSS（共通脆弱性評価システム、欠陥の深刻さを0〜10の点数で表す仕組み）で7.5でした。

なお、Oracleの公式のアドバイザリのページは今回の取材では読み込めなかったため、件数は報道とOpenJDKや各社の資料から確かめています。

OpenJDKの10月20日のアドバイザリでは、OpenJDK本体で47件、画面を作るための部品であるOpenJFXで6件、合わせて53件の番号が並んでいます。Azulのリリースノートは55件を一覧にして、そのうち2件（CVE-2026-91484とCVE-2026-101737）はZuluには当てはまらないとしています。

数え方が会社ごとに少しずつ違うのは、OracleのJava SEにだけ含まれる部品や、OpenJFXを含めるかどうかといった違いによるものです。主なものを表にしておきます。

表を見ると、定例の分は、最も高いものでも7点台にとどまっています。ネットワークの部品（java.net）の修正が多く、件数で見ると全体の4分の1ほどを占めています。サーバーとして外部と通信するJavaのアプリは、定例の分だけでも早めに当てておきたい内容です。

定例CPUで出たOracle JDKの版は、Java SE 27.0.1、25.0.5、21.0.13、17.0.21、11.0.33、8u511です。Java 27にとっては、9月の公開後これが初めてのセキュリティ更新になりました。一方で、同じ時期に出た情報には、Java 26について「アドバイザリの表では影響を受ける版として載っているが、修正版は出ていない」とするものがあります。

Java 26は長期サポート版（LTS）ではないため、次の版が出ると更新が止まります。Java 26を使っている場合は、27か、長期サポート版の25へ移るのが現実的です。

次の定例のCPUは2027年1月19日の予定です。また、CPUを補う月ごとの更新（CSPU）が11月17日と12月15日に予定されていると報じられています。今回の臨時の修正は、次の定例の版にも当然含まれるはずですが、1月まで待つ理由はありません。

CVE-2026-91403とは：偽の証明書をJavaが信じてしまう欠陥

ここからが本題の臨時アラートです。CVE-2026-91403の中身を理解するには、HTTPSの通信で「相手が本物かどうか」をどうやって確かめているのかを、少しだけ知っておく必要があります。

証明書と認証局、中間証明書とは

Javaのプログラムが、たとえば決済サービスのAPIに接続するとき、通信はTLS（ティーエルエス、通信を暗号化して相手を確かめる仕組み。HTTPSの「S」の部分）で守られています。

接続先のサーバーは、「自分は確かにこのドメインの持ち主です」と示すために「証明書」を差し出します。証明書は、いわばサーバーの身分証明書です。

身分証明書が信用できるのは、信用できる発行元が発行しているからです。インターネットでは、この発行元を「認証局（CA）」と呼びます。認証局の中でも一番上に立つものの証明書を「ルート証明書」と呼び、Javaやブラウザ、OSは、あらかじめ信用するルート証明書の一覧を持っています。

ただし、ルート証明書の秘密の値（秘密鍵）は非常に大切なので、ふだんの発行作業には使いません。ルートの下に「中間証明書（中間CA）」という子どもの発行元を作り、実際のサイトの証明書はこの中間CAが発行します。

サーバーの証明書から、中間CA、ルートへとたどれる一連のつながりを「証明書チェーン」と呼びます。Javaは、このチェーンが自分の一覧にあるルートまでつながっていれば、相手を本物とみなします。

eMudhraの中間CAで何が起きたか

BleepingComputerの報道によると、問題になったeMudhraの中間証明書8枚は、どれもP-384という種類の暗号の鍵を使っていましたが、その秘密鍵の値が256未満という、ありえないほど小さな数でした。本来は、天文学的な数の候補の中からでたらめに選ばれるべき値です。

256通りしかなければ、全部試すのは一瞬で終わります。公開された鍵のひとつは、値がたったの「4」だったと報じられています。

eMudhraは、鍵を作るためのスクリプトの誤りが原因だと説明しています。スクリプトが弱い鍵の組をもう1つ作ってしまい、名前が似ていたために、そちらが署名に使われてしまったという説明です。

8枚の内訳は、次のとおりです。

• Webサイト用（TLS用）が6枚
• プログラムに署名するため（コード署名用）が2枚

秘密鍵が分かれば、その中間CAになりすまして、好きなドメインの証明書や、好きなプログラムへの署名を作れてしまいます。

Oracleのアラートの説明を要約すると、ネットワーク上にいる認証されていない攻撃者が、データの作成・削除・改ざんや、重要なデータの読み取りを起こしうる、というものです。

具体的には、通信の途中に割り込める立場の攻撃者（公衆無線LANや乗っ取られたルーターなど）が、偽の証明書を使って本物のサーバーになりすます「中間者攻撃」が想定されます。Javaのアプリは偽のサーバーを本物だと思い込み、パスワードやAPIのトークンを渡してしまったり、偽の応答を受け取ってしまったりします。

深刻度9.1と6.8、2つの点数

CVSSの点数は、資料によって違います。Oracleがアラートで示したのは9.1で、「ネットワーク越し・攻撃の難しさは低い・権限も利用者の操作も不要・機密性と完全性への影響が大きい・可用性（止まるかどうか）への影響はなし」という評価です。

一方、Red Hatは自社のCVEページで6.8という暫定の点数を付けています。Red Hatは、攻撃の難しさを「高い」、利用者の操作を「必要」と見ていて、通信の途中に割り込む必要があることを重く見た評価だと考えられます。

どちらの点数が正しいかを決める必要はありません。大切なのは、攻撃が成り立つには「通信の途中に入れること」が前提になる一方で、その前提さえ満たせば、Javaの側では見抜く手段がない、という性質です。

社内のネットワークだけで使っているシステムでも、ネットワークの中に攻撃者が入り込めば成り立つので、「外に出ていないから大丈夫」とは言い切れません。

悪用は確認されていない

10月24日の時点で、この欠陥が実際の攻撃に使われたという報告は見当たりません。公開されている攻撃コード（PoC）についても、確認できた資料はありませんでした。eMudhraも、問題の中間CAの多くは本番で使われておらず、利用者向けに証明書を発行した形跡はないと説明しています。

ただし、鍵は2025年4月から弱いままだったので、その間に誰かが気づいていた可能性まで否定できるわけではありません。BleepingComputerは、そうした悪用の証拠はないと伝えています。

研究者は、問題の証明書チェーンを実際に使った確認用のサイトを用意していて、そこにJavaから接続して「つながってしまう（HTTP 200が返る）」なら、そのJavaは偽の証明書を信じる状態だと分かるようになっています。

この確認用サイトは攻撃のためのものではなく、検査のためのものです。後半の確認手順で、この仕組みを使った確かめ方を紹介します。

Oracleの直し方：16枚の拒否リストと「ルートは消さない」判断

Oracleは今回、cacertsからルート証明書を消すのではなく、問題の中間証明書を「信用しないもの」として名指しする方法を選びました。その理由を理解するには、「クロス署名」という仕組みを知っておく必要があります。

8枚が16枚になる理由：Sectigoのクロス署名

Guillaume Laforge氏の10月21日の解説によると、8枚の中間CAは、それぞれ2回ずつ署名されていました。1回目はeMudhra自身のルート（TLS用・コード署名用の「G3」系のルート）による署名で、その先は「emSign ECC Root CA – G3」というルートにつながります。

2回目は、別の大手認証局であるSectigo（セクティゴ）の古いルート「AAA Certificate Services」による署名です。これを「クロス署名」と呼びます。

クロス署名は、新しい認証局のルートがまだ多くの機器に入っていない時期に、昔からあるルートの「お墨付き」を借りて、古い機器でもつながるようにするための仕組みです。今回は、2025年5月にSectigoがeMudhraの中間CAにクロス署名していました。

そのため、同じ鍵を持つ中間証明書が、eMudhraのルートにつながる版と、Sectigoのルートにつながる版の2種類、合わせて16枚あることになります。

Javaの一覧（cacerts）には、emSignのルートも、SectigoのAAA Certificate Servicesも入っています（入っているかどうかはディストリビューションによって違い、それは後で説明します）。攻撃者は、2つのうちどちらの経路でも偽の証明書を作れるので、片方だけを止めても意味がありません。

blocked.certs：信用しない証明書の一覧

JDKには、cacertsとは別に、「たとえチェーンがつながっていても、この証明書が途中に出てきたら拒否する」という拒否リストのファイルがあります。JDK 11以降では lib/security/blocked.certs、JDK 8では blacklisted.certs という名前で、証明書の指紋（SHA-256という計算で求めた、証明書ごとに異なる短い値）が並んでいます。

Oracleの修正は、ここに問題の中間証明書を書き加えるものでした。

ルートを消さなかったのは、ルートを消すと、そのルートの下にある正規の証明書まで使えなくなるからです。とくにAAA Certificate Servicesは、Sectigoの古いルートとして長く使われてきたもので、これを消すと、今も古い経路の証明書を出している正規のサイトにつながらなくなるおそれがあります。中間証明書だけを名指しで止めれば、ほかの正規のサイトには影響しません。

実際に修正版の中身を調べた検証記事（lilting.ch、10月23日）によると、修正版の27.0.1.0.2では、次のようになっていました。

• cacertsにはemSignのルートもAAAのルートも残ったまま
• blocked.certsの行が39行から87行に増え、48個の指紋が新しく加わっていた

16枚なのに48個なのは、同じ証明書でも、中身の書き表し方（DERという形式や、ECDSAという署名の数値の表し方）を少し変えると、別の指紋になってしまう場合があるためです。

Laforge氏も10月23日の追記で、16個の正規の指紋に加え、OpenJDKの変換ツールが作った32個の別表記を合わせて48個になったと説明を更新しています。最初は16個を手で書き足す回避策が広まりましたが、念入りに止めるなら48個が新しい目安です。

影響を受ける版と、修正版

Oracleのアラートで影響を受けるとされた版と、修正版を表にまとめます。影響を受ける版の欄に、前日の定例CPUで出たばかりの版が並んでいる点に注意してください。

表の版より古いものも、当然ながら影響を受けます。サポートの終わった版はOracleが試験していないだけで、問題の証明書を信じてしまう点は同じです。

Java 8の修正版の表記は、資料によって「8u511」とだけ書かれているものと「8u511 b32」と書かれているものがあり、ビルド番号まで確かめるのが確実です。また、OpenJDKのアドバイザリのページは、影響を受ける版の表記を10月23日にひっそり書き換えていて（11.0.33を11.0.32.1に、など）、表記が揺れていることが検証記事で指摘されています。

Oracleは、すぐに更新できない場合の代わりの手段として、2つを挙げています。

• ひとつは、Oracleが配るblocked.certsのファイルに入れ替える方法です（自分で書き足した項目がある場合は残す）。
• もうひとつは、Javaの起動時に -Dcom.sun.net.ssl.checkRevocation=true と -Dcom.sun.security.enableCRLDP=true を付けて、証明書が失効していないかを確かめる機能（失効確認）を有効にする方法です。

署名付きのJARについては、JDK 17以降で jarsigner -verify -revcheck -strict を使うと失効も含めて確かめられます。これらはどれか1つを選ぶ代わりの手段で、全部を同時に行う必要はありません。

「emSignのルートを消せば済む」ではない理由

今回の件で、日本語でも英語でも多く見かけたのが、「keytoolでemSignのルートを探して、消せば大丈夫」という手順です。keytoolは、JDKに付いてくる、証明書の一覧を見たり編集したりするための道具です。この手順には落とし穴があります。

keytoolで見えるのは、eMudhra側の経路だけ

Laforge氏の解説では、次のコマンドでemSignのルートを探す方法が紹介されています。keytool -list -cacerts -storepass changeit -v | grep -i "Owner:.*emSign" 。これを実行すると、「emSign ECC Root CA – G3」「emSign Root CA – G1」「emSign Root CA – G2」の3つが見つかる、という例が示されています（見つかる数はJDKによって違います）。

このうち、今回の中間CAにつながるのは「emSign ECC Root CA – G3」（Javaの中での別名は emsigneccrootcag3 [jdk]）です。ところが、これを消しても、SectigoのAAA Certificate Services（別名 comodoaaaca [jdk]）につながる側の経路は残ります。

Laforge氏は、ルートだけを消した状態では、TLS用の6つの経路と、コード署名用の2つの経路が残ってしまうと説明しています。「消したから安心」と思い込むことが、一番の落とし穴です。

AAAのルートまで消すと何が起きるか

では、AAA Certificate Servicesも消せばいいのでしょうか。この方法は確かに両方の経路を断てますが、Sectigoの古い経路で証明書を出している正規のサイトにもつながらなくなるおそれがあります。

Laforge氏の比較表では、この方法の副作用を「正規のSectigo AAA経由のチェーンが壊れる」としています。GitHubで公開された別のまとめでも、comodoaaacaを消すと古い正規のSectigoのチェーンが壊れると注意しています。

3つの方法を並べると、次のようになります。

表から分かるように、一番副作用が小さいのは、修正版に入れ替えるか、blocked.certsに指紋を加える方法です。ただし、話はここで終わりません。

OpenJDKが用意した利用者向けの案内ページ（openjdk.org/emudhra、10月23日更新）は、ベンダーから入手した単体のJDKについて、「修正版の27.0.1.0.2などに更新した場合でも」すぐに対処するよう求め、その手段として、emsigneccrootcag3とcomodoaaacaの2つをcacertsから消す方法（A）と、失効確認を有効にする方法（B）を示しています。なぜ修正版でも追加の対処が必要なのかは、ページには書かれていません。

ディストリビューションによって、cacertsの中身が違う

もうひとつややこしいのは、cacertsにどのルートが入っているかが、ディストリビューションによって違うことです。lilting.chの検証では、次の結果でした。

• jdk.java.netから入手したOpenJDK 27.0.1は、eMudhra側・Sectigo側のどちらの確認用サイトにもつながってしまいました。
• Temurin 25.0.4.1は、eMudhra側にはつながりましたが、Sectigo側は「有効な証明書の経路が見つからない」というエラーで失敗しました。

TemurinのcacertsにAAA Certificate Servicesが入っていないためです。

BellSoftの解説によると、Temurinは、Mozillaが管理するルート証明書の一覧（NSS）をもとにcacertsを作っていて、MozillaはAAA Certificate Servicesを2026年のうちに一覧から外していました。そのため、Temurinで危ないのは主にeMudhra側の経路です。

一方、BellSoftのLibericaのcacertsにはAAAが含まれていると同社は書いています。同じ「Java 21」でも、どこから入手したかによって、危ない経路の数が違うということです。

失効確認を有効にする方法にも注意点があります。lilting.chの検証では、失効確認を有効にするとOpenJDK 27.0.1は2つの経路のどちらも「失効済み（理由はCA_COMPROMISE）」として拒否しましたが、繰り返し試すと1回だけ接続が途中で切られました。

• 失効確認は、eMudhraの失効情報の配布サーバー（CRL）に毎回問い合わせるので、そこに届かないと接続そのものが失敗することがあります。
• オプションをzshのシェル変数に入れて渡したら、実際にはJavaに届いておらず、全部「つながってしまった」という落とし穴も報告されています。

設定したら、本当に効いているかを確認用サイトで確かめることが欠かせません。

ディストリビューション別の対応状況（10月24日時点）

ここでは、主なJDKのディストリビューションごとに、10月24日の時点で公式の資料から確かめられた対応状況をまとめます。状況は日々変わっているので、実際に作業するときは、それぞれの公式のページで最新の情報を確認してください。

表の中から、とくに注意したいところを補足します。

Corretto：定例の版と、対応の版を区別する

CorrettoのGitHubのリリース一覧では、21系の最新は10月23日の21.0.13.0.10、17系の最新は同じく10月23日の17.0.21.0.10になっています。21.0.13.0.10の変更履歴には、修正されたCVEとして40件が並び、その先頭にCVE-2026-91403（CVSS 9.1）が載っています。

一方、10月22日の時点では、Correttoを使っている別のプロジェクトが「Amazonがまだ修正版を出していない」として、自分たちのコンテナイメージにblocked.certsの更新を足す変更を行っていました。

つまり、Correttoは22日の時点では未対応で、23日の版で対応したと読めます。10月20日前後に配られたCorrettoの版を入れたままの場合は、もう一度更新してください。

Zulu：入れ替えのやり方に細かい注意

Azulは、Zuluの修正版とは別に、古い版を使い続ける人のための手順を公開しています。手順の流れは、次のとおりです。

1. プラットフォームごとに用意したblocked.certsのファイルを入手する
2. SHA-256の値で中身を確かめる
3. 各インストールの lib/security に上書きコピーする
4. Javaを使うアプリをすべて再起動する

ここで同社は、ファイルをテキストエディタで開いたり保存したりしないよう注意しています。エディタが目に見えない印（BOMなど）を付け加えると、Javaがリスト全体を無視してしまうことがあるためです。

また、修正を含まない版に更新すると元のファイルに戻ってしまうので、そのときは手順をやり直す必要があるとしています。

Temurin：一番使われているのに、発表が見当たらない

Temurinは、Dockerの公式イメージ「eclipse-temurin」にも使われていて、無償のJDKとして広く使われています。それだけに気になるのが、10月24日の時点で、Adoptium（Temurinを作っているEclipse財団のプロジェクト）のニュースページにも、利用者向けの課題の一覧にも、eMudhraやCVE-2026-91403についての発表が見当たらないことです。

TemurinのGitHubでは、10月22日に21.0.13+9が公開されていますが、検証記事は、10月の定例のタグは修正のコミットより前のものだと指摘しています。依存関係の調査を行うSafeDepも、10月22日時点のTemurinを「修正なし」としています。

Temurinを使っている場合は、修正版が出るまで、blocked.certsに指紋を加える回避策を取るのが現実的です。

SafeDepは、Temurinの USE_SYSTEM_CA_CERTS=1（OSの証明書を取り込む設定）を有効にしても効果がなかったと報告しています。この設定はOSの証明書を「足す」だけで、Temurinがもともと持っているルートを「消す」わけではないためです。

RHEL・Debian系：OSの証明書の更新を忘れずに

OSのパッケージとして入れたJavaは、事情が違います。Red Hatによると、RHELのパッケージ版のOpenJDKは、OS全体で共有する証明書の一覧（ca-certificates）を使うので、ca-certificatesの更新（CVE-2026-114406として追跡）で直ります。

OpenJDKの案内ページも、Arch Linux、Fedora、Gentoo、Oracle Linux、RHELはOSの証明書の更新でおそらく足りるとしています。

ただし、DebianとUbuntuなどの派生ディストリビューションでは、ca-certificatesとca-certificates-javaを更新するだけでは足りないとOpenJDKは書いています。Debianの既知の不具合（バグ番号1069251）のため、Java用の証明書の一覧が正しく作り直されないことがあるからです。

対処は、管理者の権限で rm -f /etc/ssl/certs/java/cacerts を実行してから、update-ca-certificates --fresh で一覧を作り直す、というものです。

自分のJavaが危ないかを確かめる手順

ここからは、手元のJavaが今回の欠陥の影響を受けるかを確かめる手順を、順番に書いていきます。仕事でサーバーを管理している方はもちろん、趣味でMinecraftのサーバーやJavaのツールを動かしている方も、一度確かめておくと安心です。

1. 入っているJavaをすべて洗い出す

最初にやるべきことは、版を確かめることではなく、「Javaがいくつ入っているか」を把握することです。java -version で表示されるのは、コマンドの検索パス（PATH）で最初に見つかった1つだけです。実際には、次のような場所に別々のJavaが入っていることがよくあります。

• IntelliJ IDEAやEclipseなどの開発環境に同梱されたJava
• SDKMAN!、asdf、mise、jEnvなどのバージョン管理の道具で入れた複数のJava（.tool-versions や mise.toml に版が書かれていることもあります）
• GradleのツールチェーンやMavenのツールチェーンが自動で取ってきたJava
• GitHub Actionsの actions/setup-java など、CI（自動でビルドや試験を行う仕組み）で使うJava
• 業務用のソフトや、ゲーム、IoT機器の管理ツールなど、製品の中に同梱されたJava
• Dockerのコンテナイメージの中のJava

それぞれのJavaで、次の手順を繰り返します。一つでも取り残すと、そこが弱点として残ります。

2. 版と、置き場所を確かめる

版は java -version で確かめます。Oracle JDKなら、表示された版を前の節の表と比べます。

Zuluのように、JDKの版番号とは別に独自の版番号を持つものもあり、Safeguardの解説は、修正のための再ビルドではJDKの版番号が元のままのことがあると注意しています。その場合は、ディストリビューション独自の版番号で判断してください。

Javaの置き場所は、java -XshowSettings:properties -version を実行して、表示される java.home の値で確かめられます。blocked.certsやcacertsは、この場所の下の lib/security（JDK 8では jre/lib/security）にあります。

3. 拒否リストに指紋が入っているかを確かめる

blocked.certsは、指紋が1行に1つずつ並んだ文字のファイルなので、中を数えることができます。SafeDepは、問題の中間証明書の指紋を grep -c で探し、「0」が返ればそのJavaは影響を受ける、という確かめ方を紹介しています。

修正版なら、Laforge氏や検証記事が示すように、16個（または別表記を含めて48個）の指紋が入っているはずです。

指紋の一覧は、OpenJDKの修正や、研究者が公開した一覧、各社の資料に載っています。ここで紹介するには長すぎるので、必ず一次の資料から写してください。

4. 実際に接続して確かめる

一番確実なのは、実際に問題の証明書チェーンを使ったサイトに接続してみることです。OpenJDKは、案内ページで確認用のプログラム CheckCerts.java を公開していて、JDK 8以降で使えるとしています。

また、Laforge氏の解説では、Javaの専門家として知られるMark Struberg氏が作った CheckCompromisedCa.java が紹介されています。JDK 11以降なら、java CheckCompromisedCa.java のように、ファイルを指定するだけでコンパイルせずに動かせます。

12個の確認用のアドレスに接続し、修正前のJavaでは12個すべてが「VULNERABLE（HTTP 200）」、修正後は12個すべてが CertPathValidatorException: Untrusted certificate で失敗すれば正しい状態です。

確認用のサイトは、研究者が we-have-a-problem.com というドメインで用意したもので、たとえば dv-g3b-emudhra.we-have-a-problem.com がeMudhra側の経路、dv-g3b-aaa-emudhra.we-have-a-problem.com がSectigo側の経路を試すためのものです。

比べるために、www.google.com のような普通のサイトにはつながることも、あわせて確かめておくと安心です。

5. ルートの有無を確かめる（参考）

どのルートが入っているかは、BellSoftが紹介している keytool -list -cacerts -storepass changeit | grep -E 'comodoaaaca|emsigneccrootcag3' で確かめられます。前の節で書いたとおり、ルートが入っていることは、それだけで危ないことを意味しません。

修正版では、ルートが残ったまま、拒否リストで止められています。ここでの確認は、「Sectigo側の経路が自分のJavaに関係あるか」を知るための参考として使ってください。

6. 直したら、必ず再起動する

Javaは、起動したときにblocked.certsやcacertsを読み込みます。Javaを更新したり、ファイルを入れ替えたりしても、すでに動いているアプリは古い一覧のまま動き続けます。

Windowsのサービスとして動いているJavaや、Tomcatのようなアプリケーションサーバー、Minecraftのサーバーなどは、忘れずに再起動してください。Azulも、手順の中で再起動を必須としています。

コンテナ・ネイティブイメージ・製品に同梱されたJava

Javaのアプリをサーバーで動かす場合、今はDockerなどのコンテナで動かす例が多くなっています。コンテナを使っている場合、開発者のパソコンのJavaを更新しても、本番のコンテナの中のJavaは変わりません。この節では、コンテナや、それに似た「作った時点で中身が固まる」配り方で、何に気をつけるべきかをまとめます。

コンテナイメージは作り直すまで古いまま

コンテナイメージは、アプリを動かすための環境を、OSの一部からJava、アプリ本体まで丸ごと詰めた配布物です。イメージの中のcacertsやblocked.certsは、イメージを作った（ビルドした）時点のものに固まっています。

動いているコンテナの中でファイルを書き換えても、コンテナを作り直せば元に戻ってしまうので、Azulは「動いているコンテナではなく、イメージやデプロイの設定を直すこと」を求めています。

Cycodeの解説は、修正版のベースイメージ（土台にするイメージ）に切り替えたうえで、docker build --pull --no-cache のように、最新のベースイメージを取り直し、キャッシュを使わずに作り直すことを勧めています。

また、Dockerfileでは次の場合、作り直しても古いままなので、指定そのものを書き換える必要があるとしています。

• ベースイメージをダイジェスト（イメージの中身から計算した固定の値）で指定している場合
• サポートの終わった系列を使っている場合

eclipse-temurin:21 のような「流れるタグ」なら、修正版が配られたあとに作り直せば新しい中身になりますが、前の節のとおり、Temurinの修正版の公開は10月24日の時点で確認できていません。

Temurinのイメージは、OSとしてUbuntuを使っていますが、SafeDepによると、OSの証明書の一覧を調べる道具ではJDK自身のcacertsは見られないので、Temurinのイメージでは別にblocked.certsの対処が必要です。修正版のベースイメージを待つ間は、Dockerfileに、指紋の一覧をイメージにコピーして $JAVA_HOME/lib/security/blocked.certs に書き足す手順を入れる方法が、Laforge氏やSafeDepから紹介されています。

distroless・最小構成のイメージ

シェル（コマンドを打つための仕組み）やパッケージ管理の道具を含まない、最小構成のイメージもあります。distrolessと呼ばれるものが代表例です。

こうしたイメージでは、イメージの中でコマンドを実行してファイルを書き換えることができないので、新しいダイジェストのイメージを取り直すか、別の段階で用意したファイルをコピーする形にします。BellSoftは、シェルがなく、管理者以外の利用者で動く形のイメージについて、いったん管理者に切り替えて処理し、終わったら元の利用者に戻す書き方を紹介しています。

Kubernetesを使っている場合は、Azulが紹介しているように、ConfigMapなどでblocked.certsのファイルを外から差し込む方法もあります。ただし、Windowsのコンテナでは1つのファイルだけを差し込むことができないので、作り直すしかないとAzulは書いています。

jlinkで作った小さなJava、CRaC

jlinkは、アプリに必要な部品だけを集めて、小さなJavaの実行環境を作る道具です。jlinkで作った実行環境は、元のJDKから部品を写し取った別物なので、元のJDKを直しても変わりません。

Azulは、jlinkで作るたびにblocked.certsを写し直す必要があると注意しています。jpackageでアプリとJavaをひとまとめにして配っている場合も同じで、macOSではファイルを入れ替えたあとに署名をし直す必要があります。

CRaC（クラック）は、起動して温まった状態のJavaを丸ごと保存しておき、次からはそこから再開して起動を速くする仕組みです。保存した時点の状態には古い拒否リストが含まれているので、Azulは、変更の前に作った保存点は作り直すよう求めています。

GraalVMのネイティブイメージ

GraalVMのネイティブイメージは、Javaのプログラムを、Javaの実行環境なしで動く1つの実行ファイルに変換する仕組みです。起動が速いので、コンテナやサーバーレスの環境でよく使われています。

Laforge氏によると、ネイティブイメージでは、証明書の一覧や安全のための設定が、ビルドした時点で実行ファイルの中に埋め込まれます。そのため、GraalVMの側のblocked.certsを直したうえで、実行ファイルをビルドし直す必要があります。

Oracle GraalVM for JDKの17.0.21と21.0.13は、アラートで影響を受ける版として名指しされています。

製品の中に同梱されたJava

見落としやすいのが、業務用のソフトに同梱されたJavaです。たとえば、スイスの業務ソフト会社Abacusは10月22日に、自社のERP（基幹業務システム）とクライアントのソフトが、同梱しているJavaのためにCVE-2026-91403の影響を受けると公表しました。同社は、正式な修正の提供（ERPは11月15日予定）までの間、同梱のJavaのblocked.certsを入れ替えるよう利用者に求めています。

このように、ソフトの会社がJavaを同梱している場合、利用者が自分でJavaを更新しても、そのソフトの中のJavaは変わりません。会社で使っている業務ソフトや、ネットワーク機器の管理画面、監視ツールなどにJavaが含まれていないかを確かめ、含まれている場合は、提供元の案内を待つか、問い合わせてください。

Azulも、Javaを同梱した製品については提供元に確認するよう呼びかけています。

Spring Bootなどアプリの側で確かめること

JDKを直せば終わり、とは限りません。アプリの書き方や設定によっては、JDKの一覧とは別の証明書の一覧を使っていたり、逆に一部の確認を止めていたりすることがあります。ここでは、Spring Bootを中心に、アプリの側で確かめておきたい点をまとめます。

どの通信が影響を受けるのか

今回の欠陥の影響を受けるのは、Javaのアプリが「接続する側（クライアント）」としてTLSを使う場面です。Laforge氏は、標準の証明書の一覧を使う場合の例として、Java標準の HttpClient や HttpsURLConnection、Springの RestClient や WebClient、Quarkus、Micronaut、Netty、OkHttpを挙げています。

外部のAPI（決済、メール配信、クラウドのストレージ、AIのサービスなど）を呼び出すアプリは、ほぼすべて当てはまると考えてください。

SafeDepは、外部のAPIを呼び出すJavaのサービスは、APIのトークンなどの秘密の値を通信に載せているため、とくに危険が大きいと指摘しています。偽のサーバーにつながってしまうと、そのトークンをそのまま渡してしまうからです。

逆に、Javaのアプリが「受ける側（サーバー）」として自分の証明書を出す場面では、今回の欠陥が直接の問題になることは少ないとみられます。ただし、お互いに証明書を見せ合う相互TLS（mTLS）で、相手の証明書を標準の一覧で確かめている場合は、受ける側でも関係してきます。

独自のトラストストアを使っていないか

トラストストアは、「信用するルート証明書の一覧」を入れたファイルのことで、cacertsもその一つです。アプリによっては、cacertsの代わりに自前のトラストストアを使っていることがあります。たとえば、次のような場合です。

• 起動時に -Djavax.net.ssl.trustStore=... を指定している場合
• Spring Bootの設定ファイル（application.ymlやapplication.properties）で、SSLバンドル（spring.ssl.bundle.jks.* や spring.ssl.bundle.pem.*）を使ってトラストストアを指定している場合

また、JDKの lib/security に jssecacerts というファイルがあると、Javaはcacertsより先にそちらを使います。

Cycodeは、-Djavax.net.ssl.trustStore で指定した独自の一覧はOSの更新で直らないので、手で対処する必要があると注意しています。とくに、昔にcacertsを丸ごと写して作ったトラストストアには、emSignのルートやAAAのルートが入ったままになっている可能性があります。

JDKを修正版に上げれば拒否リスト（blocked.certs）による拒否は働くはずですが、JDKが古いままなら、独自のトラストストアも危ないままです。どちらを使っているかを把握したうえで、両方を確かめてください。

ソースコードやビルドの成果物の中に、cacert.pem のような証明書の束のファイルが紛れ込んでいないかも確かめておきましょう。SafeDepは、こうしたファイルが同梱されていると、問題の中間証明書を信用し続けてしまうことがあるとして、ソースや配布物の中を探すよう勧めています。

証明書の確認を止めていないか

開発中に「証明書のエラーが出て面倒だから」と、すべての証明書を信じる設定（何でも通す TrustManager や、ホスト名の確認を止める設定）を入れたまま本番に出してしまう例は、残念ながら珍しくありません。こうした設定が入っていると、今回の欠陥とは関係なく、どんな偽の証明書でも通ってしまいます。

今回の件をきっかけに、TrustManager や HostnameVerifier、InsecureTrustManagerFactory といった言葉でソースコードを検索し、本番の経路で確認が止められていないかを見直しておくと安心です。

失効確認を有効にする場合の注意

Oracleが代わりの手段として挙げた失効確認は、アプリの起動オプションに -Dcom.sun.net.ssl.checkRevocation=true と -Dcom.sun.security.enableCRLDP=true を加えるだけで有効になります。Spring Bootのアプリなら、JAVA_TOOL_OPTIONS という環境変数や、起動スクリプトのJavaのオプションに加える形が一般的です。

ただし、前に書いたとおり、失効情報の配布元に届かない環境（外部への通信を制限したサーバーなど）では、接続そのものが失敗する可能性があります。また、すべての接続で失効情報を取りに行くので、通信の遅れが増えることもあります。

本番で使う前に、試験の環境で動きを確かめてください。

署名付きJARとコード署名

今回の8枚のうち2枚は、プログラムに署名するための中間CAでした。秘密鍵が分かれば、偽の署名を付けたJARファイルを作れてしまいます。

社内で、署名を確かめてからJARを読み込む仕組みを使っている場合は、jarsigner -verify -revcheck -strict で失効も含めて確かめるよう、Oracleは案内しています。eMudhraの中間CAで署名されたJARを正規に使っている組織は多くないとみられますが、署名の確認を仕組みに組み込んでいる場合は、念のため確かめておきましょう。

立場別にやること

最後に、ここまでの内容を、立場ごとに「まずやること」と「余裕ができたらやること」に分けて整理します。全部を一度にやる必要はありません。自分に当てはまる行から手をつけてください。

表の中で一番大切なのは、「直したことを確かめる」と「直したあとに消えないようにする」の2点です。Azulが注意しているとおり、修正を含まない版に上げると、手で入れ替えたblocked.certsは元に戻ってしまいます。

反対に、修正版に上げたあとも手作業のコピーやマウントの設定を残していると、将来の拒否リストの更新を、古いファイルで上書きして隠してしまうおそれがあります。修正版に移れたら、回避策は外してください。

また、今回の件は「Javaは独自の証明書の一覧を持ち、ブラウザのような遠隔での取り消しの仕組みを標準では使っていない」という、Javaの性質そのものから起きたものです。認証局の事件は、過去にもDigiNotarやSymantecなどで繰り返されてきました。

次に同じようなことが起きたとき、どのJavaがどこにあり、どうやって一覧を更新するのかが分かっていれば、今回よりも速く対応できます。今回作ったJavaの一覧は、捨てずに残しておくことをおすすめします。

証明書の仕組みを体系的に学ぶなら

今回の件を追いかけると、ルート証明書、中間証明書、クロス署名、失効、証明書の透明性といった言葉が次々に出てきます。これらを一度きちんと整理しておきたい方には、TLSと公開鍵基盤（PKI）の定番の解説書の日本語訳『プロフェッショナルTLS＆PKI 改題第2版』（Ivan Ristić著、齋藤孝道監訳、ラムダノート、2023年12月）があります。

出版社の公式ページによると、次のような内容を扱っています。

• 第4章「公開鍵基盤」で、証明書チェーン、認証局、証明書のライフサイクル、失効、証明書の透明性（CT）、CAAなどを体系的に説明しています。
• 第5章「PKIに対する攻撃」で、DigiNotar、StartCom、Comodoのリセラーの侵害、TURKTRUST、Symantecの失墜など、過去の認証局の事件を数多く取り上げています。今回のeMudhraの件を、過去の事件と比べながら理解するのに役立ちます。
• 第13章でOpenSSLを使った動作の確かめ方を扱い、OCSPやCRLによる失効の確認の手順も含まれています。
• 原書『Bulletproof TLS and PKI 2nd Edition』の全訳で、B5判488ページ。紙の本とPDFのセットでも販売されています。

なお、出版社の目次を見る限り、Javaに特化した章は含まれていません。Javaの設定そのものではなく、その土台にある証明書と認証局の仕組みを学ぶための本として選んでください。

プロフェッショナルTLS＆PKI 改題第2版をAmazonで見る

まとめ

2026年10月のJavaには、10月20日の定例CPU（Java SEで55件とする報道）と、10月21日の臨時のセキュリティアラートCVE-2026-91403が、2日続けて出ました。臨時の更新の原因は、eMudhraの中間CA 8枚の秘密鍵が極端に弱く作られていたことです。

ブラウザは自前の仕組ですぐに止めましたが、Javaは独自の証明書の一覧を持ち、遠隔での取り消しや失効確認を標準では使っていないため、Java自身の更新が必要になりました。

修正は、問題の中間証明書を拒否リスト（blocked.certs）に加える形で行われ、ルート証明書は残されています。8枚の中間CAはSectigoのAAA Certificate Servicesからもクロス署名されていたため、emSignのルートを消すだけでは足りず、AAAまで消すと正規のサイトに影響するおそれがあります。

各社の対応はそろっておらず、10月24日の時点ではTemurinの公式の発表を確認できていません。

• 定例CPUの版（21.0.13など）は臨時アラートの対象なので、Oracleなら .0.2 の付いた修正版まで上げる
• 手元、CI、コンテナ、製品同梱など、Javaをすべて洗い出して、それぞれを確かめる
• RHELはca-certificatesの更新、Debian・UbuntuはJava用の一覧の作り直しまで行う
• コンテナとネイティブイメージは作り直し、Javaのアプリは必ず再起動する
• 確認用のサイトに「つながらない」ことを確かめ、修正版に移れたら回避策は外す

今回の欠陥は、悪用の報告こそありませんが、攻撃者が通信の途中に入れれば、Javaの側では見抜けないという性質のものです。証明書の事件はこれからも起きるので、「自分のJavaがどこにあり、どうやって証明書の一覧を更新するのか」を、この機会に整理しておくことが、次の事件への一番の備えになります。

出典

• OpenJDK Vulnerability Advisory: 2026/10/21（CVE-2026-91403）
• OpenJDK and OpenJFX Vulnerability Advisory: 2026/10/20
• OpenJDK eMudhra（利用者向けの案内）
• Oracle Security Alert CVE-2026-91403
• Oracle Critical Patch Update Advisory – October 2026
• IPA Oracle Java の脆弱性対策について(2026年10月)
• 窓の杜 Oracle 2026年10月のCPU（Java SE 55件）
• endoflife.ai Oracle CPU October 2026
• Cyber Security News Oracle Issues Emergency Java Update for Critical 9.1 HTTPS Trust Vulnerability
• SecurityOnline CVE Watchtower CVE-2026-91403
• Red Hat Customer Portal CVE-2026-91403
• Guillaume Laforge The eMudhra CA Compromise: Why Your JVM Is Vulnerable (and How to Fix It Properly)
• lilting.ch Testing CVE-2026-91403 on OpenJDK and Temurin
• Azul Workaround for the eMudhra CA certificate compromise
• Azul Zulu October 2026 Release Notes
• Amazon Corretto 21 CHANGELOG
• Amazon Corretto 17 Releases
• Microsoft Learn Release Notes for the Microsoft Build of OpenJDK
• Adoptium temurin21-binaries Releases
• BellSoft eMudhra CA compromise: how to fix Java truststores
• Safeguard eMudhra Java Fix Update: JDK Vendor Builds and Workarounds
• SafeDep eMudhra CA Key Compromise: Response Guide for Developers
• Cycode eMudhra Intermediate CA Compromise: What to Patch and How to Find It
• seqeralabs/nf-jdk Pull Request #64
• Abacus Information about CVE-2026-91403
• BleepingComputer Mozilla, Google, Apple block compromised eMudhra CA certificates
• ラムダノート プロフェッショナルTLS＆PKI 改題第2版

※この記事の内容は、2026年10月24日時点で公表されている情報をもとにしています。