主要なAI推論サーバー全体で重大なRCE脆弱性が発見

開示とベンダーの対応

タイムラインは次のように進みました:

• 2024年10月: Meta Llama Stack（CVE-2024-50050）– 安全でないpickleの使用。JSONベースのシリアライゼーションにより修正。
• 2025年5月: vLLM（CVE-2025-30165）– 脆弱なV0エンジンを安全なV1デフォルトに置き換えることで重大なRCEを修正。
• 2025年5月: NVIDIA TensorRT-LLM（CVE-2025-23254）– Oligoの報告を受けてHMAC検証を実装。NVDによりCritical（9.3）と評価。
• 2025年6月: Modular Max Server（CVE-2025-60455）– pickleの代わりにmsgpackを用いて迅速に修正。

しかし、一部のプロジェクトは修正を行いませんでした。

研究フレームワークであるMicrosoftのSarathi-Serveは、依然として脆弱なままです。SGLangは、メンテナによる当社分析の認識があったにもかかわらず、不完全な修正を実装しています。

これらは私たちが「シャドー脆弱性」と呼ぶものです。CVEが付与されないまま既知の問題が残存し、静かに攻撃者によって再発見されるのを待っています。

RCE デモ

ShadowMQの現実世界での影響を示すため、NVIDIA TensorRT-LLMとModular Maxの両方でRCEのライブデモを収録しました。以下の動画は、この欠陥が実際にどのように悪用され得るかを正確に示しています。

より大きな教訓: コピーは簡単、監査は難しい

開発者が脆弱なコードをコピーするのは、不注意だからではありません。エコシステムがそれを促しているからです。オープンソースAIコミュニティでは、性能が最優先です。

プロジェクトは驚異的なスピードで進んでおり、同業者からアーキテクチャコンポーネントを借用するのは一般的です。しかし、コード再利用に安全でないパターンが含まれると、その影響は外側へ素早く波及します。

ドキュメントが、特定の手法のセキュリティリスクについて警告することはほとんどありません（recv_pyobj()はその典型例です）。

ChatGPTのようなコード生成ツールでさえ、脆弱かどうかにかかわらず、現実世界の利用状況を反映して一般的な例を繰り返しがちです。

こうして同じRCEベクターが、MetaからNVIDIAに至るまで、フレームワークへ静かに入り込む可能性があります。

脆弱性を責任をもって修正してくださったMeta、NVIDIA、vLLM、Modularのセキュリティチームに感謝します。

安全を保つ方法

• 直ちにパッチを適用:
  • Meta Llama Stack ≥ v0.0.41
  • NVIDIA TensorRT-LLM ≥ v0.18.2
  • vLLM ≥ v0.8.0
  • Modular Max Server ≥ v25.6
• 信頼できないデータに対してpickleやrecv_pyobj()を使用しないでください。
• ZMQベースの通信には認証（HMACまたはTLS）を追加してください。
• 公開されているZMQエンドポイントをスキャンし、特定のネットワークインターフェースにバインドすることでネットワークからのアクセスを制限してください。すべてのネットワークインターフェースでソケットを公開してしまう「tcp://*」の使用は避けてください。
• 開発チームを教育する: シリアライゼーションの選択はセキュリティの選択です。

Oligoがこれらの脆弱性からどのように保護するか

Oligoのランタイムセキュリティプラットフォームの主要な強みは、他のどの技術よりもランタイムの挙動をリアルタイムで深く可視化できる点にあります。以下は、この可視性がどのように実用的なインテリジェンスへと変わり、ShadowMQを構成する集合的な脆弱性から保護するのかを示す例です。

最後に

ShadowMQは単なる脆弱性ではありません。イノベーションと不安全性がどのように一緒に広がり得るかを示すケーススタディです。

単一ライブラリの単一関数が、複数のフレームワークにまたがる重大な欠陥の連鎖を生み、世界で最も人気のあるAIシステムの一部に影響を与える結果となりました。すべては、あるプロジェクトが別のプロジェクトのコードを、その含意を十分に理解しないままコピーしたことが原因です。

特にAIインフラにおいて、セキュリティは意図的でなければなりません。性能最適化をコピーするとき、私たちはそのリスクも引き継ぐのです。

‍