high · 7.5CVE-2026-55149Aug 20, 2026

CVE-2026-55149: vouch-proxy Unbounded Multipart Cookie Allocation DoS

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

A single unauthenticated HTTP request with a crafted cookie name can crash vouch-proxy by forcing the Go runtime to attempt a ~160 GB heap allocation, taking down the authentication gateway and any…

Packagegithub.com/vouch/vouch-proxy
Ecosystemgo
Affected<= 0.47.2
Fixed in0.48.0
CVE-2026-55149: vouch-proxy Unbounded Multipart Cookie Allocation DoS

The problem

vouch-proxy's multipart cookie reassembly in pkg/cookie/cookie.go reads the total part count directly from the attacker-supplied cookie name (e.g. VouchCookie_1of<N>), then calls make([]string, N) with no upper-bound check.

The /validate and /_external-auth-:id endpoints invoke this code path through JWTCacheHandler before any authentication is performed. No session, token, or credentials are required to trigger the crash.

Proof of concept

A working proof-of-concept for CVE-2026-55149 in github.com/vouch/vouch-proxy, with the exact payload below.

bash
curl -v http://TARGET:9090/validate \
  -H 'Host: app.example.com' \
  -H 'Cookie: VouchCookie_1of10000000000=x'

The sink is make([]string, numParts) at cookie.go:130. The value of numParts is parsed with strconv.Atoi directly from the cookie name suffix supplied by the client, with no positive-range or maximum-value check before the allocation.

With N=10000000000, the Go runtime attempts to allocate approximately 10,000,000,000 x 16 bytes = 160 GB in one call. The runtime cannot satisfy this and immediately emits a fatal out-of-memory error (exit code 2), crashing the process.

The patch (commit fa18ce30) adds a maxCookieParts = 32 constant and rejects any parsed value outside [1, 32] before reaching make, eliminating the unbounded allocation. It also replaces the strings.Split on "of" with strings.Cut, adding a validity check that the separator was actually present.

The fix

Upgrade to vouch-proxy v0.48.0 (commit fa18ce30). The fix adds a hard upper bound (maxCookieParts = 32) on the parsed part count and returns an error for any cookie whose total exceeds that limit, before any memory allocation occurs.

Reported by bnfinet.

References: [1][2][3][4]

Related research