Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact fast-xml-parser processes multiple "DOCTYPE" declarations within a single XML document. Each declaration passes its entities to @nodable/entities through addInputEntities(). addInputEntities() resets the entity expansion counters every time it is called. An attacker can therefore insert additional DOCTYPE declarations to repeatedly reset maxTotalExpansions and maxExpandedLength during one parse operation. This allows a crafted XML document to exceed the configured entity-expansion limits and can cause excessive CPU use, event-loop blocking, memory exhaustion, and process termination. Workarounds - Manually check if multiple DOCTYPEs are not present in input contents - Update to v5.10.1 - Keep processEntity flag off
Recommended action: Upgrade to 5.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
fast-xml-parser XMLBuilder: Comment and CDATA Injection via Unescaped Delimiters Summary fast-xml-parser XMLBuilder does not escape the -- sequence in comment content or the ]] sequence in CDATA sections when building XML from JavaScript objects. This allows XML injection when user-controlled data flows into comments or CDATA elements, leading to XSS, SOAP injection, or data manipulation. Existing CVEs for fast-xml-parser cover different issues: - CVE-2023-26920: Prototype pollution (parser) - CVE-2023-34104: ReDoS (parser) - CVE-2026-27942: Stack overflow in XMLBuilder with preserveOrder - CVE-2026-25896: Entity encoding bypass via regex in DOCTYPE entities This finding covers unescaped comment/CDATA delimiters in XMLBuilder - a distinct vulnerability. Vulnerable Code File: src/fxb.js Compare with attribute/text escaping which IS properly handled via replaceEntitiesValue(). Proof of Concept Test 1: Comment Injection (XSS in SVG/HTML context) Output: Test 2: CDATA Injection (RSS…
Recommended action: Upgrade to 5.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 expansion, leading to memory exhaustion and denial of service. Details The OptionsBuilder.js correctly preserves a user-supplied value of 0 using nullish coalescing (??): However, DocTypeReader.js uses truthy evaluation to check these limits. Because 0 is falsy in JavaScript, the entire guard expression short-circuits to false, and the limit is never enforced: The execution flow is: 1. Developer configures processEntities: { maxEntityCount: 0, maxEntitySize: 0 } intending to block all entity definitions. 2.…
Recommended action: Upgrade to 5.5.7 or 4.5.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 5.5.6 or 4.5.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Application crashes with stack overflow when user use XML builder with prserveOrder:true for following or similar input 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?
Recommended action: Upgrade to 5.3.8 or 4.5.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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(): 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: Shadowing all 5 built-in…
Recommended action: Upgrade to 5.3.5 or 4.5.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 5.3.6 or 4.5.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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., � or �). 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: 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: This causes the RangeError to propagate uncaught, crashing the parser and any application using it. PoC Setup Create a directory with these files: package.json server.js Run Result Server crashes with: Alternative Payloads Impact Denial of Service…
Recommended action: Upgrade to 5.3.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A ReDOS that exists on currency.js was discovered by Gauss Security Labs R&D team. Details https://github.com/NaturalIntelligence/fast-xml-parser/blob/v4.4.0/src/v5/valueParsers/currency.js#L10 contains a vulnerable regex PoC pass the following string '\t'.repeat(13337) + '.' Impact Denial of service during currency parsing in experimental version 5 of fast-xml-parser-library https://gauss-security.com
Recommended action: Upgrade to 4.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 is a Name: so the safest way to validate an entity name is to build a regex to represent this expression and check whether the name given matches the regex. (Something along the lines of /^[name start char class][name char class]$/.) There's probably a nice way to simplify the explicit list rather than typing it out verbatim using Unicode…
Recommended action: Upgrade to 4.2.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact As a part of this vulnerability, user was able to se code using `proto` as a tag or attribute name. ```js const { XMLParser, XMLBuilder, XMLValidator} = require("fast-xml-parser"); let XMLdata = " hacked " 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. References https://gist.github.com/Sudistark/a5a45bd0804d522a1392cb5023aa7ef7
Recommended action: Upgrade to 4.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact "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 stall for an indefinite amount of time. Patches The problem has been resolved in v4.2.4 Workarounds Avoid using DOCTYPE parsing by processEntities: false option.
Recommended action: Upgrade to 4.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.