fast-xml-parser

### 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 t

CVE: CVE-2026-73569

# 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 pres

CVE: CVE-2026-41650

## Summary 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 pr

CVE: CVE-2026-33349

## 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 all

CVE: CVE-2026-33036

### 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?_](http

CVE: CVE-2026-27942

# 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

CVE: CVE-2026-25896

### 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

CVE: CVE-2026-26278

### 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., `�` 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: ```javascript "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.fromC

CVE: CVE-2026-25128

### Summary 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

CVE: CVE-2024-41818

### 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: