CVE-2026-103241: Medium DoS in vLLM Gemma4 Unified Parser

CVE-2026-103241 is a Medium severity denial of service in vLLM, the LLM inference and serving engine. A flaw in the Rust Gemma4 unified parser lets deeply nested model output crash the process. The record lists versions up to 0.26.0 as affected and names 0.29.1rc0 as the version that resolves it.

What's affected

• Product: vLLM, from the vllm-project, in the Rust frontend parser for Gemma4 tool calls.
• Affected: up to 0.26.0, per the record.
• Fixed: 0.29.1rc0 per the record and the linked release page. That is a release candidate, so look for a later stable release.
• Component: rust/src/parser/src/unified/gemma4.rs, the Gemma4UnifiedParser.
• Score: CVSS 5.3, Medium.

Source note: the record says up to 0.26.0 while the fix lands in 0.29.1rc0, so the status of builds between those numbers is not stated in the sources I read. The related pull request merged on 1 September 2026. Check the project's release notes for the exact release your deployment uses.

How to check if you're exposed

Look at the vLLM version in every serving environment and whether the Rust frontend path is used.

pip show vllm
pip freeze | grep -i vllm
docker images | grep -i vllm

Then check whether you serve Gemma 4 models with tool calling enabled. The upstream issue shows the parser handles tool call arguments, so deployments that never use tool calling with this model family are less exposed.

If you pull a container image, read the tag and the build date rather than trusting a latest tag. Inventory notebooks and staging clusters too, because those are the ones that tend to run forgotten versions.

Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan reads a manifest or lockfile and shows which packages carry known CVEs, including this one. Nothing is installed and nothing leaves your browser session beyond the scan itself.

What to do now

1. Find every vLLM deployment and note its version and the models it serves.
2. Upgrade to 0.29.1rc0 or later, and prefer a stable release once one is out. Test on staging first.
3. Review the pull request description for the recursion guard, which limits recursive parser frames, and confirm your version includes it.
4. Run the serving process under a supervisor that restarts it on a crash, and keep request rate limits in place.
5. Do not expose the inference endpoint directly to untrusted users. Put it behind an authenticated gateway.
6. Add the model server to your continuous dependency monitoring.

Why it matters

The record classes this as CWE-404, improper resource shutdown or release. The upstream issue gives the mechanism: the parser reads tool call arguments with a recursive descent grammar that had no depth limit, so deeply nested braces and brackets recurse until the thread's stack runs out and the process ends.

The interesting part for AI teams is where the hostile input comes from. It is model output, not a user upload. A model can be steered by a prompt, so untrusted users who can talk to the model may influence what the parser sees. That makes parsers on the output side as important to harden as those on the input side.

The fix adds a shared guard with a maximum of 128 active recursive frames, according to the pull request. The record notes that an exploit was published, and does not say it was used in the wild. The CVE is not in the CISA catalog.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• vLLM issue 50927
• vLLM pull request 54303
• vLLM release v0.29.1rc0

Last reviewed: 18 October 2026.