Axis2の脆弱性CVE-2026-66713は危険度9.8、既定では無効な機能が対象

2026年7月28日、SOAP形式のWebサービスを作るためのJava製ソフト「Apache Axis2/Java」に、脆弱性 CVE-2026-66713 が登録されました。米国の脆弱性データベースNVDでの表示は危険度9.8（10点満点、Critical＝緊急）。ログインもパスワードも不要で、サーバー上で好きなプログラムを走らせられる、という区分です。

数字だけ見れば最悪クラスです。ただ、開発元であるApache Software Foundationが公開したアドバイザリには、この脆弱性が成立する条件がはっきり書かれています。「Tribesクラスタリング」という機能を有効にしている場合のみ。そしてこの機能は初期設定では無効です。Apache自身が付けた深刻度の表記は「low（低）」でした。

つまり、9.8という数字を見て青くなる必要がある人と、設定ファイルを1行確認して終われる人がいます。まず自分がどちら側なのかを判定する手順を示し、そのうえで該当した場合に何が起きるのか、修正版はどれなのか、なぜ「9.8」と「低」が並んでしまうのかを順に整理します。

公表された内容と、付けられた数字

CVE-2026-66713: クラスタ通信の受け口で、送られたデータがそのまま実行される

Apache Axis2/Java には、複数台のサーバーで同じサービスを動かして状態を揃えるための「クラスタリング」機能があります。その通信部分に使われていたのが、Tomcat由来の Tribes というライブラリです。

Axis2 はこのTribes経由で届いたメッセージを、Javaの「オブジェクト直列化」という仕組みで元のデータ構造に復元していました。復元の入口は org.apache.axis2.clustering.tribes.Axis2ChannelListener#messageReceived です。ここに検証が入っていなかったため、攻撃者が細工したデータを送ると、復元の過程でそのまま任意のプログラムが動いてしまう——これがCVE-2026-66713の中身です。ApacheのCVEレコードの記述も同じ内容で、「クラスタリングポートに到達できる、認証を持たない遠隔の攻撃者」が条件として明記されています。

Webサービスの入口（HTTPのSOAPエンドポイント）ではなく、サーバー同士が話すための別のポートが入口である点が、この脆弱性の性格を決めています。クラスタリングを動かしていなければ、そのポートはそもそも開いていません。

自動巡回が先に拾い、そのあとで人が来る

この穴を最初に拾うのは、インターネット上のサーバーを機械的に片っ端から叩いて、反応があった機器だけを後で人間が調べる、量産型の侵入業者です。企業を狙い撃ちにする高度な集団ではありません。CVE番号が公開された翌日から、その番号に対応する探索プログラムを回すのが彼らの仕事です。今回のように「特定のポートが開いていて、そこに投げたデータの返り方で判別できる」タイプは、この機械的な探索と相性が良いところがあります。

クラスタ通信の受け口が応答を返したサーバーでは、サーバーの中に自分用の出入口（バックドア）を仕込み、そのサーバーを操れる状態を確保して、その権利を別の攻撃者に売るという一連の作業が始まります。買い手が身代金要求型ウイルスの運用者なら、社内ネットワークの奥へ進む足場として使われます。買い手が情報を売る業者なら、そのサーバーが持っているデータベースの接続情報を抜くところから始まります。

業務システムの連携を担うサーバーが乗っ取られたとき、何が起きたように見えるかは立場によって違います。そのシステムを使っている社員や取引先にとっては、業務が止まる・伝票の内容が書き換わるといった形で表に出ます。運用している側にとっては、Axis2が動いているサーバーの権限がまるごと相手の手に渡ることを意味します。Axis2は多くの場合、基幹系のデータベースと直接会話する位置に置かれているため、そこを取られると「Webサーバー1台の被害」では終わりません。逆に言えば、だからこそ次の節の判定を先に済ませる価値があります。

自分の環境は対象なのか、どこを見れば分かるのか

判定はAxis2の設定ファイル axis2.xml 1か所で終わります。置き場所は配置形態によって変わりますが、TomcatにWARを置いている一般的な構成なら WEB-INF/conf/axis2.xml、スタンドアロンなら conf/axis2.xml です。このファイルの中の <clustering> という要素を探します。

配布物に最初から入っている状態は、Axis2のリポジトリにある axis2.xml で確認できます。次の1行です。

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

見るのは末尾の enable だけです。enable="false" のままなら、CVE-2026-66713は成立しません。enable="true" に書き換えられている場合、あるいは <clustering> 要素ごとコメントアウトが外されて有効化されている場合が、対象です。

この既定値が「いつからそうなのか」も確認しました。1.7.9・1.8.2・2.0.0 の各タグで、同じ行がいずれも enable="false" でした。つまり2018年公開の1.7.9までさかのぼっても、配布時点では無効です。誰かが意図して有効化していない限り、当たりません。

有効化されていた場合、同じ <clustering> の中にある次のパラメータが、攻撃者から見た入口の位置になります。

実際にクラスタを組む際は localMemberHost をサーバーの実アドレスに書き換えることになるので、危険度が本当に上がるのは「クラスタリングを有効化し、かつ4000番ポートが到達可能な範囲に開いている」状態です。ここまで揃っていれば、9.8という数字はそのまま自分の環境の話になります。逆に、ポートが同一ホスト内や閉じたセグメントに限られているなら、当面の対応の緊急度は下がります。

なぜ「9.8」と開発元の「低」が並んでしまうのか

同じ脆弱性に真逆の評価が付いているように見えるので、内訳を分解しておきます。この数字の出どころを取り違えると、判断の重みづけを間違えます。

CVSSという計算式は、「攻撃が成立したとき、どれだけ壊れるか」を測る道具です。前提条件が揃う確率は計算に入りません。認証なしで遠隔から任意のプログラムが動く、という一点を入力すれば、機能が既定で無効かどうかに関係なく9.8が出ます。つまりこの9.8は「成立したときの破壊力の上限」であって、「あなたが危ない確率」ではないということです。

一方でApacheが「低」と書いたのは、既定で無効な機能が条件だという実運用上の判断が入っているためです。ただし注意したいのは、「低」は「該当環境でも軽い」という意味ではない点です。条件が揃った環境では、アドバイザリに書かれているとおり認証なしで任意コード実行に至ります。「多くの人は対象外」と「対象の人には最悪級」が同時に成り立っている、と読むのが正確です。

なお、CISAは同時にSSVCという別の指標も付けており、その内訳は「悪用: 確認されていない／自動化: 可能／技術的影響: 全面」でした。悪用実績はまだ無い、というのが7月28日時点の公的な見立てです。悪用が始まった脆弱性はCISA KEVのリストに載るので、そこに現れるかどうかが今後の分かれ目になります。

この「スキャナには9.8と出るが開発元評価は低」という構図自体は、Apache製品では珍しくありません。同じ月にApache Tomcatでも同型のずれが起きています。数字を見たら必ず発行元の一次記述に戻る、という手順を癖にしておくと消耗が減ります。

影響を受けるバージョンと、修正版はどれか

影響範囲は「2.0.0 まで」、つまり2.0.1より前のすべてのバージョンです。修正版は2.0.1で、こちらはMaven Centralの公開記録とAxis2のダウンロードページの双方で 2026年5月17日公開と確認できました。アドバイザリより2か月以上前に、修正版がすでに出ていたことになります。

修正の中身はGitHub上のコミットで読めます。コミットメッセージは「AXIS2-6097 Remove Clustering feature」。変更は115ファイル、追加6行に対して削除10,692行。危険な復元処理に検証を足したのではなく、クラスタリング機能をまるごと捨てるという決着でした。2.0.1のリリースノートにも「Removed Features」として同じ項目が載っています。

日付にも目を向けておきたいところで、このコミットが書かれたのは2025年9月9日。CVEが登録される10か月以上前です。もともとセキュリティ修正として書かれたものではなく、保守しきれない機能を落とす整理の一環だったところに、後から脆弱性報告が届いて「その整理がそのまま修正版になっていた」という順序に見えます。公表より先に修正済みの版が世に出ていたのは、利用者にとっては単純に助かる話です。

「2.0.1へ上げる」が簡単ではない事情

ただ、影響範囲が「2.0.0 まで」で修正版が「2.0.1」だけ、という形は、古い版を使い続けている現場にとってはやや厳しい構図です。1.x 系に対する修正版は出ていません。

2.0.1のリリースノートによると、この系列は OpenJDK 17 が最低要件（対応は17・21・25）です。ひとつ前の2.0.0のリリースノートでは javax から jakarta への名前空間移行が行われ、想定環境も Tomcat 11 / WildFly 32 に上がっています。さらに 2.0.1 では WSDL 2.0・OSGiモジュール・JiBXデータバインディングも落とされました。

Java 8 の上で 1.8.2（2022年7月公開が最後）や 1.7.x を動かしている社内システムから見ると、「2.0.1へ上げる」はパッチ適用ではなく移行プロジェクトです。Javaのバージョン、パッケージ名の書き換え、Tomcat本体の更新までまとめて動くことになります。

だからこそ、判定を先にやる意味があります。enable="false" のままなら、この移行を今週中に始めなければならない理由は本件には無い、と言えます。逆に有効化している環境では、移行を待つのではなくまず設定を無効化して4000番ポートを閉じるという順序になります。機能を使い続ける必要があるなら、Tomcat側のクラスタリングやロードバランサでの振り分けなど、Axis2の外側で同じ役割を持たせる設計変更を検討することになります。Axis2からこの機能が消えた以上、恒久策はそちら側です。

依存関係スキャンでは見つからない可能性がある

運用面でひとつ注意点があります。この脆弱性には GHSA-fhh8-qfj4-g948 というGitHub Advisoryが7月28日に登録され、深刻度もCritical 9.8と表示されています。ところが同じページには「Affected versions: Unknown」「Patched versions: Unknown」と出ており、対象パッケージが登録されていないため Dependabot のアラートは出ないと明記されています。

NVD側も同様で、7月28日時点のステータスは「Awaiting Analysis」、対象バージョン範囲を表す CPE も未登録です。「依存関係スキャナが何も言ってこないから大丈夫」という判断が、本件では成り立ちません。pom.xml に org.apache.axis2 が入っているかどうかは、自分で確認する必要があります。この手の「登録が追いつかず自動検知の網から落ちる」状況は、依存ライブラリを追いかける仕組みを持っていないと拾えないので、OSSの依存関係を継続的に見る仕組みを別に持っておく価値があります。範囲が登録されれば自動検知は追いついてくるはずなので、そこも次回の確認対象です。

JVNにもJPCERT/CCにも登録がない

2026年7月29日時点で調べた範囲では、CVE-2026-66713について国内の公的機関からの発信は見つかりませんでした。

同じ日にApacheから公表されたTomcatのDoS（WebSocketのチャットサンプルで資源を食い潰されるもの）は、こちらはJVNに登録されました。対象はTomcat 11.0.0-M20〜11.0.24 / 10.1.24〜10.1.57 / 9.0.89〜9.0.120で、修正は11.0.25・10.1.58・9.0.121。Tomcat公式のセキュリティ情報には、サンプルアプリを削除する運用ガイドに従っていれば影響を受けない旨も書かれています。詳細はTomcatの脆弱性をまとめたページで扱うため、ここでは触れるにとどめます。

Axis2側が国内で拾われていないのは、後述するように利用実態が見えにくい製品だからだと思われます。裏を返せば、「うちのシステムにAxis2が入っているかどうか」を教えてくれる人は、社外にはいないということでもあります。

同じ「Javaの復元処理」でやられる脆弱性が続いている

CWE-502は、プログラムがネットワークから受け取ったデータを元のかたちに戻すとき、そのデータの中身を疑わずに処理してしまう問題を指します。Javaのオブジェクト直列化は「戻す」過程でクラスの初期化処理が走るため、細工されたデータを渡されるとそこで攻撃者のコードが動く余地が生まれます。20年近く指摘され続けている系統で、いまも新しい番号が付き続けています。

直近では、Javaのネットワーク処理の土台として広く使われているライブラリでApache MINAのCVE-2026-47065が公表されています。あちらは許可リスト方式の防御を回し込まれた事例で、同じ穴を三度ふさぎ直している経緯まで含めて、この系統の厄介さが出ています。

そして今回のAxis2と同じ2026年7月28日、IBMも CVE-2026-14512 を公表しました。WebSphere Application Server 9.0 および 8.5 traditional における「認証前の危険な復元処理」で、IBM自身が付けたCVSSは9.8です。こちらは条件付きではなく、認証を通す前の段階が対象です。IBM製品を並行して見ている方は、IBM製品の脆弱性をまとめた記事も併せて確認してください。

Apache系のRPC・Webサービス実装という括りでは、Apache Thriftの脆弱性や、HTTP/2の処理で資源を食い潰されるApache HTTPサーバのDoSも同時期に動いています。「Javaで組んだサーバー間通信の受け口」を持つ製品全般が、いま順番に洗われている状況です。Nettyのように土台側で見つかったケースも同じ流れに入ります。

Axis2はいまどれくらい使われているのか

正直に書くと、Axis2は今から新規採用される製品ではありません。SOAP形式のWebサービスがシステム間連携の標準だった2000年代半ばから後半にかけて、Javaでの実装として広く入りました。その後、外部公開APIの主流はRESTとJSONに移り、Axis2の名前を新しい案件で聞くことはほとんどなくなりました。

それでも動いているものは動いています。当時作られた社内システムや、金融・製造・公共の基幹系まわりで組まれた連携基盤は、SOAPのインターフェースを保ったまま残っていることが珍しくありません。バージョンの公開履歴を見ると、1.7系の最終版が2018年、1.8系の最終版が2022年7月、そして2.0系が2025年から——という間隔です。長い停滞のあとに大きく作り替えられた製品の輪郭が見えます。

国内の知名度という意味では、TomcatやWebSphereと比べれば桁違いに低い製品です。「Axis2 脆弱性」で検索する人の数も多くはないでしょう。ただ、この種の製品の怖さは知名度の低さそのものにあります。10年前に作った連携サーバーの中で今日も動いていて、担当者が異動して誰も構成を把握していない——という置かれ方が起こりやすい位置にいます。JVNも報道も動かない以上、気づく契機は自社の棚卸しだけです。

もう一点、Axis2は単体で使われるだけでなく、他の製品の内部に取り込まれていることもあります。今回のクラスタリング設定の初期値にある wso2.carbon.domain という文字列は、Axis2をエンジンとして使っていた別の製品群の名残です。「Axis2を入れた覚えはない」＝「入っていない」ではないので、依存ライブラリの一覧まで見る価値があります。

まだ公開されていない情報

この記事は上記を推測で埋めていません。埋まった時点で追記します。

2.0.1へ上げられない場合を含めた手順

最初にやるのは、Axis2が動いている全ホストで axis2.xml を開き、<clustering> の enable がどうなっているかを見ることです。ここが false なら、本件についての緊急対応はありません。バージョン更新は通常の計画に載せて構いません。

true だった場合は、クラスタリングを本当に使っているのかを確認します。使っていないのに有効になっているなら、false に戻してAxis2を再起動すれば、それで穴は閉じます。使っている場合は、4000番（あるいは localMemberPort に設定した値）のTCPポートが、どこから到達できる状態になっているかを確認してください。クラスタを構成するノード以外から届く必要はないので、ファイアウォールやセキュリティグループで送信元を絞るのが、移行より先に効く手当てです。

そのうえで、2.0.1への移行を計画に入れます。前述のとおりJavaとTomcatの版まで動く話になるため、期間は素直に見積もったほうがよいでしょう。クラスタリングの代替をどこで持つかを設計として決めるのが、この移行の実質的な中身になります。

最後に、Axis2そのものを使っていないつもりの環境でも、依存ライブラリの一覧に org.apache.axis2 が入っていないかは一度見てください。GitHub Advisory側にパッケージ範囲が登録されていない現状では、自動検知に頼れません。

よくある質問

危険度9.8と出ていますが、今すぐ止めるべきですか

まず axis2.xml の <clustering enable="..."> を確認してください。false なら、この脆弱性を理由にサービスを止める必要はありません。9.8という数字は「成立したときの破壊力」の指標であって、成立条件の確率は含んでいません。

クラスタリングを有効にした覚えがありません。それでも確認は必要ですか

確認したほうが確実です。設定ファイルは構築時のベンダーや、途中で入った運用担当が書き換えている可能性があります。10年前の構築時に負荷分散の一環として有効化され、その後は誰も触っていない、という形が最もありそうなパターンです。

1.8.2を使っています。1.8.3のような修正版は出ますか

一次情報で案内されている修正版は2.0.1のみです。1.x系へのバックポートについてはアドバイザリにもリリースノートにも記載がありません。2.0.1で機能そのものが削除されたという決着の仕方からすると、1.x向けの個別修正が出る見込みは高くないと考えられます（これは本記事の推測です）。

2.0.1に上げるとクラスタリングは使えなくなるのですか

使えなくなります。2.0.1ではクラスタリング機能が削除され、axis2.xml から <clustering> 要素そのものが消えています。この機能に依存している構成では、Axis2の外側で同じ役割を持たせる設計変更が必要です。

Tomcatも一緒に更新すべきですか

本件はAxis2側の問題で、Tomcat本体を更新しても直りません。ただし同じ7月28日にTomcat側でもCVE-2026-66299が公表されているので、定例更新の対象として別途確認する価値はあります。

まとめ

Apache Axis2/Java 2.0.0 までのバージョンに、認証なしで任意のプログラムを実行されうる脆弱性CVE-2026-66713が登録されました。NVDでの表示は9.8（Critical）ですが、この数字を付けたのはCISAで、開発元Apacheの表記は「低」です。成立条件は既定で無効なTribesクラスタリングが有効になっていることで、判定は axis2.xml の1行を見れば終わります。

修正版2.0.1はアドバイザリより2か月以上前の2026年5月17日に公開済みで、クラスタリング機能をまるごと削除するという形で決着しています。修正の元になったコミットは2025年9月のもので、もともとセキュリティ修正として書かれたものではありませんでした。ただし2.0.1はOpenJDK 17必須・jakarta移行済みの系列なので、古い環境からの更新は移行プロジェクトの規模になります。

EPSSは未算出、CISA KEVにも未掲載で、悪用の報告はありません。GitHub Advisoryに対象パッケージ範囲が未登録のため、依存関係スキャンでは検知されない状態です。国内ではJVN・JPCERT/CC・IPAいずれも本件を取り上げておらず、日本語の情報もまだありません。だからこそ、Axis2が動いているシステムを持っている組織は、自分で棚卸ししてください。9.8の数字に慌てる必要はありませんが、条件に当てはまる少数の環境では、その数字がそのまま降ってきます。

参照元

• ▸ oss-security - CVE-2026-66713: Apache Axis2/Java: deserialization of untrusted Data（Apache公式アドバイザリ、2026年7月28日）
• ▸ Apache Mailing List - CVE-2026-66713 アナウンススレッド
• ▸ NVD - CVE-2026-66713（2026年7月28日公開）
• ▸ CVE.org - CVE-2026-66713 レコード
• ▸ GitHub Advisory Database - GHSA-fhh8-qfj4-g948
• ▸ GitHub - AXIS2-6097 Remove Clustering feature（修正コミット）（2025年9月9日）
• ▸ GitHub - axis2.xml（v2.0.0、clustering要素の既定値）
• ▸ Apache Axis2 2.0.1 Release Notes
• ▸ Apache Axis2 2.0.0 Release Notes
• ▸ Apache Axis2 - Releases（2.0.1 は2026年5月17日公開）
• ▸ Maven Central - org.apache.axis2:axis2 バージョン一覧
• ▸ CWE-502: Deserialization of Untrusted Data
• ▸ CISA - Known Exploited Vulnerabilities Catalog（2026年7月29日確認時点で未掲載）
• ▸ FIRST - EPSS（2026年7月29日時点でスコア未算出）
• ▸ JVNVU#99139115 - Apache Tomcat の WebSocket チャットサンプルにおけるDoSの脆弱性（2026年7月29日）
• ▸ Apache Tomcat 11 vulnerabilities（CVE-2026-66299）
• ▸ IBM Support - CVE-2026-14512（WebSphere Application Server）（2026年7月28日）