Skip to content
The Injection_
LIVE
LIVElast sweep next in--:--:--

[ RSS ][ JSON ][ llms.txt ]

SGLang: a caller-set hash makes the cache serve another request's image

CVE-2026-111392 lets a remote caller of SGLang's /generate endpoint reuse another request's cached image by declaring its hash.

· SGLang · Research by Mingkai Yu, Jiadai Wang, Jiajia Liu

CVE-2026-111392
MEDVulnerability

CVE-2026-111392 lets a caller of SGLang's native /generate endpoint choose the cache key for an image, so a crafted request can have another request's cached image served back to the model. No released version fixes it.

01What happened

VulnCheck published CVE-2026-111392 on October 16, 2026 and credits Mingkai Yu, Jiadai Wang and Jiajia Liu. A bug report filed in the SGLang repository the same day reports the flaw reproducing on three of three cold restarts, and a second client on another host receiving the first client's image content. A contributor opened a pull request against the report the same day.

02How it works

SGLang's native /generate endpoint accepts an mm_hashes field: one hex string per image, chosen by the caller. The reporter traced how that value is written straight onto the multimodal item, skipping the content-based hash recompute, and then becomes the item's pad value filling the image region of the token sequence. The declared hash therefore becomes the prefix cache's identity for that image, so a request carrying one image under a hash already used for a different image reuses the earlier image's cached KV entries. The model then describes the earlier image and returns an ordinary-looking completion, with no warning or error.

03Who is affected

Multimodal SGLang deployments that expose the native /generate endpoint to callers who are not fully trusted carry the risk, across the release range listed below. Deployments reached only through the OpenAI-compatible endpoints are out of scope, because those routes do not expose the mm_hashes field. The reporter's own test ran a Qwen2.5-VL-3B-Instruct server on a single GPU.

04What to do

Restrict access to SGLang's native /generate endpoint, or route callers you do not trust through the OpenAI-compatible endpoints instead, until a fixed release ships. Operators who need the native endpoint can track pull request 44653, which would ignore caller-declared hashes unless the server is started with a new opt-in flag.

Questions people ask

Is there a patch for CVE-2026-111392 in SGLang?
No released SGLang version fixes CVE-2026-111392 as of October 16, 2026. A pull request, 44653, would ignore caller-declared mm_hashes unless an operator starts the server with a new --trust-caller-mm-hashes flag, but the pull request is still open and unmerged, and its author notes the end-to-end reproducer has not been run on a GPU. Restricting access to the native endpoint is the available mitigation.
Which SGLang endpoints expose the mm_hashes field?
Only SGLang's native /generate endpoint accepts the mm_hashes field, according to the bug report. The OpenAI-compatible endpoints do not expose it, so deployments that serve traffic solely through those routes are not reachable by this attack. The reporter also notes that SGLang's Kimi embedding path already rejects caller-supplied mm_hashes, while the generic multimodal path does not.
How does CVE-2026-111392 differ from the SGLang debug dumper flaw?
CVE-2026-111392 poisons the multimodal prefix cache and can disclose another request's image, while CVE-2026-111391 lets a caller run Python in the SGLang scheduler process through a debug endpoint. VulnCheck published advisories for both on October 16, 2026, but they sit in different code paths: the cache flaw is rated 6.3 medium and the debug dumper flaw is rated critical.

Sources 3 links, all fetched

  1. 1github.comSGLang Issue 44641
  2. 2vulncheck.comVulnCheck Advisory
  3. 3github.comProposed Fix PR