CVE-2026-50633｜Apache CXF の JNDI 注入と暫定回避策

はじめに

Java の Web サービスフレームワークとして広く使われている Apache CXF に、コード実行につながり得る JNDI 注入の脆弱性 CVE-2026-50633 が公表されました。影響を受けるのは、CXF を JCA リソースアダプター（RAR）としてアプリケーションサーバーに組み込む特定の構成です。攻撃の成立には JCA デプロイメント記述子（ra.xml）や起動時のパラメーターを操作できることが前提となるため、まずは自環境が対象構成に該当するかどうかの切り分けが出発点になります。

本脆弱性の影響は、cxf-integration-jca を用いた JCA RAR 構成に限定されます。CXF を JAX-WS / JAX-RS フレームワーク（Spring Boot やサーブレット）として使う一般的な構成では、このモジュールを含まないため影響を受けない可能性が高いです。根本対処は 4.2.2 または 4.1.7 へのアップグレードで、すぐに更新できない場合は、利用有無の切り分け・ra.xml へのアクセス制限・外部への LDAP / RMI 通信の遮断が暫定的な回避につながります。

CVE-2026-50633 の概要

CVE-2026-50633 は、Apache CXF の JCA 統合モジュール（org.apache.cxf:cxf-integration-jca）に含まれる JNDI 注入の脆弱性です。対象クラスは DispatchMDBMessageListenerImpl で、攻撃者が ra.xml や起動時のアクティベーションパラメーターを操作できる場合に、コード実行につながる可能性があります。

参考: Apache CXF 公式 Advisory（CVE-2026-50633）
“A JNDI Injection vulnerability has been discovered in Apache CXF’s JCA integration module”
（Apache CXF の JCA 統合モジュールに JNDI 注入の脆弱性が発見された）
https://lists.apache.org/thread/1czhgovkgzdkyp3t61wthn0foogh2grf

JNDI 注入とは

JNDI（Java Naming and Directory Interface）は、Java アプリケーションが LDAP・RMI・DNS などのディレクトリサービスから、名前を指定してオブジェクトを取得するための仕組みです。JNDI 注入は、この 取得に使う名前（参照先）を攻撃者が操作できてしまう ことで成立します。参照先を攻撃者が用意したサーバーに向けさせると、環境によってはリモートのオブジェクトやクラスが読み込まれ、コード実行に至ります。

このクラスの脆弱性として広く知られているのが、2021 年の Log4Shell（CVE-2021-44228）です。CVE-2026-50633 も同系統で、CXF の JCA 統合モジュールが JNDI ルックアップに用いる値が、ra.xml や起動パラメーター経由で外部から操作され得る点が問題となります。本記事では、攻撃の再現手順（具体的なペイロード）には踏み込まず、影響の切り分けと防御・検知に焦点を当てます。

深刻度の評価（Apache: important / CISA-ADP: CVSS 8.1 HIGH）

深刻度は、Apache の評価が important（重要）です。NVD 本体のスコアは執筆時点で未付与ですが、CISA-ADP が CVSS 3.1 で 8.1（HIGH） を付与しています。ベクターは AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H で、ネットワーク経由（AV:N）かつ認証不要（PR:N）である一方、攻撃成立の難易度は高い（AC:H）と評価されています。これは、ra.xml や起動パラメーターを操作できることという前提条件を反映したものです。機密性・完全性・可用性のいずれにも高い影響（C:H/I:H/A:H）があり、成立した場合の被害は大きくなります。

弱点分類は CWE-20（不適切な入力検証）で、発見者は Securin の Venkatraman Kumar 氏（r3dw0lfsec）です。脆弱性は 2026 年 6 月 12 日に公開されました。攻撃難易度が高い一方で影響が大きいため、対象構成に該当する場合は、影響範囲の確認と対処を進めることが望まれます。

影響を受ける条件と自環境の確認

本脆弱性の影響は、cxf-integration-jca を用いた JCA RAR 構成に限定されます。確認のポイントは、(1) CXF を JCA リソースアダプターとして利用しているか、(2) cxf-integration-jca が依存関係に含まれ、どのバージョンかの 2 点です。

対象は cxf-integration-jca を用いた JCA RAR 構成

該当するのは、CXF をリソースアダプター（.rar）として Java / Jakarta EE アプリケーションサーバーに組み込み、ra.xml で設定する構成です（参照: https://cxf.apache.org/docs/using-cxf-jca-rar-in-application-server.html ）。CXF を JAX-WS / JAX-RS フレームワーク（Spring Boot やサーブレット）として使う一般的な構成では、このモジュールを含まないため、影響を受けない可能性が高いです。

判断の手がかりは、.rar 形式での CXF のデプロイ有無、ra.xml の存在、そして cxf-integration-jca がクラスパスに含まれるかどうかです。

依存関係から CXF のバージョンと利用形態を確認する

Maven プロジェクトでは、依存ツリーをフィルターして cxf-integration-jca の有無とバージョンを確認します。フィルター構文は [groupId]:[artifactId]:[type]:[version] です。

# cxf-integration-jca が依存ツリーに含まれるかを確認
mvn dependency:tree -Dincludes=org.apache.cxf:cxf-integration-jca

# CXF 関連の依存とバージョンをまとめて確認
mvn dependency:tree -Dincludes=org.apache.cxf

出力に cxf-integration-jca が現れなければ、本脆弱性の対象モジュールはプロジェクトに含まれていません。現れる場合は、表示されたバージョンが修正版（4.2.2 / 4.1.7）以上かを確認します。

Gradle プロジェクトでは、以下のコマンドで確認できます。

# 特定の依存の解決結果を確認
./gradlew dependencyInsight --dependency cxf-integration-jca

# プロジェクト全体の依存ツリーを確認
./gradlew dependencies

なお、CXF が直接の依存ではなく他のライブラリやフレームワーク経由で推移的に取り込まれている場合もあります。上記コマンドの出力で、どの依存から引き込まれているかをあわせて確認しておくと、後述のバージョン更新がスムーズになります。

根本対処: 4.2.2 / 4.1.7 へのアップグレード

根本的な対処は、修正版へのアップグレードです。CXF の 4.2.x 系を利用している場合は 4.2.2、4.1.x 系を利用している場合は 4.1.7 が対象です。これらより古いブランチ（4.1.6 以前など）を利用している場合は、修正版を含む系列への移行を検討します。

参考: NVD（CVE-2026-50633）
“Users are recommended to upgrade to versions 4.2.2 or 4.1.7, which fixes this issue.”
（ユーザーには本脆弱性を修正する 4.2.2 または 4.1.7 へのアップグレードが推奨される）
https://nvd.nist.gov/vuln/detail/CVE-2026-50633

Maven / Gradle での更新

多くのプロジェクトでは、CXF のバージョンを cxf.version のようなプロパティで一元管理しています。このプロパティを修正版に更新するのが基本です。

<properties>
  <cxf.version>4.2.2</cxf.version>
</properties>

CXF が推移的に取り込まれている場合は、dependencyManagement（Maven）や依存制約（Gradle の constraints / platform）でバージョンを上書きし、解決されるバージョンを修正版に固定します。更新後は、再ビルドしたうえで先の dependency:tree で解決結果を確認します。

mvn -U clean verify
mvn dependency:tree -Dincludes=org.apache.cxf:cxf-integration-jca

Gradle では、依存宣言またはバージョン管理箇所を修正版に更新します。

implementation 'org.apache.cxf:cxf-integration-jca:4.2.2'

アプリケーションサーバー同梱版の確認

一部の Jakarta EE / Java EE アプリケーションサーバーは、CXF をサーバー側のライブラリとして同梱しています。この場合、アプリケーション側の pom.xml や build.gradle を更新しても、実行時にはサーバー同梱の CXF が読み込まれることがあります。サーバー同梱版を利用している構成では、サーバーのパッチ適用やモジュール差し替えなど、各サーバーのドキュメントに沿った更新が必要です。実行時にどのバージョンの CXF が読み込まれているかを確認したうえで対処することをおすすめします。

すぐ動ける暫定回避策（アップグレード前）

アップグレードをすぐに適用できない場合に、攻撃面を下げるための暫定策を優先度順に整理します。いずれも恒久的な対処ではなく、根本対処（4.2.2 / 4.1.7 へのアップグレード）までのつなぎとして位置づけることをおすすめします。

利用有無の切り分けと未使用モジュールの除去

最も効果が大きいのは、そもそも cxf-integration-jca / JCA RAR 構成を使っていないかを切り分け、使っていなければ対象モジュールを除去する ことです。先の確認コマンドで cxf-integration-jca が依存ツリーに現れない、あるいは JCA RAR としてのデプロイがないと確認できれば、本脆弱性の影響を実質的に排除できます。不要なモジュールが依存に含まれている場合は、依存から外す、または該当の .rar をデプロイ対象から除くことを検討します。

ra.xml と起動パラメーターへのアクセス制限

本脆弱性は、攻撃者が ra.xml や起動時のアクティベーションパラメーターを操作できることを前提としています。裏を返せば、これらを書き換えられる経路を絞ること が直接的な緩和につながります。具体的には、ra.xml を含むデプロイメント記述子のファイル権限の見直し、デプロイ用ディレクトリへのアクセス制御、デプロイパイプライン（CI / CD）の権限管理と変更レビューの徹底が挙げられます。記述子や起動パラメーターは、信頼できる管理者・プロセスのみが変更できる状態に保つことをおすすめします。

外部への LDAP / RMI 通信の遮断

JNDI 注入は、外部の LDAP や RMI といったディレクトリサービスへの参照解決を伴うことが多いため、アプリケーションサーバーからの外向き通信を制限することも有効です。業務上必要な宛先を除き、LDAP（389 / 636）や RMI（1099 など）への外向き通信を遮断する egress フィルタリングを設けることで、悪用の成立を難しくできます。

JNDI 関連の JVM 設定（多層防御）

比較的新しい JDK では、JNDI 経由で任意の URL からクラスを読み込む挙動が既定で無効化されています。JDK 6u211・7u201・8u191・11.0.1 以降では、LDAP・RMI いずれの経路でもリモートコードベースからの読み込みが既定で抑止され、OpenJDK では com.sun.jndi.ldap.object.trustURLCodebase の既定値が false に設定されています。多層防御として、以下を明示的に指定して固める方法があります。

-Dcom.sun.jndi.ldap.object.trustURLCodebase=false
-Dcom.sun.jndi.rmi.object.trustURLCodebase=false
# 対応する JDK では、シリアライズデータの信頼も無効化できます
-Dcom.sun.jndi.ldap.object.trustSerialData=false

ただし、この設定だけで安全になるわけではありません。クラスパス上に存在する ObjectFactory 系のクラス（ガジェット）を悪用する経路は、リモートコードベースの読み込みを無効化していても残り得ます。そのため、JVM 設定はあくまで多層防御の一部として扱い、根本対処までの暫定措置と位置づけることをおすすめします。

これらの暫定策は攻撃面を下げるものであり、恒久的な対処は 4.2.2 / 4.1.7 へのアップグレードです。アップグレードが可能になった段階で、速やかに適用することをおすすめします。

踏んでしまった場合の対応（検知と初動）

侵害が疑われる場合は、まず兆候を確認し、確証が得られなくても初動対応を進めることが被害の抑制につながります。侵害の有無を確定するには専門的な調査が必要なため、以下は兆候の確認と初動の流れとして整理します。

ログと通信から侵害の兆候を確認する

複数の観点から、不審な挙動の有無を確認します。

 アプリケーションサーバー / CXF のログ:
想定外の JNDI ルックアップ、ra.xml や起動パラメーターの変更、未知のクラスのロード、例外の急増がないか。

 ネットワーク:
アプリケーションサーバーからの想定外の外向き通信（LDAP・RMI・DNS）や、未知の宛先への接続がないか。

 プロセス・システム:
java プロセスからの想定外の子プロセス起動（外部コマンドの実行）、新規に作成された不審なファイル、起動スクリプトや cron の改変、リソース使用量の急増（不正なマイニング等の兆候）がないか。

 デプロイ資産:
ra.xml やデプロイメント記述子の改ざん、デプロイパイプラインへの不審な変更がないか。

初動対応（隔離・保全・復旧）の流れ

兆候が確認された場合の初動は、おおむね次の流れになります。

自組織での対応が難しい場合は、CSIRT や専門事業者への相談を検討することをおすすめします。

まとめ

CVE-2026-50633 は、Apache CXF の JCA 統合モジュールにおける JNDI 注入の脆弱性で、条件が揃うとコード実行に至り得ます。影響は cxf-integration-jca を用いた JCA RAR 構成に限定され、根本対処は 4.2.2 / 4.1.7 へのアップグレードです。すぐに更新できない場合は、利用有無の切り分けや ra.xml のアクセス制限、外部通信の遮断が暫定的な回避につながります。

• 影響は cxf-integration-jca を用いた JCA RAR 構成に限定
• 一般的な JAX-WS / JAX-RS 構成は対象外の可能性が高い
• 根本対処は 4.2.2 または 4.1.7 へのアップグレード
• 依存確認は mvn dependency:tree や gradle dependencyInsight
• 最優先の暫定策は未使用モジュールの除去
• ra.xml の改変経路の制限と外部通信の遮断が緩和策
• 侵害が疑われる場合はログと外向き通信から兆候を確認

以上、最後までお読みいただきありがとうございました。