Eclipse OpenJ9 の -Xtrace でバッファアンダーフロー

Critical（CVSS 9.1）に分類されるEclipse Foundation Eclipse OpenJ9の脆弱性です。Java 仮想マシンの実装である Eclipse OpenJ9 で、-Xtrace を使ってメソッドの引数をトレースするとバッファアンダーフローが起きる。NVD の記述は 0.60 までのバージョンが対象としており、CPE の範囲は 0.8.0 以上 0.60.0 未満である。修正は参照に登録されている OpenJ9 のプルリクエストで取り込まれているが、それがどのリリース版に入ったかは NVD のデータからは特定できないため、対応するリリースはベンダーの情報で確認する必要がある。CVSS は評価元の見方が大きく分かれている。NVD（Primary）は CVSS 3.1 で 9.1 Critical（CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H）とし、ネットワークから認証なしで完全性と可用性を損なえる評価にしている。一方 CNA である Eclipse Foundation は CVSS 4.0 で 5.8 Medium（AV:N/AC:H/AT:P/PR:L/UI:A/VC:N/VI:H/VA:H/SC:N/SI:L/SA:L）とし、攻撃の複雑度が高く前提条件があり、権限と利用者の関与も必要という評価にしている。発火条件が -Xtrace によるメソッド引数のトレースという運用者側の設定に依存するため、この差はそのまま実環境での危険度の差として読める。CISA KEV には未収載。NVD の vulnStatus は Analyzed。

まず自分の環境が OpenJ9 を使っているかを確認する。java -version の出力に OpenJ9 の記載があるかを見て、あればその VM のバージョン（openj9-0.xx.0 の形で出る）を確認し、0.60 以下なら該当と考える。HotSpot 系の JDK を使っているなら対象外である。見落としやすいのは、開発者が意識せず OpenJ9 ベースの JDK を使っている場合で、具体的にはコンテナのベースイメージで OpenJ9 版のタグを選んでいるもの、アプライアンス的に配布されたミドルウェアに同梱された JVM、そして OpenJ9 を採用した JDK 配布物を社内標準にしている環境である。イメージ内で java -version を実行して実測するのが確実で、Dockerfile のタグ名だけで判断しないほうがよい。次に、発火条件である -Xtrace の使用状況を確認する。JAVA_TOOL_OPTIONS や起動スクリプト、Kubernetes のマニフェストの JVM 引数を検索し、-Xtrace でメソッドの引数をトレースする設定が入っていないかを見る。恒常的に付けている環境は少なく、障害調査のために一時的に付けたまま戻していないケースが実際の残存リスクになりやすい。修正リリースが特定できるまでの当面の措置は、この引数を外すことである。メソッド引数のトレースを常用しないと決め、調査で必要な場合は対象を絞った短時間の使用にとどめる。完了条件は、稼働中の JVM で -Xtrace によるメソッド引数トレースが有効になっていないことを確認し、そのうえでベンダーが示す修正済みリリースへ JVM を入れ替えるところまでである。KEV 未収載で悪用の報告も無いため、緊急扱いではなく通常の JVM 更新サイクルに載せてよい。

Eclipse Foundation Eclipse OpenJ9 を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-16439）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。