NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
HIGH severity

CVE-2026-33036 — fast-xml-parser

HIGHFix: NaturalIntelligence/fast-xml-parser@bd26122

CVE-2026-33036 is a high-severity (CVSS 7.5) CWE-776 vulnerability in fast-xml-parser. A fix is available for fast-xml-parser — see the affected versions and patch details below.

fast-xml-parser affected by numeric entity expansion bypassing all entity expansion limits (incomplete fix for CVE-2026-26278)

Also known asGHSA-8gc5-j5rx-235r
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Nov 7, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-33036.

EPSS Exploitation Probability

via FIRST.org ↗
0.6%probability of exploitation in next 30 days
Lower Risk+0.01%
Lower risk than most CVEs50th percentile — riskier than 50% of all scored CVEsHighest risk
0.00%0.41%0.82%1.23%0.0%0.6%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

2 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

6Kother npm packages depend on this — each one inherits the vulnerability until it's patched upstream
fast-xml-parsernpm
114.5Mdownloads / week

Description

Summary

The fix for CVE-2026-26278 added entity expansion limits (maxTotalExpansions, maxExpandedLength, maxEntityCount, maxEntitySize) to prevent XML entity expansion Denial of Service. However, these limits are only enforced for DOCTYPE-defined entities. Numeric character references (&#NNN; and &#xHH;) and standard XML entities (<, >, etc.) are processed through a separate code path that does NOT enforce any expansion limits.

An attacker can use massive numbers of numeric entity references to completely bypass all configured limits, causing excessive memory allocation and CPU consumption.

Affected Versions

fast-xml-parser v5.x through v5.5.3 (and likely v5.5.5 on npm)

Root Cause

In src/xmlparser/OrderedObjParser.js, the replaceEntitiesValue() function has two separate entity replacement loops:

  1. Lines 638-670: DOCTYPE entities — expansion counting with entityExpansionCount and currentExpandedLength tracking. This was the CVE-2026-26278 fix.
  2. Lines 674-677: lastEntities loop — replaces standard entities including num_dec (/&#([0-9]{1,7});/g) and num_hex (/&#x([0-9a-fA-F]{1,6});/g). This loop has NO expansion counting at all.

The numeric entity regex replacements at lines 97-98 are part of lastEntities and go through the uncounted loop, completely bypassing the CVE-2026-26278 fix.

Proof of Concept

const { XMLParser } = require('fast-xml-parser');

// Even with strict explicit limits, numeric entities bypass them
const parser = new XMLParser({
  processEntities: {
    enabled: true,
    maxTotalExpansions: 10,
    maxExpandedLength: 100,
    maxEntityCount: 1,
    maxEntitySize: 10
  }
});

// 100K numeric entity references — should be blocked by maxTotalExpansions=10
const xml = `<root>${'&#65;'.repeat(100000)}</root>`;
const result = parser.parse(xml);

// Output: 500,000 chars — bypasses maxExpandedLength=100 completely
console.log('Output length:', result.root.length);  // 500000
console.log('Expected max:', 100);  // limit was 100

Results:

  • 100K &#65; references → 500,000 char output (5x default maxExpandedLength of 100,000)
  • 1M references → 5,000,000 char output, ~147MB memory consumed
  • Even with maxTotalExpansions=10 and maxExpandedLength=100, 10K references produce 50,000 chars
  • Hex entities (&#x41;) exhibit the same bypass

Impact

Denial of Service — An attacker who can provide XML input to applications using fast-xml-parser can cause:

  • Excessive memory allocation (147MB+ for 1M entity references)
  • CPU consumption during regex replacement
  • Potential process crash via OOM

This is particularly dangerous because the application developer may have explicitly configured strict entity expansion limits believing they are protected, while numeric entities silently bypass all of them.

Suggested Fix

Apply the same entityExpansionCount and currentExpandedLength tracking to the lastEntities loop (lines 674-677) and the HTML entities loop (lines 680-686), similar to how DOCTYPE entities are tracked at lines 638-670.

Workaround

Set htmlEntities:false

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
📦npmfast-xml-parser≥ 5.0.0&&< 5.5.65.5.6npm install fast-xml-parser@5.5.6
📦npmfast-xml-parser≥ 4.0.0-beta.3&&< 4.5.54.5.5npm install fast-xml-parser@4.5.5

Affected Products

1 product · 8 configurations
Application
fast-xml-parsernaturalintelligence
≥ 4.0.1 && < 5.5.6
1 version
4.0.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for fast-xml-parser, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update fast-xml-parser to 5.5.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-33036 is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate
Workaround published by Red Hat
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Source: Red Hat security advisory for CVE-2026-33036 (CC BY 4.0)
ProductFixed inAdvisory
Red Hat Advanced Cluster Security 4.8advanced-cluster-security/rhacs-main-rhel8:1775594119RHSA-2026:7110
Red Hat Advanced Cluster Security 4.9advanced-cluster-security/rhacs-main-rhel8:1775594284RHSA-2026:7128
Red Hat Developer Hub 1.8rhdh/rhdh-hub-rhel9:1776784286RHSA-2026:9742
Red Hat Openshift Data Foundation 4.16odf4/cephcsi-rhel9:1778076673RHSA-2026:17549
Red Hat Openshift Data Foundation 4.17odf4/cephcsi-rhel9:1778049594RHSA-2026:17550
Red Hat Openshift Data Foundation 4.18odf4/cephcsi-rhel9:1778045210RHSA-2026:17547
Red Hat Openshift Data Foundation 4.18odf4/cephcsi-rhel9:1783676191RHSA-2026:41941
Red Hat Openshift Data Foundation 4.19odf4/cephcsi-rhel9:1776079019RHSA-2026:12279

Frequently Asked Questions

## Summary The fix for CVE-2026-26278 added entity expansion limits (`maxTotalExpansions`, `maxExpandedLength`, `maxEntityCount`, `maxEntitySize`) to prevent XML entity expansion Denial of Service. However, these limits are only enforced for DOCTYPE-defined entities. **Numeric character references** (`&#NNN;` and `&#xHH;`) and standard XML entities (`&lt;`, `&gt;`, etc.) are processed through a separate code path that does NOT enforce any expansion limits. An attacker can use massive numbers of numeric entity references to completely bypass all configured limits, causing excessive memory all
O3 Security · Impact-Aware SCA

Is CVE-2026-33036 in your dependencies?

Find it across npm, including transitive dependencies.

CVE-2026-33036: fast-xml-parser DoS — Fixed in 5.5.6