Advisories for Npm/Fast-Xml-Parser package

2026

Entity Expansion Limits Bypassed When Set to Zero Due to JavaScript Falsy Evaluation in fast-xml-parser

The DocTypeReader in fast-xml-parser uses JavaScript truthy checks to evaluate maxEntityCount and maxEntitySize configuration limits. When a developer explicitly sets either limit to 0 — intending to disallow all entities or restrict entity size to zero bytes — the falsy nature of 0 in JavaScript causes the guard conditions to short-circuit, completely bypassing the limits. An attacker who can supply XML input to such an application can trigger unbounded entity …

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

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 …

2024
2023

fast-xml-parser regex vulnerability patch could be improved from a safety perspective

Summary This is a comment on https://github.com/NaturalIntelligence/fast-xml-parser/security/advisories/GHSA-6w63-h3fj-q4vw and the patches fixing it. Details The code which validates a name calls the validator: https://github.com/NaturalIntelligence/fast-xml-parser/blob/ecf6016f9b48aec1a921e673158be0773d07283e/src/xmlparser/DocTypeReader.js#L145-L153 This checks for the presence of an invalid character. Such an approach is always risky, as it is so easy to forget to include an invalid character in the list. A safer approach is to validate entity names against the XML specification: https://www.w3.org/TR/xml11/#sec-common-syn - an ENTITY name …

fast-xml-parser vulnerable to Prototype Pollution through tag or attribute name

Impact As a part of this vulnerability, user was able to se code using proto as a tag or attribute name. const { XMLParser, XMLBuilder, XMLValidator} = require("fast-xml-parser"); let XMLdata = "<proto><polluted>hacked</polluted></proto>" const parser = new XMLParser(); let jObj = parser.parse(XMLdata); console.log(jObj.polluted) // should return hacked Patches The problem has been patched in v4.1.2 Workarounds User can check for "proto" in the XML string before parsing it to the parser. …

fast-xml-parser vulnerable to Regex Injection via Doctype Entities

"fast-xml-parser" allows special characters in entity names, which are not escaped or sanitized. Since the entity name is used for creating a regex for searching and replacing entities in the XML body, an attacker can abuse it for DoS attacks. By crafting an entity name that results in an intentionally bad performing regex and utilizing it in the entity replacement step of the parser, this can cause the parser to …