Javaの脆弱性一覧を眺めてCVSSスコアの高い順にチケットを切ると、修正の順番を外します。実例が2024年1月のOracle Critical Patch Update（CPU）で公開されたCVE-2024-20932です。CVSS 3.1の基本値7.5は、このときのJava SEの10件のなかで単独最高でした。ところがCVEレコードの注記は、信頼済みコードだけを読み込んで実行するサーバー配備には適用されないと明記しています。ここでは一次情報の追い方と、CVE-2024-20932・CVE-2024-20918・CVE-2024-20919の実際の影響範囲を、CVEレコードとCVSSベクターに沿って整理します。
まとめ：Javaの脆弱性は「CVSSスコア」ではなく「配備形態」で直す順番が決まる
- Java SEの脆弱性は、Oracleが1月・4月・7月・10月に公開するCritical Patch Updateにまとまる。2026年5月からは月例のCritical Security Patch Update（CSPU）でもJava SEの修正が出ている（8月5件・9月3件）。日本語ではIPAが注意喚起を出す。
- CVE-2024-20932（CVSS 7.5・Security）は、信頼済みコードだけを動かすサーバー配備には適用されないとCVEレコードが明記している。
- CVE-2024-20918（CVSS 7.4・Hotspot）はWebサービス経由でAPIにデータを渡す経路が明記されており、サーバー配備ではこちらが先。
- CVE-2024-20919（CVSS 5.9・Hotspot）はAPI経由のみ。3件ともCVSSベクターの末尾はA:Nで、可用性への影響は評価されていない。
- 修正はJDK 8u401 / 11.0.22 / 17.0.10 / 21.0.2 に相当する四半期リリースで入る。ただしOpenJDKディストリビューションの版番号はOracleと一致しない。
以下、一次情報の場所、3件のCVEの中身、スコア順に直すと何を外すのか、そして自環境の影響判定までを順に見ていきます。
Javaの脆弱性一覧で影響版と適用条件を確認するための一次情報源
Oracle Critical Patch Updateのリスクマトリクス
Java SEの脆弱性は個別に随時公開されるのではなく、Oracleが四半期ごとにまとめて出すCritical Patch Update（CPU）に乗ります。公開月は1月・4月・7月・10月です。ただし2026年5月28日から、それ以外の月の第3火曜日に月例のCritical Security Patch Update（CSPU）も出るようになり、2026年8月のCSPUではJava SEに5件の修正が含まれました（影響版は8u501・11.0.32・17.0.20・21.0.12・25.0.4・26.0.2）。「Javaの更新は年4回」という前提の運用は、2026年からは月1回の確認に改める必要があります。アドバイザリには製品別のリスクマトリクスが付いていて、CVE番号・コンポーネント・CVSS基本値・プロトコル・影響を受けるサポート対象バージョンが1行で並びます。「Javaの脆弱性一覧」を探すなら最初に開くべきはこの表で、まとめ記事の要約ではなく「Supported Versions Affected」列を自分の環境の版と突き合わせてください。
日本語で影響版と個別の脆弱性を追う場合のIPAとJVN iPedia
CPUが出るとIPAが「Oracle Java の脆弱性対策について」という注意喚起を日本語で公開します。2026年7月分の公開日は2026年7月22日。対象（＝影響を受ける版）として挙げられているのは、Oracle Java SE 26.0.1、25.0.3、21.0.11、17.0.19、11.0.31、8 Update 491（および8u491-perf）の6系統です。示されている対策は「Oracle社から提供されている最新版のソフトウェアに更新します」の一点だけ。個別の脆弱性を日本語の説明付きで検索したいときはJVN iPediaを使うと、英語のCVEレコードを読む前に当たりを付けられます。
サンドボックスとAPI経由の適用条件を分けるCVEレコードの注記
脆弱性一覧サイトやニュース記事は、CVE番号とCVSSスコアと一行要約までを転載して終わることが多いです。ところがOracle Java SEのCVEレコードは、説明文の末尾に「Note:」で始まる適用条件を持っています。この注記が、その脆弱性をクライアント側のサンドボックス配備で踏むのか、サーバー側のAPI経由でも到達できるのかを分ける。スコアと要約だけを転記した二次情報からは、この一文が落ちます。CVE番号は識別子でしかなく、危険度の判断材料はCVEとCWEの違いとは？脆弱性管理の基礎をCVSS・相互関係とあわせて解説のとおり別に読み取る必要があります。
CVE-2024-20932・20918・20919の影響範囲と到達経路
3件はいずれも2024年1月のCPU（アドバイザリ公開日は2024年1月16日）で修正されたOracle Java SEの脆弱性です。CVEレコードの記載を並べると次のようになります。
| CVE | コンポーネント | CVSS 3.1 | ベクターの差分 | 到達経路 |
|---|---|---|---|---|
| CVE-2024-20932 | Security | 7.5 | AC:L/C:N/I:H | サンドボックス配備のみ |
| CVE-2024-20918 | Hotspot | 7.4 | AC:H/C:H/I:H | API経由＋サンドボックス配備 |
| CVE-2024-20919 | Hotspot | 5.9 | AC:H/C:N/I:H | API経由のみ |
表のベクター欄は差分のAC・C・Iを記載しています。共通する項目はAV:N・PR:N・UI:N・S:U・A:Nで、完全なベクターはAV/AC/PR/UI/S/C/I/Aの順に組み合わせます。3件ともベクターの末尾はA:Nです。CVSSの評価上は可用性への影響がなく、サービス停止を狙う攻撃の標的にはなりません。旧来「Javaの脆弱性はまずクラッシュを疑え」と整理されがちですが、この3件についてはあてはまらない。
CVE-2024-20932（CVSS 7.5・Security）の適用条件
影響を受けるとされたのはOracle Java SE 17.0.9、Oracle GraalVM for JDK 17.0.9、Oracle GraalVM Enterprise Edition 21.3.8および22.3.4です。8u391や11.0.21は対象に入っていません。攻撃条件はAC:L・PR:N・UI:Nと軽く、成功すると重要データの不正な作成・削除・改変が起きます。
問題は適用範囲です。CVE-2024-20932のCVEレコードの注記は、インターネット由来の信頼できないコードを読み込みJavaサンドボックスに安全性を依存する配備、つまりサンドボックス化されたJava Web Startアプリケーションやアプレットを走らせるクライアントに適用されると述べます。そのうえで、管理者がインストールした信頼済みコードだけを実行するサーバー配備には適用されないと明記しています。裏を返せば、信頼できないコードを読み込むサーバーは適用除外になりません。この限定句を落として「サーバーには無関係」とだけ読むと、判定を誤ります。
CVE-2024-20918（CVSS 7.4・Hotspot）の到達経路
こちらは対象が広く、Oracle Java SE 8u391、8u391-perf、11.0.21、17.0.9、21.0.1が影響を受けます。GraalVM for JDKは17.0.9と21.0.1、GraalVM EEは20.3.12、21.3.8、22.3.4です。注記では、当該コンポーネントのAPIを使うこと、たとえばAPIにデータを供給するWebサービスを通じて悪用できると述べられており、そのうえでサンドボックス配備にも適用されると続きます。サーバー側とクライアント側の両方で成立する型。CVSSはAC:Hで攻撃条件が難しい分だけ基本値が7.4に下がっていますが、影響はC:HとI:Hの両方に及び、20932より広くなっています。
CVE-2024-20919（CVSS 5.9・Hotspot）の位置づけ
影響を受けるバージョンは20918と同一です。注記は、信頼できないJava Web Startアプリケーションやアプレットを使わずに、Webサービスなどを通じて当該コンポーネントのAPIにデータを供給することでのみ悪用できる、としています。つまりサーバー側の経路しか持ちません。影響はI:Hのみで、CVSS基本値は5.9です。なおCVEレコード上の公開日は2024年2月17日で、CPU当日に登録された20932・20918より1か月遅れています。CVEデータベースへの登録日と修正が出荷された日は一致しません。
2024年1月CPUで修正が入ったJDKのバージョンと更新先の判断
影響を受けるとされた版の次の四半期リリース、すなわち2024年1月CPU相当の 8u401 / 11.0.22 / 17.0.10 / 21.0.2 が修正版です。Adoptiumのtemurin11-binaries、temurin17-binaries、temurin21-binariesの各リポジトリでGitタグを確認すると、jdk-11.0.22+7、jdk-17.0.10+7、jdk-21.0.2+13がいずれも実在します。11.0.21を使っているなら11.0.22以降、17.0.9なら17.0.10以降、21.0.1なら21.0.2以降へ上げれば、この3件は解消します。
2026年10月時点のLTSは8・11・17・21・25の5系統、最新のLTSは25で、最新のフィーチャーリリースは2026年9月15日にGAとなった27です。2024年1月の版に留まっている環境はその後2年半分のCPUを取りこぼしているので、系統内の最新パッチまで一気に上げるほうが現実的でしょう。
Javaの配備形態を見落とすCVSSスコア順に並べた修正計画の落とし穴
サーバー側のAPIへの到達経路と配備形態から決める脆弱性の修正順
スコア降順に並べると20932（7.5）、20918（7.4）、20919（5.9）の順になります。サーバーサイドのJavaしか動かしていない環境では、この順序を採用してはいけません。実際の作業順は次のとおりです。
- まずCVE-2024-20918。Webサービス経由でAPIにデータを渡す経路が注記にあり、C:HとI:Hの両方に影響する。
- 次にCVE-2024-20919。同じくAPI経由で到達するが、影響はI:Hのみ。
- CVE-2024-20932は最後。信頼済みコードしか読み込まないサーバーであれば、そもそも攻撃経路が成立しない。
基本値で0.1しか違わない20932と20918のあいだに、適用されるかされないかという断絶があります。これはCVSSの欠陥ではなく用途の問題です。CVSS基本値はどの環境にも共通する性質だけを表す設計で、自組織にその配備形態があるかは入りません。その差分は環境評価基準で埋める建前ですが、実務上はCVEレコードの注記を読むほうが早い。
CVE-2022-21449との比較で見えるサーバーへの到達経路の違い
同じ考え方は過去のCVEにも当てはまります。CVE-2022-21449はコンポーネントがLibrariesで、CVSS 3.1基本値は7.5、ベクターはAV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:Nと、CVE-2024-20932と完全に同一です。ECDSA署名の検証で値の範囲チェックが欠けており、すべてゼロの署名が正当なものとして通ってしまう欠陥で、Psychic Signaturesの通称で知られています。JWTやSAMLの署名検証に直撃するため、実運用への影響は大きいものでした。
注記も20932とは違います。20932がサンドボックス配備のみと限定するのに対し、21449はサンドボックス配備に加えて「当該コンポーネントのAPIを使うことでも悪用できる」と続けている。到達経路が二重にある分、同じ7.5でもサーバー運用における実質的な危険度はこちらが上です。
もう1点、一覧の読み方として重要な注意があります。21449のCVEレコードが影響対象として挙げるのはOracle Java SE 17.0.2と18、Oracle GraalVM EE 21.3.1と22.0.0.2の4つだけです。ところが同レコードが参照するoss-securityメーリングリストのスレッドでは、実際に影響を受けるのはJava 15から18であり、15と16はサポートが終了しているためOracleの公式CVE記載から落ちている、と指摘されています。CPUのリスクマトリクスやCVEレコードのaffected欄は「その時点でサポート対象だった版」の一覧であって、脆弱な版の全量ではありません。サポート切れの版を動かしている環境ほど、一覧に自分の版が載っていないことを安全の根拠にできません。
CVSSスコアだけでは決まらない修正順と配備条件・悪用実績の指標
優先順位を決める材料は、CVSS基本値のほかに2つあります。1つはここまで見てきた配備条件で、CVEレコードの注記から読み取れます。もう1つは実際に悪用が観測されているかどうかで、CISAのKnown Exploited Vulnerabilities（KEV）カタログが代表的です。OWASP Dependency-CheckはKEVカタログを取り込むアナライザを既定で有効にしており、スキャン結果に悪用実績の有無を反映できます。CVSS 9点台でも悪用例がなく自環境に配備形態がないものより、7点台でKEVに載っていて自社のWebサービスから到達できるもののほうが先。スコア降順にソートしたチケット一覧を、そのまま作業順にしないでください。なお2026年10月1日版のKEVにOracle Java SE・JREの登録は13件ありますが、いずれも2010〜2016年のCVEで、2024年以降のCVEは1件もありません。
配備形態の棚卸しやWebサービスから到達できる経路の洗い出しを自社だけで進めにくい場合は、脆弱性診断・セキュリティ診断で外部から到達できる面を確認できます。Oracle CPUの回ごとの全体像（Java以外の製品や悪用済みCVEを含む）は、Oracle 2026年1月CPUの337件と修正版で整理しています。
OpenJDKディストリビューションへの修正の届き方と版番号の確認
同一CPUに乗るOpenJDK由来の修正と配布元ごとの更新の確認
CVEレコードに書かれる製品名はOracle Java SEとOracle GraalVMですが、Hotspotのように上流のOpenJDKに由来するコンポーネントの修正は、OpenJDKの更新プロジェクトを経由してEclipse Temurin、Amazon Corretto、Azul Zulu、BellSoft Liberica、Red Hat build of OpenJDKなどの各ディストリビューションにも同じ四半期のタイミングで入ります。実際、2024年1月CPU相当の 17.0.10 はTemurinでもjdk-17.0.10+7として同月に配布されました。
したがって「OpenJDKだからOracleの脆弱性情報は関係ない」という読み方は成立しません。逆に、Oracle JDKのライセンス条件を避けてOpenJDKディストリビューションへ移行した環境でも、CPUの公開日には同じ更新作業が必要です。ライセンス面の切り分けはOpenJDKは商用利用できる？無料の範囲とOracle JDKとの違い・ライセンス・サポート期限【2026年最新】で整理しています。
Java 8でOracleと一致しない版番号とリリース時期の照合
ここで実務上つまずくのが版番号です。Java 11以降はOracleとOpenJDKディストリビューションで番号が揃いますが、Java 8では揃いません。CVE-2024-20918の影響対象はOracle Java SE 8u391で、Oracle側の修正版は8u401です。ところがAdoptiumのtemurin8-binariesリポジトリには8u401のタグが存在せず、同じ2024年1月CPU相当の更新はjdk8u402-b06として公開されています。Oracleのアドバイザリに書かれた番号でTemurinのリリースを探すと見つからず、未対応だと誤判定する原因になる。Java 8系を使っている場合は、番号の一致ではなくリリース時期とディストリビューション側のリリースノートで対応関係を確認してください。
本番のJDKと依存ライブラリから自環境が影響を受けるかを判定する手順
本番プロセスで実行中のJDKの特定とバージョン・配布元の確認方法
判定の起点は、開発端末にインストールした版ではなく本番プロセスが実際に読んでいるJDKです。複数のJDKが同居している環境ではPATHの先頭とアプリケーションサーバーの設定が食い違うことがよくあります。
java -version
java -XshowSettings:properties -version前者でランタイムの版とベンダー名、後者の出力に含まれるjava.homeとjava.vendorで実体の場所と配布元が分かります。コンテナで動かしているならホスト側ではなくイメージ内で実行してください。JDK・JRE・JVMの区別があいまいなまま調べると取り違えるので、Java SEとは？JDK・JRE・JVMの違いとOracle Java/OpenJDKのライセンスを最新版で解説で用語を先に押さえておくと確実です。
JDK更新後も残る依存ライブラリの脆弱性を洗うSCAツールの使い方
JDK本体を最新にしても、アプリケーションが抱えるサードパーティJARの脆弱性は残ります。ここを機械的に洗うのがSCA（Software Composition Analysis）で、無償で使える定番がOWASP Dependency-Checkです。1つ注意点があります。正リポジトリはdependency-check/DependencyCheckで、以前の所在であるjeremylong/DependencyCheckはアーカイブ済み。古い記事や社内Wikiのリンクをたどると更新の止まったリポジトリに着地します。2026年10月2日時点でも最新リリースはv13.0.0（2026年8月3日公開）で、Mavenプロジェクトならビルドに組み込めます。
mvn org.owasp:dependency-check-maven:check既定ではHTMLレポートがビルド出力ディレクトリに生成されます。CVSS基本値がしきい値を超えたらビルドを落とす運用にしたい場合は、failBuildOnCVSSを設定してください。ただし前節のとおりスコアだけで止めると、自環境に配備形態のない脆弱性でビルドが赤くなり続けます。
CI/CDに載せるときのNVDデータ取得とAPI上限・キャッシュの設定
Dependency-CheckはNVD APIから取得したCVEデータをローカルのH2データベースに保持して照合します。実行環境からservices.nvd.nist.govへ到達できることが前提で、閉域のビルドサーバーでは失敗する。KEVアナライザが参照するwww.cisa.govも同様です。既定値を見ると、NVDデータの再確認間隔はnvd.api.check.validforhoursで4時間、KEVカタログはkev.check.validforhoursで24時間に設定されています。
さらに効くのがAPIキーです。NVD APIへのリクエスト上限は、キーなしで30秒あたり5回、キーありで50回と既定値が10倍違います。CIのジョブごとに使い捨てコンテナでキャッシュを持たずに走らせる構成にすると、初回取得が毎回発生してキーなしの上限に張り付きます。データディレクトリをキャッシュに載せるか、nvd.api.keyを設定するか、社内ミラーをnvd.api.datafeed.urlで参照するかのいずれかを選んでください。
よくある質問
Javaの脆弱性一覧はどこで確認できますか？
起点はOracleのCritical Patch Updateアドバイザリに含まれるOracle Java SEのリスクマトリクスで、1月・4月・7月・10月に更新されます。2026年5月からは、それ以外の月に出る月例のCritical Security Patch UpdateにもJava SEの修正が載ることがあります。日本語ならIPAの「Oracle Java の脆弱性対策について」とJVN iPediaを併用してください。個別の適用条件まで確認するときはNVDまたはCVE Programのレコード本文を読みます。なお一覧に載るのはその時点でサポート対象だった版だけなので、サポート切れの版を使っているなら載っていないことを安全の根拠にできません。
CVE-2024-20932はサーバーにも影響しますか？
CVEレコードの注記では、管理者がインストールした信頼済みコードだけを読み込んで実行するサーバー配備には適用されないとされています。適用対象はサンドボックス化されたJava Web Startアプリケーションやアプレットを実行するクライアント側で、信頼できないコードを読み込むサーバーは適用除外になりません。サーバー運用ではWebサービス経由でAPIに到達できるCVE-2024-20918のほうが優先度は上です。
OpenJDKにもOracleの脆弱性修正は入りますか？
入ります。Hotspotなど上流のOpenJDKに由来する修正は、Temurin、Corretto、Zulu、Libericaといった各ディストリビューションにも同じ四半期のタイミングで反映されます。ただしJava 8系は版番号がOracleと一致せず、Oracleの8u401に相当するTemurinのリリースは8u402です。番号ではなくリリース時期で対応関係を確認してください。
使っているJavaのバージョンはどう確認しますか？
java -version でランタイムの版とベンダーを、java -XshowSettings:properties -version の出力に含まれるjava.homeで実体の場所を確認します。開発端末ではなく本番プロセスが読んでいるJDKで実行するのが要点です。コンテナ運用ならイメージ内で実行してください。
CVEの重要度はCVSSスコアだけで判断してよいですか？
基本値だけでは足りません。CVSS基本値は環境に依存しない性質のみを表す設計なので、自組織にその配備形態があるかは反映されません。CVEレコードの注記に書かれた適用条件と、CISAのKnown Exploited Vulnerabilitiesカタログに載っているかどうかを合わせて読み、スコア降順ではなく到達可能性の高い順に直してください。
