fast-xml-parser on npm is safe to use when you stay on a current release and parse only trusted or size-limited input, but older versions carried prototype pollution and denial-of-service flaws you should know about. It is one of the most widely used XML parsers in the JavaScript ecosystem, pulled in directly and transitively by a huge number of projects, which makes its security history worth understanding before you rely on it.
Because npm fast-xml-parser is so common as a transitive dependency, you may be running it without having chosen it. The first practical step is knowing what version resolves in your tree.
Why fast-xml-parser Is Everywhere
XML has not gone away. SOAP APIs, RSS and Atom feeds, sitemaps, SAML assertions, Office document formats, and countless legacy integrations still speak XML. fast-xml-parser earned its popularity by being fast, dependency-light, and able to convert XML to JavaScript objects (and back) with a simple API:
import { XMLParser } from 'fast-xml-parser'
const parser = new XMLParser()
const obj = parser.parse(xmlString)
That convenience is also where the risk lives. Turning arbitrary XML into JavaScript objects means the parser touches property names, entities, and numeric parsing, each of which has produced a security issue at some point.
The CVEs That Mattered
Two vulnerability classes stand out in fast-xml-parser's history, and both are instructive.
Prototype pollution (CVE-2023-26920). In versions prior to 4.1.2, the parser failed to sanitize the __proto__ property when it appeared as a tag or attribute name in XML input. An attacker could craft a document that polluted the JavaScript object prototype, potentially leading to unexpected behavior or, in the worst case, code execution depending on how the resulting object was used downstream. The issue was fixed in version 4.1.2, which sanitizes __proto__ during parsing. Prototype pollution maps to CWE-1321 and is a recurring hazard in any library that builds objects from untrusted key names.
Regular expression denial of service (CVE-2024-41818). A ReDoS flaw was found in the currency-parsing regular expression, where specially crafted input could cause catastrophic backtracking and hang the event loop. This was fixed in version 4.4.1. ReDoS is a subtle risk because the vulnerable code path may look harmless until an attacker feeds it pathological input.
More recent advisories have continued to appear against the library, including denial-of-service issues tied to entity handling that were addressed in later 5.x releases. The pattern is clear: parsers that handle untrusted, structured input attract this kind of finding, and the maintainer has been responsive in shipping fixes. The takeaway is to stay current rather than pin to an old "known good" version indefinitely.
Checking Your Version
Since you may be depending on fast-xml-parser transitively, inspect the resolved version:
npm ls fast-xml-parser
If that shows a version below 4.4.1, you are missing fixes for both issues above. Update the direct dependency if you own it, or use an override to force a patched version when it comes in transitively:
{
"overrides": {
"fast-xml-parser": "^5.0.0"
}
}
Test after upgrading across major versions, since the API and parsing defaults have evolved between the 3.x, 4.x, and 5.x lines.
Safe Usage Patterns
Upgrading closes known holes, but defensive configuration protects you from the next one. A few practices help:
- Limit input size. Reject or truncate XML payloads above a sane threshold before parsing. This blunts most denial-of-service attempts, including ReDoS and entity-expansion attacks.
- Do not trust parsed keys. Treat object keys derived from XML as untrusted. Avoid using them to index into objects you care about without validation, which contains the impact of any residual prototype pollution.
- Validate against a schema when you can. If the XML has a known structure, validate it before or after parsing rather than accepting arbitrary shapes.
- Parse in a bounded context. For high-risk input, parse in a worker or with a timeout so a hang cannot take down the whole process.
The Transitive Dependency Problem
The hardest part of npm fast-xml-parser risk is that it often arrives through another package. You did not npm install it, so you may not think to check it, yet a vulnerable copy deep in your tree is just as exploitable. This is the core case for software composition analysis: an SCA tool such as Safeguard walks the full dependency graph, flags a vulnerable fast-xml-parser buried three levels down, and points you at the override or upgrade that resolves it. Manual npm ls checks work for one package, but they do not scale across a real dependency tree that changes on every install.
The same discipline applies to XML parsing generally. If you handle XML in Java, the JAXP stack has its own XXE risks; our Jackson databind security guide covers a related class of deserialization issues in that ecosystem.
FAQ
Is fast-xml-parser safe to use in 2025?
Yes, on a current version. Stay on at least 4.4.1 to include the prototype pollution and ReDoS fixes, and prefer the latest 5.x release for the most recent hardening. Combine that with input-size limits for untrusted data.
What is the fix for the fast-xml-parser prototype pollution CVE?
CVE-2023-26920 was fixed in version 4.1.2, which sanitizes the __proto__ property during parsing. Upgrade to that version or later.
How do I know if I depend on fast-xml-parser?
Run npm ls fast-xml-parser to see whether it appears in your tree and at what version. It is frequently pulled in transitively, so you may depend on it without a direct install.
Can I force a patched version if it comes in transitively?
Yes. Use the overrides field in package.json (npm) or the equivalent resolutions field for Yarn to pin fast-xml-parser to a patched version across your dependency tree.