Apache Axis2に未認証RCE 修正版は機能ごと削除

【更新 2026-08-02】本記事を見直し、修正しました。主な修正点：2.0.0 への移行に伴う非互換として挙げていた「必要な OpenJDK の下限が 17 に引き上げ」を、各版の実際の要件（1.8 系＝Java 8／2.0.0＝Java 11／更新先の 2.0.1＝Java 17）に訂正しました。

Apache Axis2/Java のクラスタリング機能に、認証なしでリモートコード実行が可能な脆弱性 CVE-2026-66713 が公表されました。攻撃が成立する条件は「Tribes ベースのクラスタリングを有効にしていること」で、既定では無効です。ただし有効にしている環境では、クラスタリング用のポートに到達できるだけで任意のコードを実行されます。

注意点は3つあります。修正版 2.0.1 はクラスタリング機能に手を入れたのではなく機能そのものを削除して対処していること、旧 1.8 系に修正版が提供されていないこと、そして開発元の深刻度評価は「低」である一方、CISA は CVSS 9.8（緊急）を付けていることです。

この記事でわかること

• CVE-2026-66713 の内容と、攻撃が成立する条件
• 自社が対象かどうかを判定する手順（設定の既定値一覧つき）
• 開発元「低」と CISA「9.8」に評価が割れた理由と、どちらで判断すべきか
• 「修正＝機能削除」「旧系列に修正版なし」が現場に迫る意思決定

何が起きたのか

Apache Axis2/Java は、Java で SOAP ベースの Web サービスを実装・実行するためのエンジンです。同じ用途の Apache CXF と並び、社内システム間の連携基盤として長く使われてきました。今回の脆弱性は、その中でも複数ノードを束ねるクラスタリング機能にあります。

どこが壊れているのか

該当箇所は Axis2ChannelListener クラスの messageReceived() メソッドです。クラスタのチャネルが受信したバイト列を、そのまま Java オブジェクトとして復元（デシリアライズ）しています。Java のデシリアライズは復元の過程で対象クラスのコードを動かすため、細工したオブジェクトを送り込まれると任意のコードが実行されます。

公開されているソースコードを読むと、このメソッドには「クラスタの初期化が完了していなければ受信メッセージを破棄する」という防御が入っています。ただしその判定は、デシリアライズを実行した後に置かれています。つまり「まだクラスタを組んでいる途中だから安全」とは言えません。バイト列を復元した時点で決着がついているためです。

Tomcat のクラスタリングの話ではありません

Axis2 のクラスタリングは、Tomcat のクラスタリングライブラリである Tribes（tomcat-tribes）を部品として利用しています。そのため「Tomcat のクラスタが危ない」と読み違えられやすいのですが、欠陥があるのは Tribes 本体ではなく、Axis2 側が用意した受信リスナの実装です。Tomcat 単体のクラスタ構成は本件の対象ではありません（Tomcat 本体の脆弱性についてはこちら）。

自社は対象か（判定の手順）

本件の該当判定はバージョン番号だけでは終わりません。バージョンは 2.0.0 以前がすべて範囲に入る一方、実際に影響を受けるかどうかは設定で有効にしているかの二値で決まります。次の3段階で確認します。

1. そもそも Axis2 を使っているか

Axis2 は JAR ファイルとして業務アプリケーションの WAR に同梱される形が一般的で、OS の「インストール済みソフトウェア一覧」には出てきません。ファイル名で探します。

find / -name "axis2-kernel*.jar" -o -name "axis2-clustering*.jar"

クラスタリング機能は axis2-clustering という独立した成果物として提供されています。この JAR が存在しなければ、その環境にクラスタリング機能は組み込まれていません。

2. axis2.xml でクラスタリングが有効か

設定ファイル axis2.xml（配備形態にもよりますが WEB-INF/conf/axis2.xml に置かれることが多い）の clustering 要素を確認します。配布物の既定値は次のとおりです。

<clustering class="org.apache.axis2.clustering.tribes.TribesClusteringAgent" enable="false">

enable が false のままなら対象外です。true に変更されていれば該当します。

3. クラスタリングポートが待ち受けているか

配布物の既定値は次のとおりです。実環境では変更されている可能性が高いので、あくまで「どこを見るか」の目安として使ってください。

ss -ltnp | grep 4000

既定の待ち受けアドレスは 127.0.0.1 ですが、複数台でクラスタを組む以上、実運用では他ノードから届くアドレスに変更されているはずです。「実際にクラスタとして動いている」＝「そのポートは他ホストから到達できる状態にある」と考えるのが安全側の見方です。どこまで到達できるかは、ネットワーク側の制御次第になります。

深刻度が「低」と「9.8」に割れた理由

NVD 本体による評価は執筆時点で未実施（Awaiting Enrichment）で、表示されている 9.8 は CISA-ADP による暫定評価です。

ベクタを事実と突き合わせると、両者は矛盾していません。開発元は「既定で無効であり、クラスタリング用のポートは信頼できるネットワークにのみ置かれる」という前提に立って全体のリスクを低いと判断しています。CISA-ADP は「有効化されており、攻撃者がポートに到達できる」場合の技術的な影響をそのまま数値化しており、認証も利用者操作も不要（PR:N/UI:N）で任意コード実行に至る以上、この数値自体は妥当です。

実務上の意味は明快です。スコアの中間を取って「中くらいの優先度」として扱う判断には意味がありません。クラスタリングを有効にしていなければ影響はなく、有効にしていれば緊急、という二値だからです。CVSS を起点にした脆弱性管理を運用している組織ほど、まず判定を済ませることが優先されます。

修正版は「機能ごと削除」されている

本件でいちばん重い論点はここです。修正版 2.0.1（2026年5月17日公開）は、クラスタリング機能の欠陥を修正したのではなく、機能そのものを削除しています。

削除の判断は CVE の公表よりかなり前に行われていました。公開されている経緯によれば、利用者メーリングリストで org.apache.axis2.clustering パッケージを削除する旨を告知したものの反応がなく、そのまま削除に至っています。実際のコミット（AXIS2-6097 Remove Clustering feature）は115ファイル・約10,700行の削除でした。

したがって、クラスタリングを使っている環境にとって 2.0.1 は「脆弱性が直ったバージョン」ではなく「その機能が無くなったバージョン」です。更新すれば脆弱性は解消しますが、同時にクラスタ構成も成り立たなくなります。状態の共有やノード管理をこの機能に頼っていた場合は、アプリケーションサーバ側やロードバランサ側で同等の機能をどう実現するか、代替設計を検討する作業が発生します。

旧 1.8 系に修正版はない

影響範囲は 2.0.0 以前のすべてで、長く使われてきた 1.8 系（1.8.2 が最終）も含まれます。しかし1.8 系向けの修正リリースは提供されていません。示されている対処は 2.0.1 への更新のみです。

これが軽い作業でない点に注意が必要です。2.0.0 は 1.8 系からの移行にあたり、次の非互換を伴っています。

• javax.* から jakarta.* への全面移行（Jakarta EE 対応）
• 必要な OpenJDK の下限が引き上げられている（1.8 系は Java 8、2.0.0 は Java 11、更新先となる 2.0.1 は Java 17 が必須）
• HTTP クライアントが HttpClient 4 から HttpClient 5 へ変更（axis2.xml の設定変更が必要）
• WSDL2Java で生成済みのソースはそのままでは動作しない可能性があり、再生成が必要になる場合がある
• OSGi 対応・Eclipse プラグイン・先行的な Basic 認証などの機能が削除

つまり「パッチを当てる」ではなく「アプリケーションを移植する」規模の話になります。しかも本件は、クラスタリングを使っていなければそもそも影響がありません。移植の緊急度は判定結果によって大きく変わります。ここを確認せずに「CVSS 9.8 だから至急対応」と現場へ投げると、不要な大工事を始めてしまいかねません。

現場目線の課題

率直なところ、この種の脆弱性がいちばん厄介なのは技術的な難しさではなく、「うちで使っているのか誰も知らない」という点です。Axis2 を使った業務アプリケーションの多くは数年から十数年前に受託開発されたもので、当時の設計を把握している担当者が社内に残っていないことは珍しくありません。

クラスタリングを有効にしたかどうかの答えは、当時の開発ベンダーが書いた axis2.xml の中にしかありません。ソフトウェアの一覧にも資産台帳にも出てこないので、脆弱性情報を眺めているだけでは気づけない。結局、アプリケーションサーバに入ってファイルを探すという地道な作業になります。ここは自動化しにくく、限られた人員でどこまで手を伸ばすか、いつも悩ましいところです（同じ構図はライブラリの「見えない依存」の棚卸しでも繰り返し起きています）。

もう一つ引っかかるのは、開発元自身は2025年9月の時点で「セキュリティ上疑わしい」と判断して削除を決めていたのに、CVE として広く周知されたのは約10か月後だった、という時間差です。利用者メーリングリストへの告知はありましたが、購読していない利用者には届きません。脆弱性情報の入口を CVE や公的機関の注意喚起だけに置いていると、こうした「先に直っていたもの」は構造的に拾えません。利用しているミドルウェアについては、リリースノートまで目を通す担当を決めておくのが現実的な備えになります。

なお、Axis2 のクラスタリング設定の既定ドメイン名が wso2.carbon.domain であることからも分かるとおり、この機能は製品に組み込まれた形でも使われてきた経緯があります。自社開発のアプリケーションだけでなく、Axis2 を内部で利用する製品を導入している場合は、その製品ベンダーの見解も確認してください。どの製品がどう影響を受けるかは、公表情報からは確認できません。

情シスはどうすべきか

1. まず該当判定を行う。Axis2 の JAR があるか → axis2.xml の enable 属性 → クラスタリングポートの待ち受け、の順で確認します。対象外と分かれば、それ以上の作業は不要です。
2. 有効だった場合は、先にネットワーク側で塞ぐ。クラスタリング用の TCP ポートとマルチキャストが、クラスタを構成するノード以外から到達できない状態かを確認します。更新の可否にかかわらず、これは適用後も残しておくべき常設の対策です。
3. そのうえで移行を計画する。2.0.1 への更新は機能削除とメジャーアップグレードを同時に伴うため、作業窓・切り戻し・代替設計を含めた案件として扱う必要があります。開発ベンダーへの照会が最初の一歩になることが多いはずです。

「そもそも自社に何が入っているか分からない」という段階でつまずく場合は、公的な枠組みから入るのが近道です。IPA の中小企業の情報セキュリティ対策ガイドラインは、情報資産の把握から対策の進め方までを体系的に示しており、社内説明の下敷きとしても使えます。SOAP を含む Web サービスを外部に公開している場合は、IPA の安全なウェブサイトの作り方も併せて参照してください。

あわせて、開発委託先への地道な働きかけも効きます。「利用しているミドルウェアとそのバージョン、有効化した任意機能を納品物として明示してもらう」ことを次回以降の調達要件に入れておくだけで、次に同じ形の脆弱性が出たときの調査時間は大きく変わります。

まとめ

• CVE-2026-66713 は Apache Axis2/Java 2.0.0 以前のクラスタリング機能（Tribes）にある、認証不要のリモートコード実行です。既定は無効で、該当判定はバージョンではなく axis2.xml の設定で決まります。
• 開発元の「低」と CISA-ADP の CVSS 9.8 は矛盾しません。有効にしていなければ影響なし、有効なら緊急という二値なので、中間を取る判断に意味はありません。
• 修正版 2.0.1 はクラスタリング機能を削除して対処しており、旧 1.8 系に修正版はありません。更新は Jakarta EE 移行を伴う移植作業になるため、まず判定、次にネットワーク側の遮断、そのうえで移行計画、という順序が現実的です。

出典

• oss-security: CVE-2026-66713: Apache Axis2/Java: Deserialization of untrusted data in Tribes-based clustering
• NVD – CVE-2026-66713
• Apache Axis2/Java – Releases
• Apache Axis2 2.0.1 Release Notes
• Apache Axis2 2.0.0 Release Notes
• GitHub: AXIS2-6097 Remove Clustering feature（修正コミット）
• Security NEXT: 「Apache Axis2/Java」のクラスタリング機能に脆弱性