CWE-407
Allowed-with-ReviewInefficient Algorithmic Complexity
Abstraction: Class · Status: Incomplete
An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached.
377 vulnerabilities reference this CWE, most recent first.
GHSA-H67P-54HQ-RP68
Vulnerability from github – Published: 2026-06-15 17:15 – Updated: 2026-06-29 15:05Summary
A crafted YAML document can trigger algorithmic CPU exhaustion in js-yaml merge-key processing (<<) by repeating the same alias many times in a merge sequence.
This causes quadratic parse-time behavior relative to input size and can block a Node.js worker/event loop for seconds with a relatively small payload (tens of KB), resulting in denial of service.
Details
The issue is in merge handling inside lib/loader.js:
storeMappingPair(...)iterates every element of a merge sequence when key tag istag:yaml.org,2002:merge.- For each element, it calls
mergeMappings(...). mergeMappings(...)computesObject.keys(source)and performs_hasOwnProperty.call(destination, key)checks for each key.
When input is of the form:
a: &a {k0:0, k1:0, ..., kK:0} b: {<<: [a, a, a, ... repeated M times ...]} all a entries refer to the same anchored object. After the first merge, subsequent merges are semantically no-ops, but the parser still reprocesses all keys each time. Resulting work is O(K * M), while input size is O(K + M), giving quadratic scaling as payload grows. Relevant code path: lib/loader.js in storeMappingPair(...) merge branch (keyTag === 'tag:yaml.org,2002:merge') lib/loader.js mergeMappings(...)
Root cause
File: lib/loader.js Function: storeMappingPair(state, _result, overridableKeys, keyTag, keyNode, valueNode, startLine, startLineStart, startPos) Lines: ~359-366
if (keyTag === 'tag:yaml.org,2002:merge') {
if (Array.isArray(valueNode)) {
for (index = 0, quantity = valueNode.length; index < quantity; index += 1) {
mergeMappings(state, _result, valueNode[index], overridableKeys);
}
} else {
mergeMappings(state, _result, valueNode, overridableKeys);
}
}
When the merge value is a sequence (YAML 1.1 <<: [ a, a, ... ]), each element is handed to mergeMappings() without deduplication. mergeMappings() then does
sourceKeys = Object.keys(source);
for (index = 0; index < sourceKeys.length; index += 1) {
key = sourceKeys[index];
if (!_hasOwnProperty.call(destination, key)) {
setProperty(destination, key, source[key]);
overridableKeys[key] = true;
}
}
Every alias reference in the sequence resolves (by design) to the SAME object via state.anchorMap. After the first merge, every subsequent merge of that same reference is a pure no-op semantically, but still performs:
- one Object.keys(source) call (O(K))
- K _hasOwnProperty.call checks on the destination
Total: M * K hasOwnProperty checks + M Object.keys allocations, while the final object and all observable side effects are identical to a single merge.
YAML semantics for <<: are idempotent and commutative over duplicate sources,
so collapsing duplicates preserves behavior exactly; this isn't a spec trade-off.
PoC
Environment: js-yaml version: 4.1.1 Node.js: v24.5.0 Platform: arm64 macOS (reproduced consistently) Reproduction script: Create many keys in one anchored map (&a). Merge that same alias repeatedly via <<: [a, a, ...]. Measure parse time and compare with control payload using single merge (<<: *a). Observed repeated runs (same machine): K=M=1000, input 9,909 bytes: ~33–36 ms K=M=2000, input 20,909 bytes: ~121–123 ms K=M=4000, input 42,909 bytes: ~524–537 ms K=M=6000, input 64,909 bytes: ~1,608–1,829 ms K=M=8000, input 86,909 bytes: ~3,395–3,565 ms Control (single merge, similar key counts): K=2000: ~1–2 ms K=4000: ~3 ms K=8000: ~5 ms Also verified: repeated-merge output equals single-merge output (same key count and same JSON), confirming excess time is redundant computation.
Impact
This is a denial-of-service vulnerability (CPU exhaustion / algorithmic complexity). Any service parsing untrusted YAML with js-yaml can be impacted, including API backends, CI tools, config processors, and automation services. An attacker can submit crafted YAML to significantly increase CPU time and reduce availability.
Suggested fix:
Dedupe the merge source list by reference before invoking mergeMappings. Any of the following are minimal and preserve YAML 1.1 merge semantics:
dedupe in storeMappingPair:
if (keyTag === 'tag:yaml.org,2002:merge') {
if (Array.isArray(valueNode)) {
var seen = new Set();
for (index = 0, quantity = valueNode.length; index < quantity; index += 1) {
var src = valueNode[index];
if (seen.has(src)) continue; // idempotent; skip redundant alias
seen.add(src);
mergeMappings(state, _result, src, overridableKeys);
}
} else {
mergeMappings(state, _result, valueNode, overridableKeys);
}
}
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.1"
},
"package": {
"ecosystem": "npm",
"name": "js-yaml"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.2.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "js-yaml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53550"
],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T17:15:07Z",
"nvd_published_at": "2026-06-22T16:16:38Z",
"severity": "MODERATE"
},
"details": "### Summary\nA crafted YAML document can trigger algorithmic CPU exhaustion in `js-yaml` merge-key processing (`\u003c\u003c`) by repeating the same alias many times in a merge sequence. \nThis causes quadratic parse-time behavior relative to input size and can block a Node.js worker/event loop for seconds with a relatively small payload (tens of KB), resulting in denial of service.\n\n### Details\nThe issue is in merge handling inside `lib/loader.js`:\n\n- `storeMappingPair(...)` iterates every element of a merge sequence when key tag is `tag:yaml.org,2002:merge`.\n- For each element, it calls `mergeMappings(...)`.\n- `mergeMappings(...)` computes `Object.keys(source)` and performs `_hasOwnProperty.call(destination, key)` checks for each key.\n\nWhen input is of the form:\n\na: \u0026a {k0:0, k1:0, ..., kK:0}\nb: {\u003c\u003c: [*a, *a, *a, ... repeated M times ...]}\nall *a entries refer to the same anchored object. After the first merge, subsequent merges are semantically no-ops, but the parser still reprocesses all keys each time.\nResulting work is O(K * M), while input size is O(K + M), giving quadratic scaling as payload grows.\nRelevant code path:\nlib/loader.js in storeMappingPair(...) merge branch (keyTag === \u0027tag:yaml.org,2002:merge\u0027)\nlib/loader.js mergeMappings(...)\n\n\n### Root cause\nFile: lib/loader.js\nFunction: storeMappingPair(state, _result, overridableKeys, keyTag, keyNode,\n valueNode, startLine, startLineStart, startPos)\nLines: ~359-366\n\n if (keyTag === \u0027tag:yaml.org,2002:merge\u0027) {\n if (Array.isArray(valueNode)) {\n for (index = 0, quantity = valueNode.length; index \u003c quantity; index += 1) {\n mergeMappings(state, _result, valueNode[index], overridableKeys);\n }\n } else {\n mergeMappings(state, _result, valueNode, overridableKeys);\n }\n }\n\nWhen the merge value is a sequence (YAML 1.1 \u003c\u003c: [ *a, *a, ... ]), each element\nis handed to mergeMappings() without deduplication. mergeMappings() then does\n\n sourceKeys = Object.keys(source);\n for (index = 0; index \u003c sourceKeys.length; index += 1) {\n key = sourceKeys[index];\n if (!_hasOwnProperty.call(destination, key)) {\n setProperty(destination, key, source[key]);\n overridableKeys[key] = true;\n }\n }\n\nEvery alias reference in the sequence resolves (by design) to the SAME object\nvia state.anchorMap. After the first merge, every subsequent merge of that same\nreference is a pure no-op semantically, but still performs:\n\n * one Object.keys(source) call (O(K))\n * K _hasOwnProperty.call checks on the destination\n\nTotal: M * K hasOwnProperty checks + M Object.keys allocations, while the final\nobject and all observable side effects are identical to a single merge.\n\nYAML semantics for `\u003c\u003c:` are idempotent and commutative over duplicate sources,\nso collapsing duplicates preserves behavior exactly; this isn\u0027t a spec trade-off.\n\n\n### PoC\nEnvironment:\njs-yaml version: 4.1.1\nNode.js: v24.5.0\nPlatform: arm64 macOS (reproduced consistently)\nReproduction script:\nCreate many keys in one anchored map (\u0026a).\nMerge that same alias repeatedly via \u003c\u003c: [*a, *a, ...].\nMeasure parse time and compare with control payload using single merge (\u003c\u003c: *a).\nObserved repeated runs (same machine):\nK=M=1000, input 9,909 bytes: ~33\u201336 ms\nK=M=2000, input 20,909 bytes: ~121\u2013123 ms\nK=M=4000, input 42,909 bytes: ~524\u2013537 ms\nK=M=6000, input 64,909 bytes: ~1,608\u20131,829 ms\nK=M=8000, input 86,909 bytes: ~3,395\u20133,565 ms\nControl (single merge, similar key counts):\nK=2000: ~1\u20132 ms\nK=4000: ~3 ms\nK=8000: ~5 ms\nAlso verified: repeated-merge output equals single-merge output (same key count and same JSON), confirming excess time is redundant computation.\n\n\n### Impact\nThis is a denial-of-service vulnerability (CPU exhaustion / algorithmic complexity).\nAny service parsing untrusted YAML with js-yaml can be impacted, including API backends, CI tools, config processors, and automation services. An attacker can submit crafted YAML to significantly increase CPU time and reduce availability.\n\n### Suggested fix:\nDedupe the merge source list by reference before invoking mergeMappings. Any of\nthe following are minimal and preserve YAML 1.1 merge semantics:\n\ndedupe in storeMappingPair:\n\n if (keyTag === \u0027tag:yaml.org,2002:merge\u0027) {\n if (Array.isArray(valueNode)) {\n var seen = new Set();\n for (index = 0, quantity = valueNode.length; index \u003c quantity; index += 1) {\n var src = valueNode[index];\n if (seen.has(src)) continue; // idempotent; skip redundant alias\n seen.add(src);\n mergeMappings(state, _result, src, overridableKeys);\n }\n } else {\n mergeMappings(state, _result, valueNode, overridableKeys);\n }\n }",
"id": "GHSA-h67p-54hq-rp68",
"modified": "2026-06-29T15:05:57Z",
"published": "2026-06-15T17:15:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodeca/js-yaml/security/advisories/GHSA-h67p-54hq-rp68"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53550"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodeca/js-yaml"
}
],
"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"
}
],
"summary": "JS-YAML: Quadratic-complexity DoS in merge key handling via repeated aliases"
}
GHSA-HC3C-6XQP-R265
Vulnerability from github – Published: 2025-03-21 09:30 – Updated: 2025-03-21 09:30encodeText in QDom in Qt before 6.8.0 has a complex algorithm involving XML string copy and inline replacement of parts of a string (with relocation of later data).
{
"affected": [],
"aliases": [
"CVE-2025-30348"
],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-21T07:15:37Z",
"severity": "MODERATE"
},
"details": "encodeText in QDom in Qt before 6.8.0 has a complex algorithm involving XML string copy and inline replacement of parts of a string (with relocation of later data).",
"id": "GHSA-hc3c-6xqp-r265",
"modified": "2025-03-21T09:30:34Z",
"published": "2025-03-21T09:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30348"
},
{
"type": "WEB",
"url": "https://codereview.qt-project.org/c/qt/qtbase/+/581442"
}
],
"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"
}
]
}
GHSA-HF3R-VMRV-7W29
Vulnerability from github – Published: 2024-01-03 18:30 – Updated: 2024-01-03 22:28Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-6r92-cgxc-r5fg. This link is maintained to preserve external references.
Original Description
PeterO.Cbor versions 4.0.0 through 4.5.0 are vulnerable to a denial of service vulnerability. An attacker may trigger the denial of service condition by providing crafted data to the DecodeFromBytes or other decoding mechanisms in PeterO.Cbor. Depending on the usage of the library, an unauthenticated and remote attacker may be able to cause the denial of service condition.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "PeterO.Cbor"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-03T21:06:15Z",
"nvd_published_at": "2024-01-03T16:15:09Z",
"severity": "HIGH"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-6r92-cgxc-r5fg. This link is maintained to preserve external references.\n\n### Original Description\nPeterO.Cbor versions 4.0.0 through 4.5.0 are vulnerable to a denial of \nservice vulnerability. An attacker may trigger the denial of service \ncondition by providing crafted data to the DecodeFromBytes or other \ndecoding mechanisms in PeterO.Cbor. Depending on the usage of the \nlibrary, an unauthenticated and remote attacker may be able to cause the\n denial of service condition.\n",
"id": "GHSA-hf3r-vmrv-7w29",
"modified": "2024-01-03T22:28:05Z",
"published": "2024-01-03T18:30:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/peteroupc/CBOR/security/advisories/GHSA-6r92-cgxc-r5fg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21909"
},
{
"type": "WEB",
"url": "https://github.com/peteroupc/CBOR/commit/b4117dbbb4cd5a4a963f9d0c9aa132f033e15b95"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-6r92-cgxc-r5fg"
},
{
"type": "WEB",
"url": "https://github.com/peteroupc/CBOR/compare/v4.5...v4.5.1"
},
{
"type": "WEB",
"url": "https://vulncheck.com/advisories/vc-advisory-GHSA-6r92-cgxc-r5fg"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Duplicate Advisory: Denial of service in CBOR library",
"withdrawn": "2024-01-03T21:06:15Z"
}
GHSA-HFJ8-63C8-RMFW
Vulnerability from github – Published: 2024-01-19 21:30 – Updated: 2026-01-22 20:53Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-36p8-mvp6-cv38. This link is maintained to preserve external references.
Original Description
Inefficient algorithmic complexity in DecodeFromBytes function in com.upokecenter.cbor Java implementation of Concise Binary Object Representation (CBOR) versions 4.0.0 to 4.5.1 allows an attacker to cause a denial of service by passing a maliciously crafted input. Depending on an application's use of this library, this may be a remote attacker.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.upokecenter:cbor"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-23T14:36:37Z",
"nvd_published_at": "2024-01-19T21:15:10Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-36p8-mvp6-cv38. This link is maintained to preserve external references.\n\n## Original Description\nInefficient algorithmic complexity in DecodeFromBytes function in com.upokecenter.cbor Java implementation of Concise Binary Object Representation (CBOR) versions 4.0.0 to 4.5.1 allows an attacker to cause a denial of service by passing a maliciously crafted input. Depending on an application\u0027s use of this library, this may be a remote attacker.",
"id": "GHSA-hfj8-63c8-rmfw",
"modified": "2026-01-22T20:53:05Z",
"published": "2024-01-19T21:30:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/peteroupc/CBOR-Java/security/advisories/GHSA-fj2w-wfgv-mwq6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23684"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-fj2w-wfgv-mwq6"
},
{
"type": "PACKAGE",
"url": "https://github.com/peteroupc/CBOR-Java"
},
{
"type": "WEB",
"url": "https://vulncheck.com/advisories/vc-advisory-GHSA-fj2w-wfgv-mwq6"
}
],
"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": "Duplicate Advisory: Inefficient Algorithmic Complexity in com.upokecenter:cbor",
"withdrawn": "2026-01-22T20:53:05Z"
}
GHSA-HFQX-732W-XRRW
Vulnerability from github – Published: 2025-12-03 21:31 – Updated: 2026-01-26 15:30When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.
{
"affected": [],
"aliases": [
"CVE-2025-12084"
],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-03T19:15:55Z",
"severity": "MODERATE"
},
"details": "When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.",
"id": "GHSA-hfqx-732w-xrrw",
"modified": "2026-01-26T15:30:31Z",
"published": "2025-12-03T21:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12084"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/issues/142145"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/pull/142146"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/027f21e417b26eed4505ac2db101a4352b7c51a0"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/08d8e18ad81cd45bc4a27d6da478b51ea49486e4"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/27648a1818749ef44c420afe6173af6868715437"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/41f468786762348960486c166833a218a0a436af"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/57937a8e5e293f0dcba5115f7b7a11b1e0c9a273"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/8d2d7bb2e754f8649a68ce4116271a4932f76907"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/9c9dda6625a2a90d2a06c657eee021d6be19842d"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/a46c10ec9d4050ab67b8a932e0859a2ea60c3cb8"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/a696ba8b4d42fd632afc9bc88ad830a2e4cceed8"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/c97e87593063d84a2bd9fe7068b30eb44de23dc0"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/ddcd2acd85d891a53e281c773b3093f9db953964"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/e91c11449cad34bac3ea55ee09ca557691d92b53"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/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-HQQC-JR88-P6X2
Vulnerability from github – Published: 2025-03-31 21:47 – Updated: 2025-03-31 21:47An issue was discovered in the codec. A hash collision vulnerability (in the hash map used to manage connections) allows remote attackers to cause a considerable CPU load on the server (a Hash DoS attack) by initiating connections with colliding Source Connection IDs (SCIDs).
See https://github.com/ncc-pbottine/QUIC-Hash-Dos-Advisory
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty.incubator:netty-incubator-codec-quic"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.71.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-29908"
],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-31T21:47:20Z",
"nvd_published_at": "2025-03-31T19:15:40Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in the codec. A hash collision vulnerability (in the hash map used to manage connections) allows remote attackers to cause a considerable CPU load on the server (a Hash DoS attack) by initiating connections with colliding Source Connection IDs (SCIDs).\n\nSee https://github.com/ncc-pbottine/QUIC-Hash-Dos-Advisory",
"id": "GHSA-hqqc-jr88-p6x2",
"modified": "2025-03-31T21:47:21Z",
"published": "2025-03-31T21:47:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty-incubator-codec-quic/security/advisories/GHSA-hqqc-jr88-p6x2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29908"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty-incubator-codec-quic/commit/e059bd9b78723f8b035e0c547e42ce263f03461c"
},
{
"type": "WEB",
"url": "https://github.com/ncc-pbottine/QUIC-Hash-Dos-Advisory"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty-incubator-codec-quic"
}
],
"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"
}
],
"summary": "Netty QUIC hash collision DoS attack"
}
GHSA-HQR4-QQ8F-HG3X
Vulnerability from github – Published: 2026-10-05 22:49 – Updated: 2026-10-05 22:49Summary
The JSONC parser (stream-json/jsonc/parser.js) and verifier (stream-json/jsonc/verifier.js) scan a comment for its terminator starting from the comment's opening / on every input chunk. When a comment doesn't finish inside the current buffer, the scanner returns the comment's start offset and the buffer keeps the whole comment, so the next chunk re-scans everything seen so far. A single comment of length n delivered across many chunks costs O(n²) CPU.
This is the same class as GHSA-528h-pc64-c93x (path filters, medium, CWE-407): an algorithmic-complexity re-scan in a streaming feature. It's a different code path though — the comment scanner in handleComment, which the 3.5.0 depth cap doesn't touch — so upgrading past that advisory doesn't help here. The plain JSON parser is fine: its strings and numbers advance and drop consumed bytes, and only comments retain and re-scan.
Proof of concept
npm i stream-json@3.5.0
import Parser from 'stream-json/jsonc/parser.js';
function feed(N) {
return new Promise(resolve => {
const stream = Parser.asStream(); // default options
stream.on('data', () => {});
stream.on('error', () => {});
stream.on('end', resolve);
const doc = '/*' + 'a'.repeat(N) + '*/1'; // one valid, closed comment
for (let i = 0; i < doc.length; i += 16384) // 16 KB pieces, as a socket delivers a body
stream.write(doc.slice(i, i + 16384));
stream.end();
});
}
Timing the pipeline (Node 22, one core, clean install): a 2 MB comment blocks the event loop ~0.9 s, 4 MB ~2.9 s, 8 MB ~13 s — roughly 4x per doubling, so quadratic. Smaller chunks make it worse, and the attacker controls TCP segment size: a fixed 4 MB comment takes ~0.75 s at 64 KB chunks, ~2.8 s at 16 KB, ~11 s at 4 KB. Feeding the same input to the JSONC verifier reproduces it identically.
Impact
Remote, unauthenticated CPU denial of service against any service that runs untrusted input through the JSONC parser or verifier: one request pins a core and stalls the whole event loop.
Caveat
Only the JSONC entry points are affected; an app on the default JSON parser is safe. The comment doesn't need to be malformed - a valid, properly closed comment does it. The payload is a few MB, or less if the client sends small chunks. I've suggested medium and left the CVSS vector to you.
Maintainer note on scope
The attack vector is local — stream-json's documented input is data the user owns (JSONC is configuration you wrote); it is not designed for input from the open internet, and the docs now say so explicitly for JSONC. Comments now mirror chunked strings (startComment / commentChunk / endComment, packed commentValue); the scan resumes across input chunks, so a comment of any length costs linear time, and constant memory without packing.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.5.0"
},
"package": {
"ecosystem": "npm",
"name": "stream-json"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-104182"
],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-05T22:49:27Z",
"nvd_published_at": "2026-10-01T21:17:19Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe JSONC parser (`stream-json/jsonc/parser.js`) and verifier (`stream-json/jsonc/verifier.js`) scan a comment for its terminator starting from the comment\u0027s opening `/` on every input chunk. When a comment doesn\u0027t finish inside the current buffer, the scanner returns the comment\u0027s start offset and the buffer keeps the whole comment, so the next chunk re-scans everything seen so far. A single comment of length n delivered across many chunks costs O(n\u00b2) CPU.\n\nThis is the same class as GHSA-528h-pc64-c93x (path filters, medium, CWE-407): an algorithmic-complexity re-scan in a streaming feature. It\u0027s a different code path though \u2014 the comment scanner in `handleComment`, which the 3.5.0 depth cap doesn\u0027t touch \u2014 so upgrading past that advisory doesn\u0027t help here. The plain JSON parser is fine: its strings and numbers advance and drop consumed bytes, and only comments retain and re-scan.\n\n## Proof of concept\n\n```\nnpm i stream-json@3.5.0\n```\n\n```js\nimport Parser from \u0027stream-json/jsonc/parser.js\u0027;\n\nfunction feed(N) {\n return new Promise(resolve =\u003e {\n const stream = Parser.asStream(); // default options\n stream.on(\u0027data\u0027, () =\u003e {});\n stream.on(\u0027error\u0027, () =\u003e {});\n stream.on(\u0027end\u0027, resolve);\n const doc = \u0027/*\u0027 + \u0027a\u0027.repeat(N) + \u0027*/1\u0027; // one valid, closed comment\n for (let i = 0; i \u003c doc.length; i += 16384) // 16 KB pieces, as a socket delivers a body\n stream.write(doc.slice(i, i + 16384));\n stream.end();\n });\n}\n```\n\nTiming the pipeline (Node 22, one core, clean install): a 2 MB comment blocks the event loop ~0.9 s, 4 MB ~2.9 s, 8 MB ~13 s \u2014 roughly 4x per doubling, so quadratic. Smaller chunks make it worse, and the attacker controls TCP segment size: a fixed 4 MB comment takes ~0.75 s at 64 KB chunks, ~2.8 s at 16 KB, ~11 s at 4 KB. Feeding the same input to the JSONC verifier reproduces it identically.\n\n## Impact\n\nRemote, unauthenticated CPU denial of service against any service that runs untrusted input through the JSONC parser or verifier: one request pins a core and stalls the whole event loop.\n\n## Caveat\n\nOnly the JSONC entry points are affected; an app on the default JSON parser is safe. The comment doesn\u0027t need to be malformed - a valid, properly closed comment does it. The payload is a few MB, or less if the client sends small chunks. I\u0027ve suggested medium and left the CVSS vector to you.\n\n---\n\n# Maintainer note on scope\n\nThe attack vector is local \u2014 stream-json\u0027s documented input is data the user owns (JSONC is configuration you wrote); it is not designed for input from the open internet, and the docs now say so explicitly for JSONC. Comments now mirror chunked strings (`startComment` / `commentChunk` / `endComment`, packed `commentValue`); the scan resumes across input chunks, so a comment of any length costs linear time, and constant memory without packing.",
"id": "GHSA-hqr4-qq8f-hg3x",
"modified": "2026-10-05T22:49:27Z",
"published": "2026-10-05T22:49:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/uhop/stream-json/security/advisories/GHSA-hqr4-qq8f-hg3x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104182"
},
{
"type": "WEB",
"url": "https://github.com/uhop/stream-json/commit/c0299dc168ce9455ef5ca5b6a0f6850ee7fa0468"
},
{
"type": "PACKAGE",
"url": "https://github.com/uhop/stream-json"
},
{
"type": "WEB",
"url": "https://github.com/uhop/stream-json/releases/tag/3.6.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "stream-json: JSONC parser and verifier re-scan the whole accumulated comment on every input chunk"
}
GHSA-HX4R-W6WJ-J8FG
Vulnerability from github – Published: 2026-10-01 15:17 – Updated: 2026-10-01 15:17uneval performs synchronous work proportional to a sparse array's declared length. An application that passes attacker-influenced sparse values to uneval can suffer event-loop blocking. Since attacker-controlled creation of sparse arrays is so difficult, this vulnerability is very difficult to exploit.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.9.2"
},
"package": {
"ecosystem": "npm",
"name": "devalue"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.9.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-407"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-01T15:17:42Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "`uneval` performs synchronous work proportional to a sparse array\u0027s declared length. An application that passes attacker-influenced sparse values to `uneval` can suffer event-loop blocking. Since attacker-controlled creation of sparse arrays is so difficult, this vulnerability is very difficult to exploit.",
"id": "GHSA-hx4r-w6wj-j8fg",
"modified": "2026-10-01T15:17:42Z",
"published": "2026-10-01T15:17:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sveltejs/devalue/security/advisories/GHSA-hx4r-w6wj-j8fg"
},
{
"type": "WEB",
"url": "https://github.com/sveltejs/devalue/commit/6861dbbb7e548849e48bce718e88747a298f7250"
},
{
"type": "PACKAGE",
"url": "https://github.com/sveltejs/devalue"
},
{
"type": "WEB",
"url": "https://github.com/sveltejs/devalue/releases/tag/v5.9.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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": "devalue: Residual sparse-array CPU amplification in uneval"
}
GHSA-HXRJ-XXG4-W3QP
Vulnerability from github – Published: 2026-09-07 15:33 – Updated: 2026-09-07 15:33league/commonmark versions before 2.9.1 contain multiple denial of service vulnerabilities in fenced code block detection, reference link label lookup, and emphasis delimiter processing that perform super-linear work on crafted input. Attackers can submit specially crafted Markdown with long backtick runs, nested brackets, or delimiter sequences to consume disproportionate CPU time and prevent legitimate requests from completing.
{
"affected": [],
"aliases": [
"CVE-2026-86430"
],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-07T13:20:42Z",
"severity": "HIGH"
},
"details": "league/commonmark versions before 2.9.1 contain multiple denial of service vulnerabilities in fenced code block detection, reference link label lookup, and emphasis delimiter processing that perform super-linear work on crafted input. Attackers can submit specially crafted Markdown with long backtick runs, nested brackets, or delimiter sequences to consume disproportionate CPU time and prevent legitimate requests from completing.",
"id": "GHSA-hxrj-xxg4-w3qp",
"modified": "2026-09-07T15:33:53Z",
"published": "2026-09-07T15:33:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thephpleague/commonmark/security/advisories/GHSA-j8pm-gj4c-rq4x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86430"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/league-commonmark-before-2.9.1-denial-of-service-via-parsing"
}
],
"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:N/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-J3QR-8F3V-FGJJ
Vulnerability from github – Published: 2025-02-10 18:30 – Updated: 2026-06-30 03:35A flaw in libtasn1 causes inefficient handling of specific certificate data. When processing a large number of elements in a certificate, libtasn1 takes much longer than expected, which can slow down or even crash the system. This flaw allows an attacker to send a specially crafted certificate, causing a denial of service attack.
{
"affected": [],
"aliases": [
"CVE-2024-12133"
],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-10T16:15:37Z",
"severity": "MODERATE"
},
"details": "A flaw in libtasn1 causes inefficient handling of specific certificate data. When processing a large number of elements in a certificate, libtasn1 takes much longer than expected, which can slow down or even crash the system. This flaw allows an attacker to send a specially crafted certificate, causing a denial of service attack.",
"id": "GHSA-j3qr-8f3v-fgjj",
"modified": "2026-06-30T03:35:19Z",
"published": "2025-02-10T18:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12133"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250523-0003"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/02/msg00025.html"
},
{
"type": "WEB",
"url": "https://gitlab.com/gnutls/libtasn1/-/issues/52"
},
{
"type": "WEB",
"url": "https://gitlab.com/gnutls/libtasn1/-/blob/master/doc/security/CVE-2024-12133.md"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-202008.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2344611"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-12133"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33125"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30850"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30849"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:8385"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:8021"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:7077"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:4049"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:17347"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/02/06/6"
}
],
"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"
}
]
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.