CVE-2026-50285: 
Analyse et atténuation des vulnérabilités

CVE-2026-50285 is a pre-authentication memory exhaustion vulnerability in Pomerium, an identity-aware proxy, caused by unbounded zstd decompression in the HPKE V2 callback path. It affects Pomerium versions >= 0.32.6 and < 0.32.8 (Go module github.com/pomerium/pomerium). The vulnerability was originally published on June 4, 2026, and added to the GitHub Advisory Database on July 15, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Pomerium Advisory).

The root cause is uncontrolled resource consumption (CWE-400) combined with improper validation of input quantity (CWE-1284) in pkg/hpke/url.go. The decodeQueryStringV2 function calls zstdDecoder.DecodeAll(raw, nil) with no output size cap — zstd.WithDecoderLowmem(true) only reduces the decoder's own footprint, not the decompressed output size. Because Pomerium's HPKE receiver public key is publicly served at /.well-known/pomerium/hpke-public-key, an attacker can generate their own sender key pair, encrypt a zstd decompression bomb (e.g., ~19 KB compressing to 128 MiB), and deliver it to the unauthenticated /.pomerium/callback endpoint. The HPKE Open call succeeds because it only verifies consistency between the attacker-supplied sender public key and the sealed payload — sender identity validation (validateSenderPublicKey) occurs after decompression completes, meaning the memory spike is unconditional. Only stateless/hosted authenticate deployments (Pomerium Zero) are affected; self-hosted stateful deployments verify an HMAC-SHA256 signature before any decryption or decompression (GitHub Advisory).

Successful exploitation causes a pre-authentication denial of service against the Pomerium proxy process. Each malicious HTTP request (~20–40 KB payload) can force the server to allocate hundreds of megabytes of memory; concurrent or repeated requests can exhaust all available process memory and crash the proxy. A crash blocks all user access to every application protected by the affected Pomerium deployment. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue confined to the proxy process itself (Pomerium Advisory).

1. Retrieve the receiver public key: Send an unauthenticated GET request to https://TARGET_HOSTNAME/.well-known/pomerium/hpke-public-key to obtain Pomerium's 32-byte HPKE public key — no credentials required.
2. Generate an attacker-controlled sender key pair: Using Go and the github.com/pomerium/pomerium/pkg/hpke package, call hpke.GeneratePrivateKey() to create a fresh ephemeral key pair.
3. Build a decompression bomb: Construct a large plaintext payload (e.g., "x=" + strings.Repeat("A", 128*1024*1024)) and compress it with zstd, producing a ~19 KB compressed blob that expands to ~128 MiB.
4. Seal the payload: Call hpke.Seal(attackerPriv, receiverPub, compressed) to encrypt the bomb using the attacker's private key and the server's public key. The HPKE Open call on the server will succeed because it only checks consistency between the supplied sender public key and the sealed ciphertext.
5. Deliver to the callback endpoint: Send a GET request to https://TARGET_HOSTNAME/.pomerium/callback/?k=<attacker_pubkey>&q=<base64_sealed_bomb>. The server decompresses the payload unconditionally before rejecting the attacker's identity.
6. Amplify the attack: Repeat or parallelize requests — each request forces ~128–256 MiB of allocation. Sustained concurrent requests exhaust process memory and crash the proxy, denying access to all protected applications (GitHub Advisory).

• Network: High volume of GET requests to /.pomerium/callback/ with query parameters k (base64-encoded 32-byte key) and q (large base64-encoded blob) from one or more source IPs; requests with unusually large q parameter values (~20–40 KB encoded).
• Logs: Pomerium proxy access logs showing repeated hits to /.pomerium/callback with large query strings and subsequent validateSenderPublicKey rejection errors; Go runtime out-of-memory (OOM) errors or process crash logs.
• Process: Sudden spike in Pomerium proxy process memory consumption (hundreds of MiB per request burst) visible in system monitoring; proxy process restarts or OOM kills recorded by the OS or container orchestrator (e.g., Kubernetes OOMKilled events).
• Network: Preceding unauthenticated GET requests to /.well-known/pomerium/hpke-public-key from the same source IP, indicating reconnaissance to retrieve the public key before the attack (GitHub Advisory).

Upgrade to Pomerium v0.32.8, which fixes the vulnerability by adding zstd.WithDecoderMaxMemory(4*1024*1024) to the zstd decoder initialization in pkg/hpke/url.go, capping decompressed output at 4 MiB. The patch was released on June 4, 2026 (commit 593eb81). Self-hosted deployments using the stateful authentication flow are not affected and do not require immediate action. As a secondary mitigation (not a substitute for patching), network-level controls can restrict access to /.pomerium/callback from untrusted sources, though this may interfere with legitimate OAuth flows (Pomerium Release, Patch Commit).

The vulnerability was discovered and reported by bugbunny.ai and was published by Pomerium maintainer calebdoxsey on June 4, 2026. The advisory was added to the GitHub Advisory Database on July 15, 2026. No significant broader media coverage or notable community commentary beyond the official advisory has been identified at this time (GitHub Advisory).