【緊急】SGLangに脆弱性4件、悪意あるAIモデルでサーバ乗っ取りの恐れ

AI推論サーバとして広く使われている「SGLang」に、認証なしでサーバを乗っ取られる重大な脆弱性が4件公表されました。JPCERT/CCのJVNが2026年5月26日に注意喚起を出しています。

うち1件は10点満点で9.8という最高クラスの危険度で、ダウンロードしてきたAIモデルファイルを読み込ませるだけでサーバ上で任意のコードが実行されてしまいます。残り3件は、サーバの管理用ポートに直接細工したデータを投げ込むだけで侵入が可能で、5月26日時点でパッチが提供されていません。

SGLangは社内でLLM（大規模言語モデル）の推論サーバを立てている企業で広く使われており、xAI、AMD、NVIDIA、LinkedIn、Cursor、Oracle、Google Cloud、Microsoft Azure、AWSなどがユーザーに名を連ねています。GitHubのリポジトリによると、世界で40万GPU以上の本番環境で動いているとされる、事実上の業界標準です。

SGLangとは何か

SGLangは、自社のサーバ上で大規模言語モデル（LLM）を動かして、APIとして社内外に提供するためのソフトウェアです。同じカテゴリにはvLLMなどがあり、両者は性能と機能で激しく競争しています。

開発元はLMSYS。ChatGPTやClaudeなどのAIを横並びで評価するランキングサイト「Chatbot Arena」を運営している非営利の研究組織です。SGLang自体もオープンソースで、PyPIから `pip install sglang` で誰でも導入できます。

用途のイメージとしては、企業が「社内で動くChatGPTのようなもの」を構築する際に、OpenAI APIの代わりに自社サーバで応答を返すバックエンドの役割を担います。HuggingFaceなどで配布されているLlamaやDeepSeekといったオープンソースのモデルファイルを読み込ませて、`/v1/chat/completions` のようなOpenAI互換のAPIを社内に提供する、というのが典型的な使い方です。

4件の脆弱性の概要

今回JVNが取りまとめた脆弱性は次の4件です。いずれも認証なしで攻撃可能で、攻撃に成功するとサーバ上で任意のコードを実行できます。

CVSSは脆弱性の深刻度を10点満点で示す業界共通の指標で、9.0以上は「Critical（緊急）」に分類されます。今回のうち3件が9.8で、ベース指標としては「リモート」「認証不要」「ユーザー操作不要」「機密性・完全性・可用性すべてに重大な影響」というほぼ最悪のパターンに当てはまります。

CVE-2026-5760：HuggingFaceから落としたモデルファイルが地雷化する

4件のうち最初に報じられた最も派手な攻撃が、4月に公表されたCVE-2026-5760です。発見者はStuart Beck氏（GitHubでは Stuub）。概念実証コードもすでにGitHubで公開されています。

攻撃のシナリオはシンプルで、これが厄介な点です。

1. 攻撃者が、GGUF形式（オープンソースLLMの一般的なファイル形式）の悪意あるモデルファイルを作る。中に仕込むのは tokenizer.chat_template という設定項目に書き込んだJinja2テンプレートのコード。
2. 攻撃者がそのファイルをHuggingFaceなどの公開リポジトリにアップロード、もしくは標的の組織に何らかの形で読み込ませる。
3. SGLangを運用している企業のエンジニアが、そのモデルを「面白そうなオープンソースモデル」として自社のSGLangサーバに読み込ませる。
4. 誰かが `/v1/rerank` という検索結果の並び替え用のAPIエンドポイントを叩いた瞬間、テンプレートがサーバ側で展開され、仕込まれていたコードが任意の権限で動く。

原因は、SGLangがチャットテンプレートを処理する際に、サンドボックス保護のない `jinja2.Environment()` を使っていたことです。The Hacker Newsによると、対応策は `ImmutableSandboxedEnvironment` への置き換え。これは既知の対策で、PyPIの公式ドキュメントでも警告されている内容です。

同じ系統の脆弱性は2024年にも「Llama Drama」として llama-cpp-python で報告されており、AIエコシステム全体で繰り返されているパターンでもあります。

CVE-2026-7301：管理用ポートに直接データを投げ込むだけで侵入できる

CVE-2026-7301は、SGLangがマルチモーダル（画像・動画を扱う）モードで動いているとき、サーバ内部で各プロセスをつなぐ通信路に攻撃者が直接アクセスできてしまう問題です。報告者はAntiproof。

SGLangは内部でZeroMQという軽量なメッセージング技術を使ってプロセス間の通信を行っています。問題は、その通信路を受け取る側で pickle.loads() を使ってメッセージを復元していること、そして公式ドキュメントが推奨する起動例が `--host 0.0.0.0`（あらゆる接続を受け付ける設定）になっていることです。

pickleはPython専用の便利なデータ保存形式ですが、信頼できないデータを `pickle.loads()` に渡すと、その中に書かれている処理がそのまま実行されてしまう、というよく知られた落とし穴があります。「信頼できないpickleを開くな」はPython公式ドキュメントの一番上に大きく書いてある警告です。

結果として、SGLangのサーバがインターネットや社内LANに公開されていれば、攻撃者は認証なしに細工したpickleデータをZeroMQのソケットに送りつけるだけで、サーバ上で任意のコードを実行できます。3月に公表されたCVE-2026-3059 / 3060と同じ構造の問題で、その時はv0.5.10で一部修正されましたが、今回の7301はその修正が及んでいない別経路の脆弱性です。

CVE-2026-7302と7304：ファイル名にパス区切り、APIフィールドにバイナリ

残り2件は、より単純な作りの脆弱性です。

CVE-2026-7302（パストラバーサル）は、画像編集用の `/v1/images/edits` と動画用の `/v1/videos` というエンドポイントが、アップロードされたファイル名をそのままサーバのファイルパスに連結してしまう問題です。リクエストのファイル名に ../../../etc/cron.d/backdoor のような文字列を入れれば、サーバプロセスが書き込み権限を持つあらゆる場所に任意のファイルを置けます。cronのジョブを書き込めば結果的に任意コード実行に到達するため、深刻度は実質的にRCEと変わりません。

CVE-2026-7304（dillによるデシリアライズRCE）は、生成APIに渡せる `custom_logit_processor` というフィールドに、16進数で表現したdillライブラリのバイナリデータを書き込むと、それを検証なしに `dill.loads()` で復元してしまうという問題です。dillはpickleの上位互換ライブラリで、性質も同じく「信頼できないデータを開いてはいけない」ものです。攻撃には起動時に `--enable-custom-logit-processor` が有効になっている必要があります。

この2件のうちCVE-2026-7304はCVSS 9.8で、いずれも認証不要でリモートから攻撃可能です。発見者のAntiproofのブログによると、3件（7301/7302/7304）はベンダーへの調整中に応答が得られず、未修正のまま公表されました。

なぜAI推論サーバで脆弱性が頻発するのか

SGLangの問題は単発の事故ではありません。Oligo SecurityのAvi Lumelsky氏は、Meta、NVIDIA、Microsoft、vLLM、SGLangなど主要なAI推論サーバの多くが同じ根本原因——ZeroMQとpickleの組み合わせの不適切な使用——に起因する脆弱性を抱えていると2025年11月の調査「ShadowMQ」で報告しています。

理由は構造的です。AI推論サーバは高速化のために、推論を担当するワーカープロセス、リクエストを振り分けるスケジューラ、トークンを生成するエンジンといった複数のプロセスを並行で動かし、それらの間で大量のPythonオブジェクト（モデルの設定、テンソルのメタデータ、テンプレート、辞書など）をやり取りします。この用途にはpickleが最も手軽で、書く側にとっては魅力的です。

ところが「内部用の通信路だから」と油断して認証や暗号化を入れず、さらにデフォルト設定で `0.0.0.0` にバインドしてしまうと、コンテナの設計次第ではこの内部通信路がそのまま社内LANやインターネットに露出します。当ブログでも2025年11月に取り上げたLiteLLMのサプライチェーン攻撃事件でも、Pythonエコシステム特有の「便利な機能の使い方を一歩間違えるとサーバ全体が乗っ取られる」構造が同じように指摘されていました。

SGLang側もLumelsky氏の指摘を受けて修正を進めていますが、CSO Onlineの報道によると修正は不完全で、別の経路を経由した同種の問題（今回のCVE-2026-7301がまさにそれ）が次々と発見されている状況です。

影響を受けるバージョンと対処

公開情報を整理すると、対処の優先順位は次のようになります。

まずは pip show sglang でバージョンを確認し、v0.5.11以降に上げます。これでCVE-2026-5760は塞がります。

残り3件は未パッチのため、当面は構成側で守ります。具体的には、SGLangを起動するときの `--host` を `127.0.0.1` や信頼できる内部IPに限定する、ZeroMQが使うポート（デフォルトでは推論サーバごとに動的に割り当てられる）を社外から到達できない位置に置く、画像・動画系のエンドポイントを使っていないならリバースプロキシで遮断する、`--enable-custom-logit-processor` を使っていないなら無効化する、という対応になります。

外部から取得したGGUFモデルファイルの取り扱いも見直しが必要です。HuggingFaceにあるからといって信頼できる訳ではなく、特にダウンロード数の少ない無名のモデル、フォークされたばかりのモデルは、CVE-2026-5760のような攻撃の温床になり得ます。組織で扱うモデルは出所を限定し、`tokenizer.chat_template` の中身を読み込み前に検査するという運用が必要になります。

ネット上の声と業界の反応

5月のJVN公表を受けて、海外のセキュリティ専門家からはSGLangのベンダー対応への懸念の声が上がっています。Antiproofは「報告に対してベンダーから応答が得られなかった」と明記しており、未修正のままの公表に至った経緯を説明しています。

一方、SGLangを開発するLMSYSはDeepSeek-V4のDay 0サポートなど機能開発を精力的に進めており、4月25日のブログでも新機能の発表が続いています。性能とエコシステムの拡大に注力する一方で、セキュリティ対応のリソース配分が追いついていない構図は、急成長中のOSSプロジェクトに共通する課題と言えます。

SGLangの導入規模を考えると、影響範囲は無視できません。SGLangのREADMEに掲載されているユーザーリストには、AIインフラを大規模に運用する大手クラウド事業者やCursorなどのAIスタートアップが並んでいます。これらの企業がどのバージョンで運用しているか、マルチモーダル機能を有効にしているか、ZeroMQポートをどう守っているかは外部からは見えませんが、いずれにせよ自社の構成を確認する必要があるタイミングです。

まとめ

AI推論サーバSGLangに、認証不要で任意コード実行を許す重大な脆弱性が4件公表されました。v0.5.11ですでに塞がれたCVE-2026-5760の他、3件は2026年5月26日時点で未パッチで、攻撃者にとって入口の多い状態が続いています。

対処の第一歩はバージョンアップ、次にネットワーク境界の見直し、最後に外部から取得するモデルファイルの取り扱い方針の整備です。AI推論基盤は、社内のRDBやKubernetesクラスタと同じく「うっかり社外露出させてはいけないコンポーネント」だという認識を、社内のインフラチームと共有しておく必要があります。

SGLangに限らず、AI推論サーバ全般がここ1年で複数の重大脆弱性を抱えてきた経緯を考えると、今回の4件は氷山の一角と見るのが妥当です。LiteLLMのサプライチェーン事件、ShadowMQ、そして今回のSGLang——根本原因はいずれもPythonエコシステム特有の「便利な機能の安全でない使い方」で、同じ構造の問題はvLLMや他のフレームワークでも今後も出てくるはずです。

参照元

• JVNVU#96879318 - SGLangにおける複数の脆弱性（JPCERT/CC）
• VU#915947 - SGLang is vulnerable to remote code execution（CERT/CC、CVE-2026-5760）
• VU#777338 - SGLang contains two RCE and one path traversal（CERT/CC、CVE-2026-7301/7302/7304）
• VU#665416 - SGLang unsafe pickle deserialization（CERT/CC、CVE-2026-3059/3060/3989）
• SGLang CVE-2026-5760 (CVSS 9.8) Enables RCE via Malicious GGUF Model Files（The Hacker News）
• Three Remote Code Execution vulnerabilities in SGLang（Antiproof）
• ShadowMQ: How Code Reuse Spread Critical Vulnerabilities Across the AI Ecosystem（Oligo Security）
• Proof of Concept exploitation of CVE-2026-5760（Stuart Beck, GitHub）
• sgl-project/sglang（GitHub）