GPU VulnDB

Database/AI/ML frameworks & serving

vLLM (MOSS-Audio multimodal processor cache, /tokenize endpoint): vLLM caches a processor object for every distinct

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

Impact

vLLM caches a processor object for every distinct request-controlled mm_processor_kwargs value in a dictionary with no bound. An attacker sending a stream of distinct or oversized mel_config values drives host memory to exhaustion and the API process dies. The /tokenize endpoint is reachable without a key even when --api-key is set, so the usual authentication control does not stop it. On a GPU node this takes out the serving process holding the GPUs for every tenant on that endpoint, and the restart reloads weights, so recovery is minutes of lost inference capacity, not seconds.

Who can reach it

Anyone who can reach the vLLM HTTP endpoint. No authentication required - /tokenize bypasses --api-key. Applies to deployments serving MOSS-Audio.

What to do

Upgrade vLLM to 0.31.0 and restart the serving process, which is a rolling restart of each model replica and reloads weights. Until then, keep the vLLM port off any network a tenant can reach and put an authenticating proxy in front of it, blocking or rate-limiting /tokenize specifically.

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.