AIエージェント系のツールは、便利な反面、ひとたび入口を開けっぱなしにするとかなり危うい。今回The Hacker Newsが伝えたのは、オープンソースのAIオーケストレーション基盤「Ruflo」に見つかった、かなり派手な脆弱性だ。ざっくり言えば、認証なしで外部からコマンド実行できてしまううえに、AIの会話ログや“記憶”まで触れてしまう可能性があった。
この手の話は、単に「サーバーが乗っ取られる」で終わらないところが今どきらしい。AIの裏側にあるAPIキー、ユーザーとの会話、学習用のメモリまで狙える。攻撃者にとっては、かなりおいしいセットだと思う。
Rufloは、Anthropic Claude CodeやOpenAI Codex向けのエージェント制御基盤です。昔の呼び名はClaude Flowで、複数のAIエージェントを束ねて動かす“指揮系統”のようなものだと思うとわかりやすいです。GitHubでは66,500スター超と、かなり使われている部類です。
問題は、その中心にあるMCP bridgeという窓口でした。MCPはModel Context Protocolの略で、AIが外部ツールやデータにアクセスするための標準的な橋渡し役です。便利ですが、要するに「AIに外の世界へ手を伸ばさせる口」です。ここが素のままネットに出ていたら、そりゃ危ない。
今回の脆弱性では、Rufloが233個ものツールを認証なしで公開していたとされています。中身には、シェルコマンド実行、データベース操作、エージェント管理、メモリ保存などが含まれていました。言い換えると、攻撃者から見れば「いろんな操作ボタンが並んだ管理画面」が、鍵なしで開いていたようなものです。
しかも、デフォルトの docker-compose.yml がポート3001を 0.0.0.0 にバインドしていたため、ネットワーク設定によっては外から届いてしまう状態だった。防火壁やセグメント分離がしっかりしていれば被害は抑えられるかもしれませんが、ネットワーク到達可能なら認証なしで完全に悪用できたとされています。ここはかなり重いです。
報告では、単一のHTTP POSTで terminal_execute を呼び出せたとされています。要するに、外部から「このコマンドを実行して」と投げるだけで、Rufloの中で id && hostname のようなコマンドが動いてしまったわけです。
このレベルになると、もはや“脆弱性”というよりリモートから遠隔操作できる扉が開いていたと言ったほうがしっくりきます。しかも、シェルを取られたあとが本番です。攻撃者はそこから、Rufloが使っているLLMプロバイダのAPIキーを抜き出し、保存されている会話を読むことができた可能性があります。
個人的に一番ぞっとするのは、ここで終わらない点です。AIシステムには「記憶」や「学習ストア」のような仕組みがあり、そこに悪意ある内容を書き込まれると、後から出てくる応答そのものが歪められる。昔ながらのWeb改ざんならページを直せば済むことも多いですが、AIの記憶汚染は“後遺症”が残るのが厄介です。
NVDの説明によれば、攻撃者は tools/call を通じて terminal_execute を実行し、橋渡し用コンテナのシェルを得て、環境変数に入っているプロバイダのAPIキーを読み取れたとされています。さらに、そのキーを使って攻撃者自身の意図通りにswarmを動かすことも可能だった、という話です。
ここで重要なのは、ただの情報漏えいではなく、AIエージェントの権限そのものが武器化されることです。APIキーを取られると、そのAIが正規に持っている力を、攻撃者がそのまま借りられてしまう。普通の認証情報漏えいよりも、被害の“使い道”が広いんですね。
さらに、/app ディレクトリに悪意あるペイロードを書き込むことで、永続的なバックドアを残すことも可能だったとされています。これはかなり嫌な展開です。単発で終わらず、再侵入の足場を置いていけるからです。
Rufloの保守担当者であるReuven Cohenは、責任ある開示を受けたあと24時間以内に修正を公開したそうです。このスピード感は素直に立派だと思います。
修正では、MCP bridgeがデフォルトでループバックインターフェースにしかバインドしないようになり、terminal_execute はサーバー側の制御で守られ、MongoDBにも認証が入るようになりました。つまり、最初から外部ネットワークに丸出しだった構成を、だいぶ現実的な形に締め直したわけです。
ただ、こういう事件はアップデートだけで終わりません。攻撃者が一度でも触っていたなら、APIキーは漏れた前提で全交換、AIの記憶やパターンストアの監査、コンテナの再構築までやる必要がある。Nomaも「ソフトウェア更新だけでは不十分」と指摘しています。これはその通りだと思います。AI基盤は、侵入されると“設定”だけでなく“振る舞い”まで汚されるからです。
記事では、露出しているインスタンスを運用しているなら、ポート3001と27017をすぐ閉じる、LLM APIキーを全部ローテーションする、AgentDBのpattern storeに不審なエントリがないか見る、MongoDBの改ざん痕跡を確認することが推奨されています。
ここでのポイントは、MongoDBやAIメモリといった“データ層”が攻撃対象になっていることです。昔ならアプリケーションが落ちるだけで済んだ話が、今は「会話の記録」や「AIの癖」まで守らないといけない。セキュリティ担当者の守備範囲が、じわじわ広がっているのを感じます。
この件の本質は、単に「RCEがあった」ではありません。AIの土台にある信頼関係が一気に崩れることです。
攻撃者は、シェルを取るだけでなく、AIが参照する情報、会話、APIキー、学習ストアまで触れます。すると、未来の応答まで意図的に曲げられる可能性が出てくる。Nomaが「将来のすべてのユーザーへの応答に影響しうる」と述べているのも、この危うさを指しています。
私は、ここがAIセキュリティの一番おもしろくて怖いところだと思っています。昔の脆弱性は“システムを落とす”か“情報を盗む”が中心でした。でもAI時代は、盗んだあとに、そのシステムの判断や記憶を汚せる。攻撃の質が少し変わってきたんですね。
参考: Ruflo MCP Flaw Lets Unauthenticated Attackers Run Commands and Poison AI Memory
