Javaの管理者は、10月20日の定例CPU適用だけで対応完了にしないでください。21日付の追加勧告CVE-2026-91403は、27.0.1や25.0.5など定例更新後の版も影響対象に挙げています。本稿で追加勧告の具体的な修正ビルドまでは確認できていないため、保守窓口・配布元のパッチ情報を別に確認する必要があります。
Oracleは10月20日付のCritical Patch Update（CPU）で、製品群全体に1,295件の新しいセキュリティパッチを案内しました。CPUはここでは計算装置ではなく、複数製品の修正をまとめた定例告知の名称です。この数字は世界で今日見つかった脆弱性の件数でも、重複を除いたCVE数でもありません。
定例CPUと追加Security Alertは別の行で管理する
| 告知 | 確認できた内容 | 運用上の判断 |
|---|---|---|
| 10月20日CPU | Java SEには55件の新規パッチ。そのうち49件について認証なしの遠隔悪用が可能とOracleが説明 | 利用機能とRisk Matrixの注記を照合する |
| 10月21日Security Alert | CVE-2026-91403。JSSE、CVSS v3.1で9.1、認証不要の遠隔悪用というOracle評価 | CPU後の版も対象。追加パッチの適用証拠が必要 |
前者の根拠はCPUのJava SE Risk Matrix、後者は専用のSecurity Alertです。Javaが存在するだけで、全CVEの攻撃経路が成立するとは限りません。各行のコンポーネント、プロトコル、前提条件を確認します。
JSSEとは何か、今回どこまで分かっているか
JSSEはJavaでTLSなどの安全な通信を扱う仕組みです。追加勧告は、該当コンポーネントのAPIを使う構成などの条件を記し、機密性と完全性への影響をHighと評価しています。一方、公開ページだけで根本原因の詳細や、すべての環境に共通の回避設定までは確定できません。未知の設定を推測して記事の手順にすることは避けます。
OracleはJSSEの追加勧告で、Oracle Java SEの8u511／8u511-perf、11.0.33、17.0.21、21.0.13、25.0.5、27.0.1に加え、Oracle GraalVM for JDKの17.0.21／21.0.13、GraalVM Enterprise Editionの21.3.20を影響対象に記しています。確認した勧告から、このCVEの実悪用の有無は確定できません。
版の表は「何に対する修正版か」まで読む
| 系列 | 10月20日CPUの公開版 | 21日の追加勧告への扱い |
|---|---|---|
| 27 | 27.0.1 | 追加勧告でも影響対象 |
| 25 | 25.0.5 | 同上 |
| 21 | 21.0.13 | 同上 |
| 17 | 17.0.21 | 同上 |
| 11 | 11.0.33 | 同上 |
| 8 | 8u511 | 同上。8u511-perfも追加勧告の対象 |
CPU公開版の根拠はOracleの27.0.1リリースノートとJava Managementのリリース案内です。この表を「これにすれば現在の全問題を解消」という表として使わないでください。追加勧告のPatch Availability Documentで、契約・製品に対応する修正情報を確認し、未確認なら未完了として残します。
IPAの10月21日の注意喚起も定例更新を案内しています。Oracle JDK以外のOpenJDK配布物には、配布元の対応状況を確認します。Oracle製のバイナリを別配布元のJDKへ無断で置き換えたり、ライセンス条件を確認せず導入したりしません。
PCのjava -versionだけでは、本番のJavaは分からない
- 1サーバー、バッチ、デスクトップアプリ、コンテナに内蔵されたJRE/JDKを列挙し、製品名・配布元・系列・ビルド番号を記録する。
- 2起動スクリプト、サービス定義、コンテナイメージなどから、実際のプロセスが使う実行ファイルを照合する。シェルのPATH上にあるJavaだけで判断しない。
- 3定例CPUとCVE-2026-91403を別の対応欄にする。Oracle製品の内蔵Javaは、その製品の保守手順とサポート条件を確認する。
- 4テスト環境で起動、HTTPS・証明書検証、外部API接続、認証、通常業務を回帰確認する。証明書検証を無効化してエラーを消すことは対処にしない。
- 5配布元の修正を適用し、全プロセスを入れ替えて実行版・パッチ識別子・確認者を記録する。追加勧告への証拠が不足する行は閉じない。
Java以外のOracle製品も、同じ数字で一括判定しない
定例CPUはDatabase、Fusion Middleware、MySQLなど幅広い製品を含みます。製品ごとのRisk MatrixとPatch Availability Documentが入口です。「Oracleを更新した」という一つのチェック欄では、DB本体、同梱ライブラリ、管理ツール、Javaの更新漏れを区別できません。製品の保守担当とサービス所有者を結び付けた台帳に分けてください。
すぐ更新できない場合は、該当機能へ渡る外部入力と公開範囲、停止した場合の業務影響を担当者で評価します。これは露出を減らす検討であり、今回のJSSEに対する公式の完全な回避策を示すものではありません。エンドユーザーが内蔵Javaを独自に差し替えず、アプリ提供者へ対応状況を確認することも必要です。
LLMに依頼する、根拠付きの点検
以下は編集部が作成した棚卸し用の指示文です。LLMの回答は安全性の保証にはなりません。未確認項目を残し、担当者が公式資料と実際の稼働状態を照合してください。
あなたは防御目的の運用点検担当です。権限のある自社環境について、提供した匿名化済み台帳と公式勧告だけで読み取り専用の棚卸しをしてください。 Oracle CPU October 2026とCVE-2026-91403の対応欄を分けてください。内蔵JRE、コンテナ、稼働プロセスの実行ファイルと配布元を照合し、定例CPUの版だけで追加勧告を解消済みとしないでください。 各項目を「対象」「対象外（根拠付き）」「未確認」に分け、根拠URL・配布元・稼働版・条件・担当者・修正版または未確認事項・確認期限を表にしてください。版だけで安全と断定しないでください。秘密鍵、トークン、パスワード、個人情報を要求せず、設定変更や攻撃再現、外部へのスキャンは実行しないでください。更新案と回帰確認案は作成しても、適用は担当者の判断に分けてください。
点検指示文をダウンロード。基本の進め方は脆弱性のトリアージも参照してください。
確認日：2026年10月22日。公開された一次資料を確認した解説であり、編集部がこの脆弱性の攻撃やパッチ適用を実環境で再現したものではありません。手順のうち優先順位・台帳・回帰確認は編集上の提案です。