vLLM 0.32.0 Security Changes: CORS Is Closed by Default, Templates Get a Timeout, and Schemas Get a Depth Cap

If you run vLLM and a browser talks to it directly, v0.32.0 can break that setup on purpose. The release changes the default CORS origins from * to none, so browser clients need an explicit --allowed-origins. The same release adds limits on chat template rendering, peer sessions, image formats and JSON schema depth. Several of them close denial-of-service paths that an API client could reach.

I read the v0.32.0 release notes, six of the pull requests they cite, and three GitHub advisories. I did not run vLLM or test any exploit. One advisory ID in the release notes does not match what GitHub shows for that ID, and I cover that below.

The breaking CORS default

The release notes list it twice, under Security and under Breaking Changes: default CORS origins changed from * to none, and you set --allowed-origins for browser clients. The pull request (#61009, merged October 11, 2026) describes the problem like this: default CORS settings allowed any website to read responses from a browser-reachable vLLM server. It requires operators to opt in to browser origins in both the Python and Rust frontends.

The pull request states two claims. Requests from foreign origins get no Access-Control-Allow-Origin header and JSON preflight requests are not authorized. Explicit --allowed-origins settings still permit the origins you choose. Its validation section lists CORS tests that passed.

If you put a web app in front of vLLM and call it from JavaScript, check this before you upgrade. If your calls come from a server, CORS does not apply to them.

Limits on things a client can send

Each item below comes from the Security section of the notes, with the pull request text where I read it.

• Chat templates. The notes say templates are validated statically and rendered under a timeout set by VLLM_CHAT_TEMPLATE_RENDER_TIMEOUT, a user-supplied chat_template in Responses chat_template_kwargs is rejected, and the Rust frontend caps template execution. Pull request #50300 says unbounded Jinja2 rendering let an authenticated API client wedge chat-style endpoints through CPU or memory use. It adds checks for excessive range(), string multiplication and deeply nested loops, and a fuel budget of 500K instructions per render in the Rust frontend.
• Peer sessions. Pull request #51504 says a client could submit many unique non-listening peer addresses through kv_transfer_params, each creating three ZMQ sockets that were never reaped, and about 340 such peers exhausted a limit of 1023 sockets and crashed the engine core. The fix adds VLLM_P2P_MAX_PEERS (default 128), VLLM_P2P_HANDSHAKE_TIMEOUT_S (default 30) and VLLM_P2P_IDLE_TIMEOUT_S (default 300). The advisory text limits the path to a setup that uses the OffloadingConnector with a P2P secondary tier.
• Images. Pull request #60022 says untrusted image bytes were passed to Pillow without a format allowlist, so PostScript or EPS payloads could reach an external renderer. It adds ALLOWED_IMAGE_FORMATS and denies EPS and WMF, among others.
• Shared-memory multimodal cache. Pull request #59357 says that with --mm-processor-cache-type shm, a worker trusted any address and ID a client sent. Handles are now signed with an HMAC using a server-side secret. The pull request says the default LRU cache is not affected.
• Schema depth. Pull request #60036 says deeply nested JSON schemas either crashed with a 500 past about 980 levels or froze the event loop below that. Schemas nested more than 64 levels now return 400. The pull request notes that OpenAI's documented limit is 10 levels.
• Token ids. The notes list a tokenizer max_token_id off-by-one. The advisory says a pre-tokenized prompt with an id equal to the vocabulary size could pass validation and crash the engine at tensor parallel size 1, for models such as the Llama-2 family.

The notes also list security dependency bumps, including aiohttp>=3.14.3 and pillow>=12.3.0.

Where the sources disagree

The release notes name three advisory IDs. I looked each one up through the GitHub advisories API.

• GHSA-frvg-qw88-hww9 is titled as a P2P ZMQ exhaustion issue, rated medium, with 0.32.0 as the first patched version. That matches the notes.
• GHSA-q97c-p368-75c4 is the out-of-vocabulary token id issue, rated medium, first patched in 0.32.0. That matches too.
• GHSA-4hhp-h66f-j5j7 is described in the release notes and in pull request #50300 as the chat template exhaustion issue. The GitHub API returned a different advisory for that ID: an SSRF and local file read in the MiMoV2 Omni multimodal processor, patched in 0.26.0.

I do not know why. The pull request title and the advisory record disagree, and I did not find a source that settles it. If you track vLLM by advisory ID, search by the fix pull request as well, and do not assume the ID maps to the template fix.

Other breaking changes worth a look

The Breaking Changes section also lists these, which matter if you pin versions or script around the server:

• Python 3.10 is dropped. The minimum is 3.11.
• transformers>=5.16.1,<5.20.0 and tokenizers>=0.23.2 are required.
• max_tokens is an upper bound on output instead of being reserved from the context window, so long prompts are no longer rejected for that reason.
• Responses API reasoning stream events are renamed to response.content_part.added and response.content_part.done with part.type="reasoning_text".
• Cascade attention is removed. --disable-cascade-attn still parses but only warns, and the notes say it will be removed in v0.33.0.

What I would check

These are my untested suggestions.

• Search your configs and front-end code for direct browser calls to vLLM before upgrading. If you have them, set --allowed-origins to an explicit list, not a wildcard.
• Find out whether you use P2P KV transfer or the shared-memory multimodal cache. If you do not, two of the fixes do not touch your setup.
• Replay a long-prompt request and a request with a custom chat template on a staging copy. The max_tokens change and the template checks can change what gets accepted.
• Do not expose the server to untrusted clients just because the limits exist. The pull requests describe authenticated or API-reachable clients, and I did not read the project's deployment guidance.

What I would not conclude

• That v0.32.0 makes an exposed vLLM server safe. These are specific fixes, and I did not audit the rest.
• That every item affects you. Several depend on options like the shm cache or a P2P tier.
• That the advisory ID mismatch changes the fix. The pull request content and the release notes agree with each other, and only the ID lookup differs.

Frequently asked questions

What changed about CORS in vLLM 0.32.0?

Default allowed origins changed from * to none, in both the Python and Rust frontends. Set --allowed-origins for browser clients.

Will my server-side client break?

CORS is enforced by browsers, so server-to-server calls are not governed by it. I did not test this.

How do I limit chat template rendering time?

The notes name VLLM_CHAT_TEMPLATE_RENDER_TIMEOUT. I did not find its default value in the sources I read.

What is the JSON schema depth limit?

Schemas nested more than 64 levels of objects and arrays return HTTP 400.

Does the P2P fix affect everyone?

Per the advisory text, it applies to a setup using the OffloadingConnector with a P2P secondary tier. I did not verify other paths.

Which Python version does vLLM 0.32.0 need?

Python 3.11 or newer. The build notes say 3.11 to 3.14 are supported.

Did you run it?

No. I read the release notes, pull requests and advisories. I did not install vLLM or test any of the fixes.

Sources

All read on November 4, 2026.

• vLLM v0.32.0 release notes
• Pull request 61009, restrict default CORS origins
• Pull request 50300, chat template resource exhaustion
• Pull request 51504, P2P ZMQ socket exhaustion
• Pull request 60022, restrict Pillow image formats
• Pull request 59357, authenticate shared-memory cache handles
• Pull request 60036, cap JSON schema nesting
• Pull request 59491, max_token_id off-by-one
• GitHub advisory GHSA-frvg-qw88-hww9
• GitHub advisory GHSA-q97c-p368-75c4
• GitHub advisory GHSA-4hhp-h66f-j5j7

Not read: vLLM's deployment and security docs, the source code, and the model support, performance and hardware sections of the notes.