情報取得日: 2026/08/19／最終確認: 2026/08/15・本ページは公開情報の非公式まとめです
| CVE ID | CVE-2026-16441 |
|---|---|
| 製品 | Eclipse Foundation / Eclipse OpenJ9 0.8.0 以上 0.60.0 未満（0.60 まで） |
| CVSS | 9.6（Critical） CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H |
| 種別 (CWE) | CWE-758 未定義・未指定・実装依存の動作への依存 |
| 登録／公開日 | 2026/08/19 |
| 出典 | https://nvd.nist.gov/vuln/detail/CVE-2026-16441 |
Eclipse OpenJ9 の 0.60 までのバージョンで、以前は具象だったスーパークラスのメソッドが抽象として再コンパイルされたクラスファイルを実行したとき、呼び出しが誤ってインタフェースのデフォルトメソッドへ委譲される。NVD の記述は「when executing class files where a previously concrete superclass method has been recompiled as abstract, execution is incorrectly delegated to an interface default method」。これは JVM が本来保証する型解決の規則が破れているということで、CWE は CWE-758（未定義・未指定・実装依存の動作への依存）。この CVE で注目すべきは、評価元によってスコアが大きく割れている点である。NVD（Primary、nvd@nist.gov）は CVSS 3.1 で 9.6 Critical（AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H）を付けているのに対し、CNA である Eclipse（emo@eclipse.org）は CVSS 4.0 で 6.9 Medium（AV:N/AC:H/AT:P/PR:L/UI:A/VC:N/VI:H/VA:L/SC:L/SI:H/SA:N）としている。差の中心は攻撃条件の見立てで、NVD が AC:L（容易）・PR:N（権限不要）と取るのに対し、Eclipse は AC:H（困難）・AT:P（前提条件あり）・PR:L（低権限が必要）と取っている。NVD の 9.6 は S:C（スコープ変更）も含むため、影響の広がりを大きく見積もっている。修正は OpenJ9 の pull request #24396 で入っている。KEV には収載されていない。
各ベンダー公式アドバイザリで確認できた事実に基づき整理しています。確認できていない項目は「情報確認中」と明記し、存在しないパッチ番号・バージョンは記載しません。
| 環境 | 対応状況 | 対応方法・備考 |
|---|---|---|
| AWS (ECS/EC2) | 対象外 |
対象外（AWS のマネージドサービスに修正対象は無い）
Lambda・ECS・EKS・EC2 で OpenJ9 系のランタイム（IBM Semeru / Temurin の OpenJ9 ビルド）を使っている場合は、そのイメージのランタイムを更新する。Corretto は HotSpot ベースなので対象外。
参照リンク
|
| GCP | 対象外 |
対象外（GCP のマネージドサービスに修正対象は無い）
Cloud Run・GKE のコンテナイメージに含まれる JVM を確認する。java -version の出力に OpenJ9 が含まれるかで判定する。
参照リンク
|
| Azure | 対象外 |
対象外（Azure のマネージドサービスに修正対象は無い）
App Service・AKS のイメージに含まれる JVM を確認する。Microsoft Build of OpenJDK は HotSpot ベースなので対象外。
参照リンク
|
| Linux | 対象外 |
対象外（OpenJ9 はディストリの標準 JDK パッケージではないことが多く、ディストリのセキュリティ更新では上がらない）
IBM Semeru Runtime や Temurin の OpenJ9 ビルドを個別に導入している場合、配布元の更新で入れ替える。ディストリの openjdk パッケージは通常 HotSpot なので対象外。
参照リンク
|
この CVE への向き合い方は、スコアの数字より先に「どちらの評価が自分の環境に当てはまるか」を決めることである。NVD の 9.6 は未認証の遠隔攻撃者を想定した見立て、Eclipse の 6.9 は低権限の利用者がクラスファイルを持ち込める状況を想定した見立てで、両者は矛盾しているのではなく前提が違う。判断の分かれ目は「攻撃者が任意のクラスファイルをその JVM に読み込ませられるか」の一点である。読み込ませられるなら NVD 側の見立てに寄り、社内の閉じたアプリケーションでコードの供給元が固定されているなら Eclipse 側の見立てに寄る。プラグイン機構を持つアプリケーション、利用者がアップロードした Java コードを実行する仕組み、外部由来の jar を動的にロードする構成は、前者に該当する。次に、自分の JVM が OpenJ9 かどうかを確認する。ここが実務上いちばん躓きやすい。OpenJ9 は Eclipse Temurin の一部のビルドや IBM Semeru Runtime として配布されており、「Java を使っている」という認識はあっても「OpenJ9 を使っている」という認識が無いことが多い。判定は java -version の出力を見るのが確実で、OpenJ9 なら出力に OpenJ9 の文字列が含まれる。HotSpot と表示されるなら対象外である。コンテナイメージのベースに含まれている場合も同様に、イメージ内で実行して確認する。対応は OpenJ9 0.60.0 より後のバージョンへの更新である。ランタイムの配布元（Temurin / Semeru など）が OpenJ9 のどのバージョンを含むかは配布元の対応表で確認する必要があり、Java のバージョン番号（17 や 21）だけでは判定できない点に注意する。緩和として実務的なのは、外部由来のクラスファイルを読み込む経路を閉じることである。この欠陥は「再コンパイルされたクラスファイルを実行したとき」に起きるので、コードの供給元を固定できれば発火条件を作らせない。KEV には収載されておらず、実際の悪用も確認されていないので、緊急の停止対応が必要な段階ではない。ただし型解決が破れる欠陥は、アクセス制御を回避する足がかりとして使われうるため、次回のランタイム更新の対象に確実に載せる。
Critical（CVSS 9.6）に分類されるEclipse Foundation Eclipse OpenJ9 0.8.0 以上 0.60.0 未満（0.60 まで）の脆弱性です。Eclipse OpenJ9 の 0.60 までのバージョンで、以前は具象だったスーパークラスのメソッドが抽象として再コンパイルされたクラスファイルを実行したとき、呼び出しが誤ってインタフェースのデフォルトメソッドへ委譲される。NVD の記述は「when executing class files where a previously concrete superclass method has been recompiled as abstract, execution is incorrectly delegated to an interface default method」。これは JVM が本来保証する型解決の規則が破れているということで、CWE は CWE-758（未定義・未指定・実装依存の動作への依存）。この CVE で注目すべきは、評価元によってスコアが大きく割れている点である。NVD（Primary、nvd@nist.gov）は CVSS 3.1 で 9.6 Critical（AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H）を付けているのに対し、CNA である Eclipse（emo@eclipse.org）は CVSS 4.0 で 6.9 Medium（AV:N/AC:H/AT:P/PR:L/UI:A/VC:N/VI:H/VA:L/SC:L/SI:H/SA:N）としている。差の中心は攻撃条件の見立てで、NVD が AC:L（容易）・PR:N（権限不要）と取るのに対し、Eclipse は AC:H（困難）・AT:P（前提条件あり）・PR:L（低権限が必要）と取っている。NVD の 9.6 は S:C（スコープ変更）も含むため、影響の広がりを大きく見積もっている。修正は OpenJ9 の pull request #24396 で入っている。KEV には収載されていない。
この CVE への向き合い方は、スコアの数字より先に「どちらの評価が自分の環境に当てはまるか」を決めることである。NVD の 9.6 は未認証の遠隔攻撃者を想定した見立て、Eclipse の 6.9 は低権限の利用者がクラスファイルを持ち込める状況を想定した見立てで、両者は矛盾しているのではなく前提が違う。判断の分かれ目は「攻撃者が任意のクラスファイルをその JVM に読み込ませられるか」の一点である。読み込ませられるなら NVD 側の見立てに寄り、社内の閉じたアプリケーションでコードの供給元が固定されているなら Eclipse 側の見立てに寄る。プラグイン機構を持つアプリケーション、利用者がアップロードした Java コードを実行する仕組み、外部由来の jar を動的にロードする構成は、前者に該当する。次に、自分の JVM が OpenJ9 かどうかを確認する。ここが実務上いちばん躓きやすい。OpenJ9 は Eclipse Temurin の一部のビルドや IBM Semeru Runtime として配布されており、「Java を使っている」という認識はあっても「OpenJ9 を使っている」という認識が無いことが多い。判定は java -version の出力を見るのが確実で、OpenJ9 なら出力に OpenJ9 の文字列が含まれる。HotSpot と表示されるなら対象外である。コンテナイメージのベースに含まれている場合も同様に、イメージ内で実行して確認する。対応は OpenJ9 0.60.0 より後のバージョンへの更新である。ランタイムの配布元（Temurin / Semeru など）が OpenJ9 のどのバージョンを含むかは配布元の対応表で確認する必要があり、Java のバージョン番号（17 や 21）だけでは判定できない点に注意する。緩和として実務的なのは、外部由来のクラスファイルを読み込む経路を閉じることである。この欠陥は「再コンパイルされたクラスファイルを実行したとき」に起きるので、コードの供給元を固定できれば発火条件を作らせない。KEV には収載されておらず、実際の悪用も確認されていないので、緊急の停止対応が必要な段階ではない。ただし型解決が破れる欠陥は、アクセス制御を回避する足がかりとして使われうるため、次回のランタイム更新の対象に確実に載せる。
Eclipse Foundation Eclipse OpenJ9 0.8.0 以上 0.60.0 未満（0.60 まで） を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-16441）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。
本ページの記載は下記の一次情報に基づく非公式まとめです。数値・対応状況は各出典元で最終確認してください（最終確認: 2026/08/15）。