GPU VulnDB

Database/AI/ML frameworks & serving

SGLang: oversized audio uploads are buffered in memory, crashing the HTTP/tokenizer worker

CVSS 8.7CVE-2026-109225AI/ML frameworks & servingcurated

Impact

Multipart uploads to /v1/audio/transcriptions are read fully into memory before any size validation, so concurrent large uploads exhaust memory and crash the HTTP/tokenizer worker. The serving process holds the GPU, so the crash takes the model replica offline and forces a reload - on large models that means minutes of cold start with the KV cache and weights re-staged. No authentication is involved, so any client that can reach the endpoint can repeat this at will. Confidentiality and integrity are unaffected; this is availability only.

Who can reach it

Anyone who can reach the SGLang HTTP endpoint, unauthenticated. SGLang exposes no auth of its own by default, so exposure depends entirely on whether the port sits behind a gateway - a pod-network-reachable endpoint means any tenant workload in the cluster can do this.

What to do

No fixed version is named in the record; the upstream issue (sgl-project/sglang#43709) tracks it. Until a release lands, cap request body size and concurrency at the proxy or ingress in front of SGLang and keep the endpoint off any tenant-reachable network. Picking up a fix is a container image bump and a restart of the serving process - the GPU is released and re-acquired, but no node drain or reboot is needed.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.