Skip to content

Update dependency fast-xml-parser to v5.5.6 [SECURITY]#5334

Open
renovate[bot] wants to merge 1 commit intomainfrom
renovate/npm-fast-xml-parser-vulnerability
Open

Update dependency fast-xml-parser to v5.5.6 [SECURITY]#5334
renovate[bot] wants to merge 1 commit intomainfrom
renovate/npm-fast-xml-parser-vulnerability

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented Mar 18, 2026

This PR contains the following updates:

Package Change Age Confidence
fast-xml-parser 5.3.85.5.6 age confidence

GitHub Vulnerability Alerts

CVE-2026-27942

Impact

Application crashes with stack overflow when user use XML builder with prserveOrder:true for following or similar input

[{
    'foo': [
        { 'bar': [{ '@​_V': 'baz' }] }
    ]
}]

Cause: arrToStr was not validating if the input is an array or a string and treating all non-array values as text content.
What kind of vulnerability is it? Who is impacted?

Patches

Yes in 5.3.8

Workarounds

Use XML builder with preserveOrder:false or check the input data before passing to builder.

References

Are there any links users can visit to find out more?

CVE-2026-33036

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>${'&#&#8203;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 &#&#8203;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


Release Notes

NaturalIntelligence/fast-xml-parser (fast-xml-parser)

v5.5.6

Compare Source

v5.5.5

Compare Source

v5.5.4

Compare Source

v5.5.3

Compare Source

v5.5.2

Compare Source

v5.5.1: integrate path-expression-matcher

Compare Source

  • support path-expression-matcher
  • fix: stopNode should not be parsed
  • performance improvement for stopNode checking

v5.5.0

Compare Source

v5.4.2

Compare Source

v5.4.1

Compare Source

v5.4.0: Separate Builder

Compare Source

XML Builder was the part of fast-xml-parser for years. But considering that any bug in builder may false-alarm the users who are only using parser and vice-versa, we have decided to split it into a separate package.

Migration

To migrate to fast-xml-builder;

From

import { XMLBuilder } from "fast-xml-parser";

To

import  XMLBuilder  from "fast-xml-builder";

XMLBuilder will be removed from current package in any next major version of this library. So better to migrate.

v5.3.9: support strictReservedNames

Compare Source

Full Changelog: NaturalIntelligence/fast-xml-parser@v5.3.9...v5.3.9


Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants