10月のJava定例パッチを当てて「今四半期は終わった」と思った方、たぶんまだ終わっていません。
今回は、当てたばかりの修正版そのものが、翌日の緊急アラートの対象になったからです。
古いJavaを抱える現場ほど刺さる話なので、月曜にそのまま使える確認手順にまとめました。
何が起きたのか（時系列）
- 米国時間10月20日：Oracleが2026年10月のCritical Patch Updateを公開。全体で1295件のセキュリティパッチ、CVSS 10.0が6件。Java SEも対象です。
- 日本時間10月21日：IPAが「Oracle Java の脆弱性対策について(2026年10月)」で早急な更新を呼びかけ。
- 米国時間10月21日：OracleがSecurity Alert「CVE-2026-91403」（CVSS 9.1、コンポーネントはJSSE）を公開。対象は 8u511 / 11.0.33 / 17.0.21 / 21.0.13 / 25.0.5 / 27.0.1。つまり前日の修正版です。
原因は、認証局eMudhraの中間CA証明書8つの秘密鍵が侵害されたこと。悪用されると、TLSクライアントとして動くJavaアプリが偽の証明書を「正しい」と信じて、悪性サイトにつながる恐れがあります（Red Hatの説明）。
ややこしいポイント：「.0.2を入れたから安心」ではない
Oracleは追加修正版（27.0.1.0.2、25.0.5.0.2、21.0.13.0.2、17.0.21.0.2、11.0.33.0.2、8u511 b32）を出しています。
ただ、Oracleの対処ページ（10月23日更新）には、これらに更新済みでも、JVM再起動の前に次のどちらかを実施するよう書かれています。
-
ルート証明書を削除する
cacertsをバックアップしてから、emsigneccrootcag3 [jdk]とcomodoaaaca [jdk]の2つをkeytool -deleteで削除し、JVMを再起動 -
失効確認を有効にする
TLSを使うアプリの起動オプションに-Dcom.sun.net.ssl.checkRevocation=trueと-Dcom.sun.security.enableCRLDP=trueを追加
さらにSonatypeは、Javaのblocked.certs（フィンガープリントによるブロック）が、エンコードを変えた同じ中間証明書を通してしまうことを再現したと報告しています。テストした環境ではルートを削除すると両方とも拒否されましたが、ルート削除は正当なTLS接続まで止める可能性があるとも注意しています。
「パッチを当てたら終わり」ではなく、「どのtruststoreを、何で信頼しているか」まで見る必要がある、というのが今回の本質です。
月曜にやるチェックリスト
1. Javaの棚卸し（30分）
-
サーバー・バッチ・PCで
java -versionを取り、ベンダー名も記録（Oracle / Temurin / Corretto / Zulu / OS同梱など） - アプリに同梱されたJRE（製品の中に埋まっているもの）も洗い出す
- Java 26は修正版が出ていないため、25か27への移行日を決める
2. 「どの証明書ストアを見ているか」を確認
-
JDK同梱のcacerts（JDK 11以降は
lib/security/cacerts、JDK 8はjre/lib/security/cacerts） -
RHELのOpenJDK RPMはOSの
ca-certificatesを使うため、OSのパッケージ更新も必須（Red Hat） -
起動オプションで
javax.net.ssl.trustStoreを独自指定している場合、JDKのcacertsを直しても効かないので個別に確認
3. 判定ツリー
- 外部へHTTPS通信するJavaアプリか？
- いいえ（社内閉域のみ・TLSクライアントなし）→ 定例の修正版へ更新、ルート削除は計画的に
- はい → 次へ
- 接続先が
AAA Certificate Services系やemSign ECC Root CA - G3系のチェーンに依存しているか検証環境で確認済みか？- 未確認 → まず失効確認オプションで暫定対処し、接続先チェーンを調べる
- 依存なし → ルート削除＋再起動で対処
4. 実施時の落とし穴
- cacertsはJDKごとに別ファイル。複数インストールがあれば全部に実施
- 削除後は再起動しないと反映されない
- 失効確認を有効にすると、CRL/OCSPに届かない閉域環境で接続エラーが出る可能性があるので、本番前に疎通確認
- 署名付きJARはJDK 17以降で
jarsigner -verify -revcheck -strictで確認
古いJavaほど困る理由
今回のような証明書の信頼停止は、サポート期間内の版にしか修正が届きません。Oracleも、Premier/Extended Support外の版はテストすらしていないと明記しています。
「動いているから触らない」JDK 8や、ベンダー製品に埋まったJREは、修正版も回避策の検証も自前でやることになります。四半期ごとの定例に加え、Oracleは2026年5月から月次のCritical Security Patch Updateも始めました。次は11月17日です。
年4回のメンテ窓だけでJavaを回す運用は、もう前提が変わっています。今回の騒ぎを、Java棚卸しと「月次で当てられる体制」づくりのきっかけにしてみてください。
参考
- Oracle Critical Patch Update Advisory - October 2026: https://www.oracle.com/security-alerts/cpuoct2026.html
- Oracle Security Blog「October 2026 Critical Patch Update Released」: https://blogs.oracle.com/security/october-2026-critical-patch-update-released
- Oracle Security Alert Advisory - CVE-2026-91403: https://www.oracle.com/security-alerts/alert-cve-2026-91403.html
- Oracle「Distrusting eMudhra Intermediate Certificates in Oracle JDK」: https://ops.java/emudhra
- IPA「Oracle Java の脆弱性対策について(2026年10月)」: https://www.ipa.go.jp/security/security-alert/2026/1021-jre.html
- Red Hat CVE-2026-91403: https://access.redhat.com/security/cve/cve-2026-91403
- Sonatype「The Limits of Fingerprint Blocklists」: https://www.sonatype.com/blog/the-limits-of-fingerprint-blocklists-a-reproducible-java-certificate-bypass
- Oracle Security Alerts（CSPU日程）: https://www.oracle.com/security-alerts/
- 解説記事「Oracle Javaの脆弱性55件｜IPAの注意喚起と更新手順」（Java 26の扱い等）: https://jinrai.co.jp/blog/2026/10/22/oracle-java-vulnerability-2026-10/
- CIO「Oracle patches 1295 security vulnerabilities in October」: https://www.cio.com/article/4239848/oracle-patches-1295-security-vulnerabilities-in-october-including-six-scoring-10-0.html