SGLang の KVキャッシュがリクエスト間で漏れた｜GLM-5.3 で155件露出、v0.5.20 で修正

LLM の推論基盤で、KVキャッシュがリクエストをまたいで漏れるという新しいクラスの事故が公表されました。Cloudflare が Workers AI で提供していた GLM-5.3 モデルで、ある要求の応答に別テナントのデータが混ざり、155件の応答が影響を受けました。原因は、OSS の推論エンジン SGLang が長すぎる要求をうまく扱えなかったことと、文脈窓と KVキャッシュのプールのサイズ不整合が重なったことです。修正は SGLang v0.5.20 で、自前で推論基盤を運用している場合は更新と設定の見直しが要ります。依存する基盤の欠陥が利用者全体に波及する構図はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説に、テナント・リクエストをまたいで本来触れないデータに届く類型はIDOR とは｜認可チェックの抜けを塞ぐ設計、AI 実行環境の隔離の考え方はOpenAI のエージェント・サンドボックスに学ぶ封じ込めにまとめています。

自前で SGLang を運用しているなら、まず版を確かめます。

python -c "import sglang; print(sglang.__version__)"

v0.5.20 未満なら更新します。これは侵害の判定ではなく、修正の入った版かの確認です。

いつ、何が起きたのか

Cloudflare は2026年10月26日、Workers AI で提供していた GLM-5.3 モデルで、クロスリクエストの KVキャッシュ露出があったと公表しました。155件の応答に別の顧客の要求のデータが含まれ、混入が起きたのは2026年8月27日から9月9日まで、影響を受けた応答はいずれも 681,280 トークンを超えるプロンプトでした。発端は外部研究者による9月8日の HackerOne 報告で、Cloudflare はインシデント宣言から40分以内にモデルを停止し、同日中に是正して復旧、意図的な悪用の証拠は確認していないとしています。

なぜ混線したのか

公表によれば、原因は二つの問題の重なりです。一つめはサイズ不整合で、モデルは 1,048,576 トークンの文脈窓で配置されたのに、prefill 側の KVキャッシュのプールは 681,280 トークン分しか確保されていませんでした。二つめは SGLang の不具合で、この上限を超える要求を失敗させる代わりに、プロンプトを1トークンのプレースホルダに置き換えて処理を続けてしまいました。prefill はそのプレースホルダの KV を生成して decode ノードへ転送し、decode 側は以前の要求が残した KVキャッシュのページを読み、その内容が応答に現れました。

背景には、高速化のために推論を prefill（プロンプトを読み込んで KV を作る段階）と decode（1トークンずつ生成する段階）に分けて別ノードで動かす構成があります。この構成では、prefill が作った KV を decode へ転送して引き継ぎます。引き継ぐ KV が「どの要求のものか」をサイズの前提ごと正しく扱えないと、decode は割り当てられたメモリ領域に残っていた前の要求のページをそのまま読みます。今回はまさに、置き換えられたプレースホルダのぶんしか KV が無いのに、decode がプール上の古いページを参照してしまいました。

ここでは攻撃に使える具体的な手順（PoC）は示しません。要点は、要求ごとに分離されているべきキャッシュが、サイズの想定を超えたときに前の要求の残りを読んでしまったことです。これは特定のモデルの問題というより、長い文脈を扱う推論基盤に共通しうる落とし穴です。言い換えれば、KVキャッシュがテナントをまたぐサイドチャネルになりうる、という新しいクラスのリスクが現実に起きたということです。従来のアプリで言えば、セッションの取り違えでログイン中の別人の画面が見えてしまう事故に近く、LLM 推論ではそれがキャッシュの層で起こります。

何を直すか

対応は、上流の SGLang を v0.5.20 以上へ上げることが中心です。追補として v0.5.21・v0.5.22 も公開されていて、Cloudflare は全オペレータに更新を推奨しています。あわせて、KVキャッシュのプールのサイズが、設定した最大の文脈長以上になっているかを、prefill と decode の両方の全ノードで確認します。SGLang の起動ログにプールと文脈長の値が出るので、そこを突き合わせます。

自分の環境を確認する

自前で SGLang を運用している場合、版の確認に加えて、起動時のログでプールと文脈長の関係を見ます。プールのトークン数が、設定した最大文脈長を下回っていると、今回と同じ前提ずれが起こりえます。

sglang --version

見るべきは、起動ログに出る KVキャッシュのプールのトークン数（割り当てられたページ数）と、モデルに設定した最大文脈長の関係です。プールが文脈長を下回っていれば、長い要求が来たときに今回と同じ前提ずれが起こりえます。prefill と decode を別ノードに分けている構成では、両方のノードでこの関係を確認します。片側だけ直しても、もう片側が古い前提のままだと混線の芽が残るためです。

マルチテナントで推論を提供しているなら、要求ごとの隔離が効いているかを運用の観点で見直します。いずれも「いま漏れているか」を直接判定するものではなく、前提が崩れていないかの確認です。確認できたら、SGLang を修正版へ上げてから本番へ反映し、更新後も起動ログで前提が保たれているかを継続して見ます。

影響範囲と、確定していないこと

確定しているのは、Cloudflare の GLM-5.3 で155件の応答に他テナントのデータが混入し、原因が SGLang の over-length 処理とプールのサイズ不整合だった、という点です。対象は 681,280 トークンを超える長い要求に限られ、意図的な悪用の証拠は無いと公表されています。一方で、すべての長い要求で漏えいが起きたとまでは示されていません（報告でもその点は限定的です）。また、この件に CVE 番号は割り当てられていない報じられ方です。

影響を直接受けるのは、SGLang を使って自前でマルチテナントの LLM 推論を配信している運用者です。SGLang は vLLM と並んで広く使われる OSS の推論エンジンで、社内基盤や推論サービスの土台に採用している組織は少なくありません。マネージドの API を使うだけの利用者は、提供元の対応に委ねられます。自分が「どちらの立場か」を最初に切り分けると、やるべきことがはっきりします。運用側なら版と設定、利用側なら提供元の告知の確認、という具合です。

今回の件は、公表の仕方としても参考になります。Cloudflare は影響件数（155件）・対象条件（681,280 トークン超）・期間（8/27〜9/9）・意図的悪用の有無を数字で切り分けて出し、上流の OSS 修正版まで案内しました。確定した事実と、まだ分かっていないこと（すべての長い要求で漏れたわけではない、CVE 未採番）を分けて読むのが、過不足ない対応につながります。いずれにせよ、長い文脈を売りにする推論基盤が増えるほど、今回のような「サイズの前提ずれ＋失敗時の扱い」に起因する混線は起こりやすくなります。版を上げ、プールと文脈長の一致を確かめることが、確実な備えです。長い文脈は便利な機能である一方、それを安全に配信できているかは別の確認を要する、という視点を持っておくとよいでしょう。

参照ソース

• Cross-request KV cache exposure in the GLM-5.3 Workers AI model（Cloudflare 公式ブログ）
• SGLang security update: improving request isolation（LMSYS / SGLang 公式）
• sgl-project/sglang リリース（v0.5.20・v0.5.21・v0.5.22 を確認）
• SGLang v0.5.20（修正を含むリリースタグ）