CVE-2026-111392: SGLang Information Disclosure Vulnerability

CVE-2026-111392 Overview

CVE-2026-111392 affects SGLang through version 0.5.21, a serving framework for large language models (LLMs) and vision-language models. The vulnerability stems from the server trusting caller-supplied mm_hashes values as the multimodal prefix-cache key. Remote attackers can poison cached key-value (KV) entries across requests by submitting crafted hashes to the /generate endpoint. By sending a different image under a known or predicted hash, an attacker can disclose another request's image content or corrupt a victim's response. The weakness is classified as Insufficient Verification of Data Authenticity [CWE-345].

Critical Impact
Cross-tenant information disclosure and response corruption in shared multimodal inference deployments running SGLang.

Affected Products

SGLang versions up to and including 0.5.21
Deployments exposing the /generate endpoint to untrusted clients
Multi-tenant inference services using SGLang's multimodal prefix cache

Discovery Timeline

2026-10-16 - CVE-2026-111392 published to NVD
2026-10-16 - Last updated in NVD database

Technical Details for CVE-2026-111392

Vulnerability Analysis

SGLang caches multimodal prefixes to avoid recomputing expensive vision-encoder outputs for repeated images. The cache uses hash identifiers to deduplicate entries across requests. In vulnerable builds, the server accepts mm_hashes directly from the client in the /generate request body and uses those values as the cache key without recomputing the hash server-side. This allows an attacker to assert any identifier for their uploaded image. When the asserted identifier collides with an identifier produced by a legitimate request, the cache serves attacker-controlled image embeddings in place of the victim's, or returns victim embeddings to the attacker.

Root Cause

The root cause is a trust boundary violation [CWE-345]. The TokenizerManager and request structures defined in io_struct.py and tokenizer_manager.py treat mm_hashes as authoritative identity material instead of recomputing it from the image bytes. Because the hash doubles as both an identity and an integrity tag, letting the client supply it collapses the integrity property.

Attack Vector

An unauthenticated remote attacker sends a /generate request containing an image payload plus a chosen or predicted mm_hashes value. If the identifier matches a cached entry from another user, the server reuses the attacker's embeddings for the victim's prompt or returns the victim's cached state to the attacker. Exploitation requires knowledge or prediction of a target hash, which raises attack complexity but is feasible when hashes derive from guessable inputs or are observable through side channels.

No verified public exploit code is available. Refer to the VulnCheck Advisory on SGLang and the vulnerable code paths in io_struct.py L205-L215 and tokenizer_manager.py L1183-L1215 for the trust boundary details.

Detection Methods for CVE-2026-111392

Indicators of Compromise

Requests to /generate containing an explicit mm_hashes field supplied by the client
Repeated identical mm_hashes values arriving from distinct source identities or sessions
Unexpected image or token content appearing in model responses that does not match the submitted prompt

Detection Strategies

Inspect application logs for /generate payloads that include mm_hashes and flag any that originate from external clients
Compare the client-supplied mm_hashes against a server-side recomputed hash of the submitted image bytes and alert on mismatches
Correlate cache-hit telemetry with user identity to detect cross-tenant reuse of multimodal cache entries

Monitoring Recommendations

Enable verbose request logging on SGLang's tokenizer manager during triage to capture full multimodal metadata
Monitor rate and distribution of mm_hashes values across sessions to detect enumeration or collision attempts
Track anomalous latency drops on /generate that correlate with suspected cache hits from untrusted callers

How to Mitigate CVE-2026-111392

Immediate Actions Required

Restrict network access to the /generate endpoint so only trusted clients can reach SGLang
Place SGLang behind an authenticating gateway that strips any client-supplied mm_hashes field before forwarding
Disable the multimodal prefix cache in multi-tenant deployments until a patched build is deployed

Patch Information

Upstream remediation is tracked in GitHub Issue #44641 and Pull Request #44653. The fix recomputes multimodal hashes server-side instead of trusting caller-supplied values. Upgrade to the first SGLang release that incorporates PR #44653 once published, and validate that mm_hashes can no longer be influenced by the request body.

Workarounds

Deploy a reverse proxy rule that drops the mm_hashes key from /generate request bodies
Partition SGLang instances per tenant so cache poisoning cannot cross trust boundaries
Require authenticated sessions and bind cache keys to the session identifier at the proxy layer

bash

# Example NGINX rule to strip client-supplied mm_hashes from /generate requests
location /generate {
    # Reject requests that attempt to supply mm_hashes
    if ($request_body ~* "mm_hashes") {
        return 400;
    }
    proxy_pass http://sglang_backend;
}