Medium

vLLM Oversized HTTP Header Resource Exhaustion

An attacker sends an HTTP request to a vLLM inference server with an abnormally large header value, such as a multi-gigabyte X-Forwarded-For string. The server buffers this into memory while parsing it, which can exhaust memory and crash or degrade the process, denying service to legitimate users.

How the attack works

The attacker sends one or more unauthenticated requests to a vLLM API endpoint. Instead of a normal-sized header, one header field contains a massive value (published proof-of-concept used a multi-gigabyte X-Forwarded-For), or the request carries many headers or a large aggregate header size. The vLLM server's parser reads and buffers this data into memory before rejecting or processing the request. If the value is large enough, or repeated requests keep pressuring the same host, memory pressure builds until the server slows down or crashes, taking the inference API offline.

Netzilo detection

Netzilo reports this behaviour when it is observed.

Signature ID
6b1d4f0a-9c52-4a1e-8f37-2d5e7a03c9b4
Severity
Medium

Why it matters

A successful attack can knock an inference API offline or degrade its performance, disrupting any application or service that depends on it, without requiring authentication or exploiting a code vulnerability.

What you can do

  • →Enforce a hard header-size limit (well under 8 KB per header, and a reasonable cap on total header bytes and header count) at a reverse proxy or load balancer in front of vLLM, not just at the application.
  • →Reject or truncate requests with abnormally large X-Forwarded-For, Cookie, Authorization, or other header values before they reach the inference server.
  • →Monitor for repeated requests to the same inference endpoint carrying oversized or high-entropy headers, especially bursts from the same source.
  • →Rate-limit and authenticate access to inference API endpoints so anonymous clients cannot send unlimited crafted requests.

Known benign look-alikes

  • Enterprise SSO deployments that emit multi-kilobyte Cookie or Authorization (JWT) headers. A single high-entropy 8-16 KB credential header scores 1 and is suppressed unless padding entropy, flooding or graph-observed burst volume is also present.
  • SDKs or internal tooling that (incorrectly) place base64 image, audio or document payloads in a custom header instead of the body. These are high-entropy and will only fire if they also exceed 32 KB or arrive in a sustained burst.
  • Long X-Forwarded-For / Forwarded / trace-header chains appended by stacked load balancers and service meshes. These are normally well under 8 KB.
  • Load and soak testing against a self-hosted vLLM endpoint, which legitimately produces the burst signal; the header-size anchor still has to be met.
  • Proxies that expand a header into meta after decoding (for example the synthetic header_authorization-jwt key) making the observed value longer than what was sent on the wire.

References