Search for packages
| purl | pkg:npm/fast-xml-parser@4.2.5 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-87wh-4hga-bbak
Aliases: CVE-2026-26278 GHSA-jmr7-xgp7-cmfj |
Affected by 3 other vulnerabilities. Affected by 4 other vulnerabilities. |
|
|
VCID-8a1h-q8ck-cfbz
Aliases: CVE-2026-25896 GHSA-m7jm-9gc2-mpf2 |
fast-xml-parser allows users to validate XML, parse XML to JS object, or build XML from JS object without C/C++ based libraries and no callback. From 4.1.3to before 5.3.5, 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. This vulnerability is fixed in 5.3.5. |
Affected by 3 other vulnerabilities. Affected by 5 other vulnerabilities. |
|
VCID-9n1q-kn2a-xfca
Aliases: CVE-2026-33036 GHSA-8gc5-j5rx-235r |
Affected by 1 other vulnerability. Affected by 2 other vulnerabilities. |
|
|
VCID-c46j-zfbx-eyc1
Aliases: CVE-2026-33349 GHSA-jp2q-39xq-3w4g |
fast-xml-parser allows users to process XML from JS object without C/C++ based libraries or callbacks. From version 4.0.0-beta.3 to before version 5.5.7, 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. This issue has been patched in version 5.5.7. |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-fbce-cxkc-3ube
Aliases: CVE-2026-41650 GHSA-gh4j-gqv2-49f6 |
Affected by 0 other vulnerabilities. |
|
|
VCID-z5yj-54hc-qyb9
Aliases: CVE-2026-27942 GHSA-fj3w-jwp8-x2g3 |
fast-xml-parser has stack overflow in XMLBuilder with preserveOrder |
Affected by 3 other vulnerabilities. Affected by 3 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-ezvf-cnzj-akgm | 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 is a Name: ``` [4] NameStartChar ::= ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF] [4a] NameChar ::= NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040] [5] Name ::= NameStartChar (NameChar)* ``` 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 character properties, but I don't know enough to do so. |
GHSA-gpv5-7x3g-ghjv
GMS-2023-1884 |