CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5567 vulnerabilities reference this CWE, most recent first.
GHSA-MGM6-GX92-H348
Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36Bitcoin SV before 0.1.1 allows uncontrolled resource consumption when receiving messages with invalid checksums.
{
"affected": [],
"aliases": [
"CVE-2018-1000891"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-23T17:15:00Z",
"severity": "HIGH"
},
"details": "Bitcoin SV before 0.1.1 allows uncontrolled resource consumption when receiving messages with invalid checksums.",
"id": "GHSA-mgm6-gx92-h348",
"modified": "2022-05-24T17:36:58Z",
"published": "2022-05-24T17:36:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000891"
},
{
"type": "WEB",
"url": "https://bitcoinsv.io/2019/03/01/denial-of-service-vulnerabilities-repaired-in-bitcoin-sv-version-0-1-1"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-MGVC-CJFR-FJF4
Vulnerability from github – Published: 2022-09-03 00:00 – Updated: 2022-09-09 00:01libvncclient v0.9.13 was discovered to contain a memory leak via the function rfbClientCleanup().
{
"affected": [],
"aliases": [
"CVE-2020-29260"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-02T23:15:00Z",
"severity": "HIGH"
},
"details": "libvncclient v0.9.13 was discovered to contain a memory leak via the function rfbClientCleanup().",
"id": "GHSA-mgvc-cjfr-fjf4",
"modified": "2022-09-09T00:01:00Z",
"published": "2022-09-03T00:00:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29260"
},
{
"type": "WEB",
"url": "https://github.com/LibVNC/libvncserver/commit/bef41f6ec4097a8ee094f90a1b34a708fbd757ec"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/09/msg00035.html"
}
],
"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-MGW6-W847-57FR
Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-05-24 17:30On Juniper Networks EX2300 Series, receipt of a stream of specific multicast packets by the layer2 interface can cause high CPU load, which could lead to traffic interruption. This issue occurs when multicast packets are received by the layer 2 interface. To check if the device has high CPU load due to this issue, the administrator can issue the following command: user@host> show chassis routing-engine Routing Engine status: ... Idle 2 percent the "Idle" value shows as low (2 % in the example above), and also the following command: user@host> show system processes summary ... PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 11639 root 52 0 283M 11296K select 12:15 44.97% eventd 11803 root 81 0 719M 239M RUN 251:12 31.98% fxpc{fxpc} the eventd and the fxpc processes might use higher WCPU percentage (respectively 44.97% and 31.98% in the above example). This issue affects Juniper Networks Junos OS on EX2300 Series: 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S5; 18.3 versions prior to 18.3R2-S4, 18.3R3-S3; 18.4 versions prior to 18.4R2-S5, 18.4R3-S4; 19.1 versions prior to 19.1R3-S2; 19.2 versions prior to 19.2R1-S5, 19.2R3; 19.3 versions prior to 19.3R2-S4, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2-S1, 19.4R3; 20.1 versions prior to 20.1R1-S2, 20.1R2.
{
"affected": [],
"aliases": [
"CVE-2020-1668"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-16T21:15:00Z",
"severity": "MODERATE"
},
"details": "On Juniper Networks EX2300 Series, receipt of a stream of specific multicast packets by the layer2 interface can cause high CPU load, which could lead to traffic interruption. This issue occurs when multicast packets are received by the layer 2 interface. To check if the device has high CPU load due to this issue, the administrator can issue the following command: user@host\u003e show chassis routing-engine Routing Engine status: ... Idle 2 percent the \"Idle\" value shows as low (2 % in the example above), and also the following command: user@host\u003e show system processes summary ... PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 11639 root 52 0 283M 11296K select 12:15 44.97% eventd 11803 root 81 0 719M 239M RUN 251:12 31.98% fxpc{fxpc} the eventd and the fxpc processes might use higher WCPU percentage (respectively 44.97% and 31.98% in the above example). This issue affects Juniper Networks Junos OS on EX2300 Series: 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S5; 18.3 versions prior to 18.3R2-S4, 18.3R3-S3; 18.4 versions prior to 18.4R2-S5, 18.4R3-S4; 19.1 versions prior to 19.1R3-S2; 19.2 versions prior to 19.2R1-S5, 19.2R3; 19.3 versions prior to 19.3R2-S4, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2-S1, 19.4R3; 20.1 versions prior to 20.1R1-S2, 20.1R2.",
"id": "GHSA-mgw6-w847-57fr",
"modified": "2022-05-24T17:30:51Z",
"published": "2022-05-24T17:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1668"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA11065"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-MH2Q-Q3FH-2475
Vulnerability from github – Published: 2026-04-07 20:12 – Updated: 2026-04-24 20:04multi-value baggage: header extraction parses each header field-value independently and aggregates members across values. this allows an attacker to amplify cpu and allocations by sending many baggage: header lines, even when each individual value is within the 8192-byte per-value parse limit.
severity
HIGH (availability / remote request amplification)
relevant links
- repository: https://github.com/open-telemetry/opentelemetry-go
- pinned callsite: https://github.com/open-telemetry/opentelemetry-go/blob/1ee4a4126dbdd1bc79e9fae072fa488beffac52a/propagation/baggage.go#L58
vulnerability details
pins: open-telemetry/opentelemetry-go@1ee4a4126dbdd1bc79e9fae072fa488beffac52a as-of: 2026-02-04 policy: direct (no program scope provided)
callsite: propagation/baggage.go:58 (extractMultiBaggage)
attacker control: inbound HTTP request headers (many baggage field-values) → propagation.HeaderCarrier.Values("baggage") → repeated baggage.Parse + member aggregation
root cause
extractMultiBaggage iterates over all baggage header field-values and parses each one independently, then appends members into a shared slice. the 8192-byte parsing cap applies per header value, but the multi-value path repeats that work once per header line (bounded only by the server/proxy header byte limit).
impact
in a default net/http configuration (max header bytes 1mb), a single request with many baggage: header field-values can cause large per-request allocations and increased latency.
example from the attached PoC harness (darwin/arm64; 80 values; 40 requests):
- canonical:
per_req_alloc_bytes=10315458andp95_ms=7 - control:
per_req_alloc_bytes=133429andp95_ms=0
proof of concept
canonical:
mkdir -p poc
unzip poc.zip -d poc
cd poc
make test
output (excerpt):
[CALLSITE_HIT]: propagation/baggage.go:58 extractMultiBaggage
[PROOF_MARKER]: baggage_multi_value_amplification p95_ms=7 per_req_alloc_bytes=10315458 per_req_allocs=16165
control:
cd poc
make control
control output (excerpt):
[NC_MARKER]: baggage_single_value_baseline p95_ms=0 per_req_alloc_bytes=133429 per_req_allocs=480
expected: multiple baggage header field-values should be semantically equivalent to a single comma-joined baggage value and should not multiply parsing/alloc work within the effective header byte budget.
actual: multiple baggage header field-values trigger repeated parsing and member aggregation, causing high per-request allocations and increased latency even when each individual value is within 8192 bytes.
fix recommendation
avoid repeated parsing across multi-values by enforcing a global budget and/or normalizing multi-values into a single value before parsing. one mitigation approach is to treat multi-values as a single comma-joined string and cap total parsed bytes (for example 8192 bytes total).
fix accepted when: under the default PoC harness settings, canonical stays within 2x of control for per_req_alloc_bytes and per_req_allocs, and p95_ms stays below 2ms.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.40.0"
},
"package": {
"ecosystem": "Go",
"name": "go.opentelemetry.io/otel"
},
"ranges": [
{
"events": [
{
"introduced": "1.36.0"
},
{
"fixed": "1.41.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-29181"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-07T20:12:57Z",
"nvd_published_at": "2026-04-07T21:17:16Z",
"severity": "HIGH"
},
"details": "multi-value `baggage:` header extraction parses each header field-value independently and aggregates members across values. this allows an attacker to amplify cpu and allocations by sending many `baggage:` header lines, even when each individual value is within the 8192-byte per-value parse limit.\n\n## severity\n\nHIGH (availability / remote request amplification)\n\n## relevant links\n\n- repository: https://github.com/open-telemetry/opentelemetry-go\n- pinned callsite: https://github.com/open-telemetry/opentelemetry-go/blob/1ee4a4126dbdd1bc79e9fae072fa488beffac52a/propagation/baggage.go#L58\n\n## vulnerability details\n\n**pins:** open-telemetry/opentelemetry-go@1ee4a4126dbdd1bc79e9fae072fa488beffac52a\n**as-of:** 2026-02-04\n**policy:** direct (no program scope provided)\n\n**callsite:** propagation/baggage.go:58 (`extractMultiBaggage`)\n**attacker control:** inbound HTTP request headers (many `baggage` field-values) \u2192 `propagation.HeaderCarrier.Values(\"baggage\")` \u2192 repeated `baggage.Parse` + member aggregation\n\n### root cause\n\n`extractMultiBaggage` iterates over all `baggage` header field-values and parses each one independently, then appends members into a shared slice. the 8192-byte parsing cap applies per header value, but the multi-value path repeats that work once per header line (bounded only by the server/proxy header byte limit).\n\n### impact\n\nin a default `net/http` configuration (max header bytes 1mb), a single request with many `baggage:` header field-values can cause large per-request allocations and increased latency.\n\nexample from the attached PoC harness (darwin/arm64; 80 values; 40 requests):\n\n- canonical: `per_req_alloc_bytes=10315458` and `p95_ms=7`\n- control: `per_req_alloc_bytes=133429` and `p95_ms=0`\n\n## proof of concept\n\ncanonical:\n\n```bash\nmkdir -p poc\nunzip poc.zip -d poc\ncd poc\nmake test\n```\n\noutput (excerpt):\n\n```\n[CALLSITE_HIT]: propagation/baggage.go:58 extractMultiBaggage\n[PROOF_MARKER]: baggage_multi_value_amplification p95_ms=7 per_req_alloc_bytes=10315458 per_req_allocs=16165\n```\n\ncontrol:\n\n```bash\ncd poc\nmake control\n```\n\ncontrol output (excerpt):\n\n```\n[NC_MARKER]: baggage_single_value_baseline p95_ms=0 per_req_alloc_bytes=133429 per_req_allocs=480\n```\n\n**expected:** multiple `baggage` header field-values should be semantically equivalent to a single comma-joined `baggage` value and should not multiply parsing/alloc work within the effective header byte budget.\n**actual:** multiple `baggage` header field-values trigger repeated parsing and member aggregation, causing high per-request allocations and increased latency even when each individual value is within 8192 bytes.\n\n## fix recommendation\n\navoid repeated parsing across multi-values by enforcing a global budget and/or normalizing multi-values into a single value before parsing. one mitigation approach is to treat multi-values as a single comma-joined string and cap total parsed bytes (for example 8192 bytes total).\n\n**fix accepted when:** under the default PoC harness settings, canonical stays within 2x of control for `per_req_alloc_bytes` and `per_req_allocs`, and `p95_ms` stays below 2ms.\n\n\n[poc.zip](https://github.com/user-attachments/files/25079945/poc.zip)\n[PR_DESCRIPTION.md](https://github.com/user-attachments/files/25079946/PR_DESCRIPTION.md)",
"id": "GHSA-mh2q-q3fh-2475",
"modified": "2026-04-24T20:04:24Z",
"published": "2026-04-07T20:12:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-mh2q-q3fh-2475"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29181"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/pull/7880"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/commit/aa1894e09e3fe66860c7885cb40f98901b35277f"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-go"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.41.0"
}
],
"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": "OpenTelemetry-Go: multi-value `baggage` header extraction causes excessive allocations (remote dos amplification)"
}
GHSA-MH3M-8C74-74XH
Vulnerability from github – Published: 2022-01-27 15:28 – Updated: 2022-01-31 21:59Impact
This is a DoS vulnerability that is possible due to a bug in the library that would allow an attacker with specifically designed queries to cause stack overflow panics. Any user with access to the GraphQL handler can send these queries and cause stack overflows. This in turn could potentially compromise the ability of the server to serve data to its users. To make things worse the only mitigation in affected versions creates opportunities for other attacks. This issue is only available if you are using graphql.MaxDepth option in your schema (which is highly recommended in most cases).
Patches
The issue has been patched in version v1.3.0. We have been trying to maintain backwards compatibility and avoid breaking changes so upgrading should not be problematic.
Workarounds
The best workaround is to patch to a version greater than or equal to v1.3.0.
Otherwise, the only workaround in versions prior to v1.3.0 is to disable the graphql.MaxDepth option from your schema. Unfortunately, this could potentially create opportunities for other attacks.
References
There are no references or links. This issue was reported privately and was fixed before creating this Security Advisory.
For more information
If you have any questions or comments feel free to reach out to @pavelnikolov or @tony on the Gopher Slack.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/graph-gophers/graphql-go"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-21708"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2022-01-24T22:42:15Z",
"nvd_published_at": "2022-01-21T23:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nThis is a DoS vulnerability that is possible due to a bug in the library that would allow an attacker with specifically designed queries to cause stack overflow panics. Any user with access to the GraphQL handler can send these queries and cause stack overflows. This in turn could potentially compromise the ability of the server to serve data to its users. To make things worse the only mitigation in affected versions creates opportunities for other attacks. This issue is only available if you are using `graphql.MaxDepth` option in your schema (which is highly recommended in most cases).\n\n### Patches\nThe issue has been patched in version `v1.3.0`. We have been trying to maintain backwards compatibility and avoid breaking changes so upgrading should not be problematic. \n\n### Workarounds\nThe best workaround is to patch to a version greater than or equal to `v1.3.0`. \nOtherwise, the only workaround in versions prior to `v1.3.0` is to disable the `graphql.MaxDepth` option from your schema. Unfortunately, this could potentially create opportunities for other attacks.\n\n### References\nThere are no references or links. This issue was reported privately and was fixed before creating this Security Advisory.\n\n### For more information\nIf you have any questions or comments feel free to reach out to @pavelnikolov or @tony on the Gopher Slack.",
"id": "GHSA-mh3m-8c74-74xh",
"modified": "2022-01-31T21:59:33Z",
"published": "2022-01-27T15:28:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/graph-gophers/graphql-go/security/advisories/GHSA-mh3m-8c74-74xh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21708"
},
{
"type": "WEB",
"url": "https://github.com/graph-gophers/graphql-go/commit/eae31ca73eb3473c544710955d1dbebc22605bfe"
},
{
"type": "PACKAGE",
"url": "https://github.com/graph-gophers/graphql-go"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2022-0300"
}
],
"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": "Denial of Service in graphql-go"
}
GHSA-MH68-7CW5-7M9V
Vulnerability from github – Published: 2025-01-28 00:32 – Updated: 2026-04-02 21:32An input validation issue was addressed. This issue is fixed in visionOS 2.3, iOS 18.3 and iPadOS 18.3, macOS Sequoia 15.3, watchOS 11.3, tvOS 18.3. An attacker on the local network may be able to cause unexpected system termination or corrupt process memory.
{
"affected": [],
"aliases": [
"CVE-2025-24126"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-27T22:15:17Z",
"severity": "CRITICAL"
},
"details": "An input validation issue was addressed. This issue is fixed in visionOS 2.3, iOS 18.3 and iPadOS 18.3, macOS Sequoia 15.3, watchOS 11.3, tvOS 18.3. An attacker on the local network may be able to cause unexpected system termination or corrupt process memory.",
"id": "GHSA-mh68-7cw5-7m9v",
"modified": "2026-04-02T21:32:08Z",
"published": "2025-01-28T00:32:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24126"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122066"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122068"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122071"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122072"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122073"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122374"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122375"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Jan/12"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Jan/13"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Jan/15"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Jan/19"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MH99-V99M-4GVG
Vulnerability from github – Published: 2026-07-24 21:53 – Updated: 2026-07-24 21:53Summary
expand() bounds the number of results it produces (the max option,
100_000 by default) but not their length. By chaining many brace groups,
an attacker keeps the result count under max while making every result grow
with the number of groups. Building max long results — plus the intermediate
arrays combined at each brace group — exhausts memory and crashes the Node
process with an uncatchable out-of-memory error. try/catch around
expand() does not help: the fatal error terminates the process.
A ~7.5 KB input ('{a,b}'.repeat(1500)) is enough to crash a default Node
process.
Details
For N chained brace groups such as '{a,b}'.repeat(N):
- the result count is
2^N, immediately capped atmax(100_000), so themaxprotection appears to hold, but - each result is
Ncharacters long, so the total output size ismax × Ncharacters, which grows without bound inN.
expand_ combines each brace set with the fully-expanded tail:
const post = m.post.length ? expand_(m.post, max, false) : ['']
...
for (let j = 0; j < N.length; j++) {
for (let k = 0; k < post.length && expansions.length < max; k++) {
const expansion = pre + N[j] + post[k] // grows one group longer per level
...
expansions.push(expansion)
}
}
The loop guard expansions.length < max limits how many strings are built, but
nothing limits how long they get. Each recursion level materializes another
array of up to max strings, one character longer than the level below, and —
because V8 represents pre + N[j] + post[k] as a cons-string (rope) that
references post[k] — those intermediate strings stay reachable through the
whole chain. Memory therefore scales with max × N.
Measured on 5.0.7 ('{a,b}'.repeat(N), default max):
| groups (N) | input bytes | result count | peak RSS |
|---|---|---|---|
| 20 | 100 | 100,000 | ~80 MB |
| 50 | 250 | 100,000 | ~214 MB |
| 100 | 500 | 100,000 | ~409 MB |
| 300 | 1,500 | 100,000 | ~1,148 MB |
| 1500 | 7,500 | — | OOM crash |
Proof of concept
const { expand } = require('brace-expansion')
// ~7.5 KB input — crashes the process with a fatal, uncatchable OOM:
// FATAL ERROR: ... JavaScript heap out of memory
try {
expand('{a,b}'.repeat(1500))
} catch (e) {
// never reached — the process is already dead
}
Impact
Any application that passes attacker-influenced strings to
brace-expansion.expand() — directly, or transitively via minimatch / glob
brace patterns — can be crashed by a small request. Because the failure is a
fatal V8 out-of-memory error rather than a thrown exception, it cannot be caught
and it takes down the whole worker/process, denying service.
Remediation
Upgrade to a patched release. The fix bounds the total number of characters a
single expand() call may accumulate (EXPANSION_MAX_LENGTH, default
4_000_000, configurable via a new maxLength option), applied inside the
output-building loops so intermediate arrays are bounded too. Once the limit is
reached, output is truncated — consistent with how max already truncates —
instead of growing without bound. The limit sits well above any realistic
expansion (100,000 results hitting max measure ~1M characters), so legitimate
input is unaffected.
After the fix, '{a,b}'.repeat(1500) returns a bounded, truncated result in
~0.7 s using ~340 MB and never crashes, including under a constrained 512 MB
heap.
The fix bounds memory but the algorithm still rebuilds intermediate arrays at
each level (roughly O(N × maxLength) work on this input class). A streaming
rewrite that produces output in O(total output size) can be a non-urgent
follow-up.
If immediate upgrade isn't possible, avoid passing untrusted input to
expand() / glob brace patterns, or pass a small explicit max and
maxLength.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.7"
},
"package": {
"ecosystem": "npm",
"name": "brace-expansion"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-14257"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T21:53:14Z",
"nvd_published_at": "2026-07-23T14:17:00Z",
"severity": "HIGH"
},
"details": "### Summary\n\n`expand()` bounds the *number* of results it produces (the `max` option,\n`100_000` by default) but not their *length*. By chaining many brace groups,\nan attacker keeps the result count under `max` while making every result grow\nwith the number of groups. Building `max` long results \u2014 plus the intermediate\narrays combined at each brace group \u2014 exhausts memory and crashes the Node\nprocess with an **uncatchable** out-of-memory error. `try/catch` around\n`expand()` does not help: the fatal error terminates the process.\n\nA ~7.5 KB input (`\u0027{a,b}\u0027.repeat(1500)`) is enough to crash a default Node\nprocess.\n\n### Details\n\nFor `N` chained brace groups such as `\u0027{a,b}\u0027.repeat(N)`:\n\n- the result count is `2^N`, immediately capped at `max` (`100_000`), so the\n `max` protection appears to hold, but\n- each result is `N` characters long, so the total output size is\n `max \u00d7 N` characters, which grows without bound in `N`.\n\n`expand_` combines each brace set with the fully-expanded tail:\n\n```js\nconst post = m.post.length ? expand_(m.post, max, false) : [\u0027\u0027]\n...\nfor (let j = 0; j \u003c N.length; j++) {\n for (let k = 0; k \u003c post.length \u0026\u0026 expansions.length \u003c max; k++) {\n const expansion = pre + N[j] + post[k] // grows one group longer per level\n ...\n expansions.push(expansion)\n }\n}\n```\n\nThe loop guard `expansions.length \u003c max` limits how many strings are built, but\nnothing limits how long they get. Each recursion level materializes another\narray of up to `max` strings, one character longer than the level below, and \u2014\nbecause V8 represents `pre + N[j] + post[k]` as a cons-string (rope) that\nreferences `post[k]` \u2014 those intermediate strings stay reachable through the\nwhole chain. Memory therefore scales with `max \u00d7 N`.\n\nMeasured on `5.0.7` (`\u0027{a,b}\u0027.repeat(N)`, default `max`):\n\n| groups (N) | input bytes | result count | peak RSS |\n|---|---|---|---|\n| 20 | 100 | 100,000 | ~80 MB |\n| 50 | 250 | 100,000 | ~214 MB |\n| 100 | 500 | 100,000 | ~409 MB |\n| 300 | 1,500 | 100,000 | ~1,148 MB |\n| 1500 | 7,500 | \u2014 | **OOM crash** |\n\n### Proof of concept\n\n```js\nconst { expand } = require(\u0027brace-expansion\u0027)\n\n// ~7.5 KB input \u2014 crashes the process with a fatal, uncatchable OOM:\n// FATAL ERROR: ... JavaScript heap out of memory\ntry {\n expand(\u0027{a,b}\u0027.repeat(1500))\n} catch (e) {\n // never reached \u2014 the process is already dead\n}\n```\n\n### Impact\n\nAny application that passes attacker-influenced strings to\n`brace-expansion.expand()` \u2014 directly, or transitively via `minimatch` / `glob`\nbrace patterns \u2014 can be crashed by a small request. Because the failure is a\nfatal V8 out-of-memory error rather than a thrown exception, it cannot be caught\nand it takes down the whole worker/process, denying service.\n\n### Remediation\n\nUpgrade to a patched release. The fix bounds the total number of characters a\nsingle `expand()` call may accumulate (`EXPANSION_MAX_LENGTH`, default\n`4_000_000`, configurable via a new `maxLength` option), applied inside the\noutput-building loops so intermediate arrays are bounded too. Once the limit is\nreached, output is truncated \u2014 consistent with how `max` already truncates \u2014\ninstead of growing without bound. The limit sits well above any realistic\nexpansion (100,000 results hitting `max` measure ~1M characters), so legitimate\ninput is unaffected.\n\nAfter the fix, `\u0027{a,b}\u0027.repeat(1500)` returns a bounded, truncated result in\n~0.7 s using ~340 MB and never crashes, including under a constrained 512 MB\nheap.\n\nThe fix bounds memory but the algorithm still rebuilds intermediate arrays at\neach level (roughly `O(N \u00d7 maxLength)` work on this input class). A streaming\nrewrite that produces output in `O(total output size)` can be a non-urgent\nfollow-up.\n\nIf immediate upgrade isn\u0027t possible, avoid passing untrusted input to\n`expand()` / glob brace patterns, or pass a small explicit `max` **and**\n`maxLength`.",
"id": "GHSA-mh99-v99m-4gvg",
"modified": "2026-07-24T21:53:14Z",
"published": "2026-07-24T21:53:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/juliangruber/brace-expansion/security/advisories/GHSA-mh99-v99m-4gvg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14257"
},
{
"type": "WEB",
"url": "https://github.com/juliangruber/brace-expansion/commit/a1bd33999ea75262c4749fff3bbb0d1372bd07b5"
},
{
"type": "PACKAGE",
"url": "https://github.com/juliangruber/brace-expansion"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/package/brace-expansion"
}
],
"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": "brace-expansion: DoS via unbounded expansion length causing an out-of-memory process crash"
}
GHSA-MHCH-RJ8X-4V2P
Vulnerability from github – Published: 2024-12-12 03:33 – Updated: 2024-12-12 03:33Windows Remote Desktop Gateway (RD Gateway) Denial of Service Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-49129"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-12T02:04:40Z",
"severity": "HIGH"
},
"details": "Windows Remote Desktop Gateway (RD Gateway) Denial of Service Vulnerability",
"id": "GHSA-mhch-rj8x-4v2p",
"modified": "2024-12-12T03:33:05Z",
"published": "2024-12-12T03:33:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49129"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-49129"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MHGF-JQHM-P7P3
Vulnerability from github – Published: 2026-05-28 21:32 – Updated: 2026-05-28 21:32Uncontrolled Resource Consumption (CWE-400) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user can send a specially crafted compressed request payload that is processed prior to authorization checks, causing excessive memory and CPU resource consumption that can result in a Kibana instance becoming unresponsive or crashing.
{
"affected": [],
"aliases": [
"CVE-2026-42400"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T21:16:30Z",
"severity": "MODERATE"
},
"details": "Uncontrolled Resource Consumption (CWE-400) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user can send a specially crafted compressed request payload that is processed prior to authorization checks, causing excessive memory and CPU resource consumption that can result in a Kibana instance becoming unresponsive or crashing.",
"id": "GHSA-mhgf-jqhm-p7p3",
"modified": "2026-05-28T21:32:05Z",
"published": "2026-05-28T21:32:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42400"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/kibana-8-19-16-9-3-5-9-4-2-security-update-esa-2026-35/386554"
}
],
"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"
}
]
}
GHSA-MHM3-QVQ8-3FC6
Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-07-13 00:01The vCenter Server contains a denial-of-service vulnerability due to improper XML entity parsing. A malicious actor with non-administrative user access to the vCenter Server vSphere Client (HTML5) or vCenter Server vSphere Web Client (FLEX/Flash) may exploit this issue to create a denial-of-service condition on the vCenter Server host.
{
"affected": [],
"aliases": [
"CVE-2021-21992"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-22T19:15:00Z",
"severity": "MODERATE"
},
"details": "The vCenter Server contains a denial-of-service vulnerability due to improper XML entity parsing. A malicious actor with non-administrative user access to the vCenter Server vSphere Client (HTML5) or vCenter Server vSphere Web Client (FLEX/Flash) may exploit this issue to create a denial-of-service condition on the vCenter Server host.",
"id": "GHSA-mhm3-qvq8-3fc6",
"modified": "2022-07-13T00:01:08Z",
"published": "2022-05-24T19:15:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21992"
},
{
"type": "WEB",
"url": "https://www.vmware.com/security/advisories/VMSA-2021-0020.html"
}
],
"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"
}
]
}
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.