eslint-9.39.4.tgz: 3 vulnerabilities (highest severity is: 9.8)

[mend-for-github-com]

Vulnerable Library - eslint-9.39.4.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Vulnerabilities

Vulnerability	Severity	CVSS	Dependency	Type	Fixed in (eslint version)	Remediation Possible**
CVE-2026-33228	Critical	9.8	flatted-3.4.1.tgz	Transitive	N/A*	❌
CVE-2026-33750	Medium	6.5	brace-expansion-1.1.12.tgz	Transitive	N/A*	❌
CVE-2026-53550	Medium	5.3	js-yaml-4.1.1.tgz	Transitive	N/A*	❌

*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

CVE-2026-33228

Vulnerable Library - flatted-3.4.1.tgz

A super light and fast circular JSON parser.

Library home page: https://registry.npmjs.org/flatted/-/flatted-3.4.1.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

• eslint-9.39.4.tgz (Root Library)
  • file-entry-cache-8.0.0.tgz
    • flat-cache-4.0.1.tgz
      • ❌ flatted-3.4.1.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

flatted is a circular JSON parser. Prior to version 3.4.2, the parse() function in flatted can use attacker-controlled string values from the parsed JSON as direct array index keys, without validating that they are numeric. Since the internal input buffer is a JavaScript Array, accessing it with the key "proto" returns Array.prototype via the inherited getter. This object is then treated as a legitimate parsed value and assigned as a property of the output object, effectively leaking a live reference to Array.prototype to the consumer. Any code that subsequently writes to that property will pollute the global prototype. This issue has been patched in version 3.4.2.
Mend Note: The description of this vulnerability differs from MITRE.

Publish Date: 2026-03-20

URL: CVE-2026-33228

CVSS 3 Score Details (9.8)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: High
  • Integrity Impact: High
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Release Date: 2026-03-20

Fix Resolution: https://github.com/WebReflection/flatted.git - v3.4.2

CVE-2026-33750

Vulnerable Library - brace-expansion-1.1.12.tgz

Brace expansion as known from sh/bash

Library home page: https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.12.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

• eslint-9.39.4.tgz (Root Library)
  • minimatch-3.1.5.tgz
    • ❌ brace-expansion-1.1.12.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

The brace-expansion library generates arbitrary strings containing a common prefix and suffix. Prior to versions 5.0.5, 3.0.2, 2.0.3, and 1.1.13, a brace pattern with a zero step value (e.g., "{1..2..0}") causes the sequence generation loop to run indefinitely, making the process hang for seconds and allocate heaps of memory. Versions 5.0.5, 3.0.2, 2.0.3, and 1.1.13 fix the issue. As a workaround, sanitize strings passed to "expand()" to ensure a step value of "0" is not used.

Publish Date: 2026-03-27

URL: CVE-2026-33750

CVSS 3 Score Details (6.5)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: Required
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: None
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Release Date: 2026-03-27

Fix Resolution: https://github.com/juliangruber/brace-expansion.git - v2.0.3,https://github.com/juliangruber/brace-expansion.git - v3.0.2,https://github.com/juliangruber/brace-expansion.git - v5.0.5,https://github.com/juliangruber/brace-expansion.git - v1.1.13

CVE-2026-53550

Vulnerable Library - js-yaml-4.1.1.tgz

YAML 1.2 parser and serializer

Library home page: https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.1.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

• eslint-9.39.4.tgz (Root Library)
  • eslintrc-3.3.5.tgz
    • ❌ js-yaml-4.1.1.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

Summary 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 is "tag:yaml.org,2002:merge". - For each element, it calls "mergeMappings(...)". - "mergeMappings(...)" computes "Object.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); } }

Publish Date: 2026-06-15

URL: CVE-2026-53550

CVSS 3 Score Details (5.3)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: None
  • Availability Impact: Low

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-h67p-54hq-rp68

Release Date: 2026-06-15

Fix Resolution: js-yaml - 4.2.0