SGLangに未修正のRCE脆弱性、社内LLM基盤に警戒

LLM（大規模言語モデル）推論フレームワーク「SGLang」に、認証なしでリモートコード実行（RCE）に至る脆弱性 CVE-2026-14890 が公表されました。2026年7月16日にCERT/CCが公開（JVNは7月17日に注意喚起）、執筆時点で修正版は確認できていません。社内で生成AIの推論基盤を自前構築している組織は、該当機能の有効/無効と、そのポートが誰から届くのかを今日中に確認してください。

この記事でわかること

• CVE-2026-14890 の要点と、自社が該当するかの判定条件
• なぜ「pickle × ZeroMQ」の組み合わせが繰り返し事故を起こすのか
• SGLangで同じ根本原因のRCEがこれで3度目である事実と、その意味
• CVSSスコアだけで優先度を決めると取りこぼす理由
• 修正版が無い状況で情シスが打てる現実的な緩和策

何が起きたのか

CERT/CCは2026年7月16日、SGLangの「エキスパート並列（expert-parallel）バックアップ機能」に、認証されていない攻撃者による任意コード実行の脆弱性があると公表しました（VU#326070）。日本ではJVNが7月17日にJVNVU#90968686として注意喚起しています。

そもそもSGLangとは何ですか

SGLangとは、LLMやマルチモーダルモデルを高速に推論させるためのオープンソースのサービング基盤（推論サーバ）です。vLLMなどと同じカテゴリの製品で、社内にGPUサーバを置いて自前でモデルを動かす構成でよく使われます。「クラウドのAPIに社内データを出したくない」という理由で内製に舵を切った組織ほど、気づかないうちに導入しているソフトウェアです。

自社は該当するか：判定は2つの条件

アドバイザリによれば、成立条件は次の2つです。両方に当てはまらなければ、この脆弱性の直接の対象ではありません。

1. エキスパート並列バックアップ機能が有効になっている（MoE系モデルを複数GPU・複数ノードに分散させる構成で使う機能です）
2. その機能が使うポートに、信頼できないネットワークから到達できる

問題は2つ目です。SGLangの内部通信はZeroMQ（軽量なメッセージングライブラリ）で行われ、該当箇所（expert_backup_manager.py）のPULLソケットが認証もデシリアライズ時の検証もかけずに外部ネットワークインタフェース上に開いている、というのがCERT/CCの指摘です。「内部通信だから安全」という前提が、バインド先の設定ひとつで崩れます。

なぜpickleは危険なのですか

pickleは「データを読む」のではなく「Pythonの処理を再生する」仕組みだからです。受け取ったバイト列を pickle.loads() に通した瞬間、その中に埋め込まれた任意のコードが実行されます。JSONのように「値だけを取り出す」わけではありません。つまり、pickleを受け付けるポートは、実質的に認証なしのコード実行エンドポイントと同義です。

機械学習の世界では、モデルの重みや中間データをそのままプロセス間で受け渡す都合上、pickleが便利に使われてきました。その慣習が、ネットワーク越しの通信路に持ち込まれたまま残っているのが、今回の構図です。

見落としやすい点：既定値が「危険側」に倒れている

CERT/CCが緩和策として挙げているのは、環境変数 SGLANG_USE_PICKLE_IPC を false にすることです。裏を返せば、この値は既定で有効（true）だということです。実際、執筆時点のリポジトリの environ.py でも SGLANG_USE_PICKLE_IPC = EnvBool(True) のままでした。

「特別な設定をした環境だけが危ない」のではなく、素直に導入した環境が危ないタイプです。導入担当者に「変な設定はしていません」と言われても、それは安全である根拠になりません。

これで3度目：同じ根本原因が繰り返している

この記事で最も強調したいのはここです。SGLangのpickle起因のRCEは、今回が初めてではありません。CERT/CCが公開したアドバイザリだけで3本あります。

いずれも「ネットワークに開いたソケットで信頼できないデータをデシリアライズする」という同一の設計上の癖から生じています。CERT/CCは、開発側がpickleをmsgpackに置き換える改修を進めていると記載しており、実際にリポジトリにはmsgpack側のIPCを示す変数も存在します。しかし移行は完了しておらず、既定値はpickleのままです。

ここから読み取るべきは、「CVEを1件ずつ潰す」運用がこの製品には効かないということです。次の四半期に4本目が出ても不思議はありません。個別のパッチ適用ではなく、「このサービスのポートを誰から見えるようにするか」というネットワーク側の設計で封じ込めるのが現実的な解になります。

CVSSスコアで優先度を決めると取りこぼす

CVE-2026-14890 は、NVD本体の評価がまだ付いていません（enrichment待ち）。表示されているのはCISA-ADPが付けた暫定値 9.1 です。ここに2つの注意点があります。

• 「7.0以上を対応対象」といったスコア駆動のトリアージでは、評価が付くまで一覧に載らない。スコアが無いことは安全の証明ではありません。
• 暫定ベクタも実態と噛み合っていない。A:N（可用性への影響なし）とされていますが、任意コード実行が成立すれば推論サーバの停止も当然可能です。過小に見える項目があります。

判断材料にすべきは点数ではなく、①成立時に取られる権限の高さ（サーバ上の任意コード実行）と②影響を受ける資産の重要度の2点です。推論基盤には社内文書やナレッジを流し込んでいることが多く、しかもGPUという計算資源そのものが攻撃者にとって価値を持ちます。資産としては軽くありません。

現場目線の課題：この手のサーバは情シスの目が届きにくい

率直なところ、いちばん厄介なのは技術ではなく所在の把握です。SGLangは pip install で入るPythonパッケージなので、資産管理ツールの「インストール済みソフトウェア一覧」には出てきません。以前扱ったポータブル版ツールやカーネルドライバーと同じ、棚卸しの網から落ちる資産です。

さらに、AI推論基盤は情シスではなく事業部門やデータ分析チームが自分で立てているケースが少なくありません。「まずはPoCなので」と検証用に立てたGPUサーバがそのまま業務で使われ続け、しかも検証の名目で広いセグメントに開いたまま——という話は珍しくないはずです。脆弱性情報が出てから「うちに何台あるのか」を数え始めるのが、いちばん避けたい状況です。

情シスはどうすべきか

修正版が無い以上、やることは「パッチを待つ」ではなく「露出を止める」に寄ります。

1. 棚卸し：GPUサーバ上で pip list | grep sglang のようにパッケージを直接確認する。ソフトウェア資産管理の一覧だけを信用しない。事業部門が立てたサーバも対象に含める。
2. 露出の確認：該当サーバで待ち受けポートを列挙し（ss -ltnp 等）、0.0.0.0 にバインドされているものが無いかを見る。外部公開資産の把握という観点では EASM（外部攻撃対象領域管理） の考え方が役立ちます。
3. 緩和策の適用：CERT/CCが挙げるのは、①サービスへの到達を信頼できるネットワークに限定する、②ネットワークセグメンテーションとアクセス制御を行う、③SGLANG_USE_PICKLE_IPC を false にする、の3点です。③は内部通信の実装に関わるため、本番適用前に検証環境で動作確認してください。
4. 今後の追跡：CERT/CCのアドバイザリは更新されます。ベンダーからの回答や修正版の情報が追記される可能性があるため、VU#326070 を定期的に確認する運用にしておくと確実です。

組織全体の進め方としては、IPAの中小企業の情報セキュリティ対策ガイドラインが示す「情報資産の洗い出し」の考え方がそのまま使えます。新しい技術ほど台帳から漏れるので、AI関連サーバを台帳の対象に含める合意を社内で取り付けること、そして事業部門がサーバを立てる際に情シスへ一報が入る導線をつくること——この地道な部分が結局はいちばん効きます。

まとめ

1. SGLangにCVE-2026-14890（認証不要のRCE）が公表され、執筆時点で修正版は確認できていません。該当条件はエキスパート並列バックアップ機能の有効化と、そのポートへの到達可能性の2つです。
2. 同じ「ネットワーク越しのpickleデシリアライズ」を原因とするRCEはこれで3度目です。個別CVEの追跡ではなく、ポートの露出を絞るネットワーク設計で封じ込めるのが現実的です。
3. NVDのスコアは未評価で、暫定値のベクタも実態とずれています。スコアではなく「取られる権限の高さ」と「資産の重要度」で優先度を決めてください。

関連記事

• WordPress・Langflowの脆弱性悪用、CISAが警告 — 生成AI基盤Langflowの未認証RCEが実際に悪用された事例
• NeMoに深刻な脆弱性CVE-2026-24228 AIの盲点 — AI開発基盤そのものが攻撃対象になる構図
• EASMとは？外部攻撃対象領域管理の仕組みを解説 — 把握できていない公開資産を見つける手法
• SharePoint・Check Point脆弱性、CISAがKEV追加 — デシリアライゼーション脆弱性が悪用された例

出典

• CERT/CC VU#326070: SGLang contains a vulnerable pickle deserialization vulnerability through the expert-parallel subsystem
• JVNVU#90968686 SGLangにおけるPickleのデシリアライゼーションに関する脆弱性
• NVD – CVE-2026-14890
• CERT/CC VU#665416: SGLang (sglang) is vulnerable to code execution attacks via unsafe pickle deserialization
• CERT/CC VU#777338: SGLang contains two remote code execution and one path traversal vulnerability
• IPA 中小企業の情報セキュリティ対策ガイドライン