GHSA-gpv5-7x3g-ghjv

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

Low npm

Severity: Low; The publisher's own rating, not a CVSS score
Exploit chance (EPSS): —; No score published
Known exploited: No; Not in CISA's catalog
Weakness: —; Not classified
Fix: 4.2.5; Upgrade fast-xml-parser to this version or later

Description

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.

Affected versions

npm

Package	Vulnerable	Fixed in
fast-xml-parser	`>= 4.2.4, < 4.2.5`	`4.2.5`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

fast-xml-parser npm → `4.2.5`

npm

npm install fast-xml-parser@4.2.5

yarn

yarn add fast-xml-parser@4.2.5

pnpm

pnpm add fast-xml-parser@4.2.5

References

Packages

github.com/NaturalIntelligence/fast-xml-parser

Timeline

Jun 15, 2023 Published

Advisory	Severity	Why it's related
GHSA-8r6m-32jq-jx6q fast-xml-parser: Repeated DOCTYPE declarations reset entity expansion limits	High	Also affects fast-xml-parser
GHSA-gh4j-gqv2-49f6 fast-xml-parser XMLBuilder: XML Comment and CDATA Injection via Unescaped Delimiters	Medium	Also affects fast-xml-parser
GHSA-jp2q-39xq-3w4g Entity Expansion Limits Bypassed When Set to Zero Due to JavaScript Falsy Evaluation in fast-xml-parser	Medium	Also affects fast-xml-parser
GHSA-8gc5-j5rx-235r fast-xml-parser affected by numeric entity expansion bypassing all entity expansion limits (incomplete fix for CVE-2026-26278)	High	Also affects fast-xml-parser
GHSA-fj3w-jwp8-x2g3 fast-xml-parser has stack overflow in XMLBuilder with preserveOrder	Low	Also affects fast-xml-parser
GHSA-m7jm-9gc2-mpf2 fast-xml-parser has an entity encoding bypass via regex injection in DOCTYPE entity names	Critical	Also affects fast-xml-parser
GHSA-jmr7-xgp7-cmfj fast-xml-parser affected by DoS through entity expansion in DOCTYPE (no expansion limit)	High	Also affects fast-xml-parser
GHSA-37qj-frw5-hhjh fast-xml-parser has RangeError DoS Numeric Entities Bug	High	Also affects fast-xml-parser

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor