AI導入を加速させる競争の中で、組織は大規模にモデルを展開するため、高性能な推論サーバーへの依存を強めている。
しかし、急速な開発ペースによって、重大な盲点が浮き彫りになった。AIの基盤インフラは、再利用されたコードや他のプロジェクトから受け継いだコード、十分に監査されていないコードで構築されていることが多い。
Oligo Securityのセキュリティ研究者は明らかにした。リモートコード実行（RCE）脆弱性が、チームの呼ぶShadowMQというパターンを通じて、主要なAIフレームワーク全体に広がっていたのだ。これは、安全性に問題のあるZeroMQ（ZMQ）とPythonのpickleデシリアライゼーションに根ざした、通信層に潜む欠陥である。
この問題は、MetaのLlama Stack、NVIDIA TensorRT-LLM、MicrosoftのSarathi-Serve、vLLM、SGLang、Modular Maxなど、業界をリードする幅広いプロジェクトに影響し、AIエコシステム全体に共通する広範なセキュリティリスクを生み出している。
ShadowMQの発見
調査は2024年、Oligoの研究者がMetaのLlama Stack内に危険なパターンを見つけたことから始まった。このフレームワークは、ZMQのrecv_pyobj()メソッドを使用しており、Pythonのpickleモジュールを使ってデータを自動的にデシリアライズしていた。
pickleはデシリアライズ中に任意のコードを実行できるため、認証されていないネットワークソケット経由で使用すると、RCEへの直接的な経路が生じる。
Metaは迅速に対応し、CVE-2024-50050を発行するとともに、pickleをJSONベースのシリアライゼーション方式に置き換えた。
研究チームはその後、他の場所でも同様の問題を発見した。NVIDIA TensorRT-LLM、vLLM、SGLang、Modular Maxはいずれも、同じ、またはほぼ同一の危険なコードを再利用していた。
なかには、ヘッダーコメントで出典を認めたまま、あるプロジェクトから別のプロジェクトへ1行単位でコピーされたファイルもあった。
例えばSGLangは、脆弱なファイルについて「vLLMから適応」と明記しており、アーキテクチャ上の最適化だけでなく、欠陥のあるデシリアライゼーションロジックまで受け継いでいた。
AIコード再利用に潜むリスク
ShadowMQは、現代のAI開発慣行を通じて脆弱性がひそかに拡散する仕組みを示している。
フレームワークのメンテナーは、性能を最適化しリリースを早めるため、他のプロジェクトからコンポーネントを借用することが多い。
この再利用自体が有害なわけではない。しかし、pickleベースのデシリアライゼーションのような安全でない通信方式を、セキュリティレビューなしにコピーすると、エコシステム全体が同じ弱点を受け継ぐことになる。
ShadowMQが連鎖的に広がる性質により、見過ごされた1つの欠陥が複数のベンダー、研究機関、クラウドプロバイダーへ波及する可能性がある。
推論サーバーが主要な標的になる理由
AI推論サーバーは、GPUクラスター全体で機密性の高いモデルプロンプト、独自データセット、顧客入力を処理する。
ShadowMQを悪用すれば、攻撃者は任意のコードを実行し、権限を昇格させ、モデルや秘密情報を抜き取り、ShadowRayキャンペーンで確認されたようなGPUベースのクリプトマイナーをインストールできる可能性がある。
Oligoのスキャンでは、プロトコル固有のTCPバナーを公衆インターネット上に送信している、公開状態のZMQソケットが数千個見つかった。その一部は明らかに本番環境の推論環境に属していた。脆弱なデシリアライゼーション呼び出しが1つあるだけで、AI運用全体が侵害される可能性がある。
ベンダー各社のShadowMQへの対応
協調開示を受け、複数の大手ベンダーが迅速にパッチをリリースした。
- Meta Llama Stack（CVE-2024-50050）ではpickleをJSONに置き換えた。
- vLLM（CVE-2025-30165）では、安全なV1エンジンを推奨することで危険なロジックを解消した。
- NVIDIA TensorRT-LLM（CVE-2025-23254）ではHMAC検証を追加し、重大度9.3の評価を受けた。
- Modular Max Server（CVE-2025-60455）では、安全なシリアライゼーションのためmsgpackを採用した。
研究者によると、すべてのフレームワークが正常にパッチ適用されたわけではない。MicrosoftのSarathi-Serveには依然として脆弱性があり、SGLangの修正も部分的にとどまっている。こうした未解決の欠陥は、潜在脆弱性、つまり防御側には知られているものの対処されず、脅威アクターによる再発見を待つ問題に当たる。
AIプロジェクト間で危険なコードが繰り返される理由
ShadowMQが広がったのは、開発者の怠慢が原因ではない。むしろ、AIエコシステムに内在する構造的な現実を反映している。
- 性能へのプレッシャーがコードの借用を促す。
- recv_pyobj()のような安全でないメソッドにはrecv_pyobj()目立った警告がない。
- コード生成ツールが、一般的だが安全でないパターンを頻繁に再現する。
- セキュリティレビューが、急速なAIイノベーションのペースに追いついていない。
その結果、1つの脆弱な実装が、数十のリポジトリへひそかに広がる可能性がある。
AIインフラを安全にするための主な対策
ShadowMQの脆弱性は、安全でないデフォルト設定と、受け継がれたコードの双方に起因するため、組織はAIインフラのセキュリティ確保に向けて先手を打つ必要がある。
- すべてのAI推論フレームワークにパッチを適用し、最新の安全なバージョンに更新するとともに、再利用または継承されたコードを継続的に監査し、安全でないパターンがないか確認する。
- 安全でないシリアライゼーションを排除するにはpickleや /recv_pyobj()を避け、信頼できる形式であるJSON、msgpack、protobufなどを適用する。
- すべてのZMQおよびサービス間通信を安全にするには、認証（HMAC/TLS）を必須にし、チャネルを暗号化するとともに、厳格なネットワーク分離とファイアウォールルールによって公開状態を阻止する。
- アクセスを制限し、インフラを強化するにはtcp://*を避け、ZMQエンドポイントを信頼できるネットワークに限定し、コンテナの強化によって推論サーバーを分離するとともに、ゼロトラスト原則を適用する。
- 監視と検知を強化するため、ログ記録、異常検知、EDR/XDRによるカバレッジ、公開エンドポイントのスキャン、異常なデシリアライゼーションやプロトコル動作に対するアラートを導入する。
- 開発・エンジニアリングチームを教育することで、シリアライゼーションのリスク、安全な通信慣行、コード再利用の危険性について理解を深める。安全でないパターンを阻止するCIチェックやポリシーも活用する。
こうした緩和策を導入し、安全な開発、通信、インフラの慣行を強化することで、組織はShadowMQ型の脆弱性に対するサイバーレジリエンスを構築できる。
AIスタックに受け継がれる脆弱性
ShadowMQは、現代のAIインフラがセキュリティ上の欠陥をゼロから生み出すのではなく、しばしば受け継いでいることを示している。
組織が前例のない速さでオープンソースコンポーネントを統合する中、脆弱性はフレームワーク、クラウド、企業環境全体にひそかに伝播する可能性がある。
こうしたリスクを軽減するには、他の重要システムと同じ厳格さでAIスタックを扱い、再利用されたコードを監査し、より安全な通信パターンを徹底するとともに、安全なシリアライゼーションを優先する必要がある。
開発者が依存するソフトウェアサプライチェーン