Apache ActiveMQのClassicエディションに、13年以上にわたって見過ごされてきたリモートコード実行（RCE）脆弱性が発見された。CVSSスコア8.8と高深刻度に分類されるCVE-2026-34197は、エンタープライズ、Webバックエンド、政府系システムなど幅広い現場で稼働するJavaメッセージブローカーを直撃する。パッチはすでにリリースされているが、ActiveMQが過去に実際の攻撃対象となってきた経緯を踏まえると、対応の優先度は極めて高い。

脆弱性の仕組み——「無害なパーツ」が組み合わさると凶器になる

この脆弱性の核心は、Jolokia管理API経由で公開されている addNetworkConnector というブローカー関数にある。攻撃者はこの関数を悪用し、外部のSpring XMLファイルをActiveMQに読み込ませることができる。ブローカーは初期化処理の中でそのXMLを解釈・実行するため、結果として任意のシステムコマンドをサーバー上で走らせることが可能になる。

通常、Jolokia APIへのアクセスには認証が必要だ。しかし、バージョン6.0.0〜6.1.1については別の既知の脆弱性（CVE-2024-32114）によってAPIが認証なしで公開されており、この範囲では認証不要のRCEが成立してしまう。

影響を受けるバージョンは以下のとおり：

  • ActiveMQ Classic 5.19.4未満のすべてのバージョン
  • ActiveMQ Classic 6.0.0〜6.2.3

修正済みバージョンは 5.19.4 および 6.2.3。該当バージョンを使っている場合は即刻アップデートを検討してほしい。

なぜ13年間気づかれなかったのか

今回の発見で特筆すべきは、脆弱性そのものと同じくらい「どうやって見つかったか」だ。Horizon3のリサーチャーであるNaveen Sunkavally氏は、AIアシスタントに「いくつかの基本的なプロンプトを投げただけ」でこの問題を特定したと述べている。「80%はAI、残り20%は人間によるラッピング」という表現が印象的だ。

Jolokia、JMX、ネットワークコネクター、VMトランスポートという各コンポーネントは、それぞれ単独では仕様どおりに動作する。問題は「組み合わせたとき」だ。人間のセキュリティ審査では、個々の機能を個別にレビューすることが多く、複数の独立した実装が連鎖して生む危険な相互作用を見落としやすい。AIはこうした「コンポーネント間の文脈横断的な推論」を得意とするため、長年見逃されていたパスを短時間で特定できた。

これは、AIによる脆弱性発見が本格的な実用段階に入りつつあることを示す具体的な事例だ。

攻撃の痕跡を見逃すな——ログで何を見るか

CVE-2026-34197は現時点で実際の悪用事例は報告されていないが、Horizon3はブローカーログに攻撃の痕跡が残ると指摘している。確認すべきポイントは以下のとおり：

  • 内部トランスポートプロトコル VM を使用した不審なブローカー接続
  • クエリパラメーターに brokerConfig=xbean:http:// を含む接続試行
  • 設定に関する警告メッセージ（これが出た時点でペイロードはすでに実行されている）

ActiveMQを運用しているチームは、監視ルールにこれらのパターンを追加しておくことを強く勧める。

実務への影響——日本企業が今すぐやるべきこと

ActiveMQ Classicは、Artemisブランチへの移行が進む一方で、レガシーJavaシステムや長期稼働のエンタープライズ基盤には今もClassicが根を張っている。特にSIerが構築した大規模システムや、長年改修されていないオンプレミス環境では使用が残っている可能性が高い。

今すぐ確認すべき事項：

  • バージョン棚卸し: 社内・クラウド上で稼働するActiveMQのバージョンを洗い出す
  • パッチ適用: 5.19.4または6.2.3への更新を最優先タスクとして計画する
  • Jolokia APIの公開状況を確認: 外部からのアクセスが遮断されているか確認する
  • CVE-2024-32114の対応状況も合わせて確認: 6.0.0〜6.1.1を使っている場合は認証バイパスの脆弱性も同時に対処する
  • ログ監視ルールの追加: 上記の攻撃シグネチャをSIEMや監視ツールに反映する

ActiveMQは過去にCVE-2016-3088やCVE-2023-46604がCISAのKEV（既知の悪用脆弱性リスト）に掲載されており、攻撃者にとって馴染み深いターゲットだ。「まだ攻撃されていないから大丈夫」という判断は通用しない。

筆者の見解

セキュリティの話は正直あまり好きなジャンルではないのだが、今回の件はそれとは別次元で興味深かった。

この脆弱性が「各コンポーネント単体では問題なく動いていた」という点は、ソフトウェアセキュリティの本質的な難しさを突いている。人間のレビューは「書かれた仕様」を検査することに長けているが、「複数の正しく動く部品が組み合わさって生まれる意図しない動作」を見抜くのは苦手だ。今回のAIを活用した発見手法は、その弱点をカバーする新しいアプローチとして現実的な価値を示した。セキュリティ審査にAIを組み込むことは、もはや「試験的な取り組み」ではなくなりつつある。

一方で、こういう脆弱性を見るたびに思うのは、「なぜ13年間も外部からJolokia APIが到達できる状態だったのか」という問いだ。ゼロトラストの観点からは、管理APIは内部ネットワークからも必要最小限のアクセスしか認めるべきではなく、認証の有無にかかわらず外部への露出は設計上排除されているべきだ。脆弱性修正は当然必要だが、それだけで終わらせず、「なぜこの経路が存在していたのか」という構造的な問いにも向き合ってほしい。

ActiveMQを運用しているチームは、今回をきっかけにArtemisへの移行計画も真剣に検討する価値がある。Classic継続利用が技術的負債の積み上げになっていないか、立ち止まって考えるタイミングかもしれない。

出典: この記事は 13-year-old bug in ActiveMQ lets hackers remotely execute commands の内容をもとに、筆者の見解を加えて独自に執筆したものです。