CVE-2026-25896

What it actually does

fast-xml-parser versions from 4.1.3 before 5.3.5 incorrectly handle dots in XML DOCTYPE entity names during entity replacement. Because the dot is interpreted like a regular-expression wildcard rather than a literal character, a crafted entity name can match and override built-in XML entities such as <, >, &, ", and '. When an application parses attacker-controlled XML and later renders the parsed output into HTML or another browser-executed context, the attacker can bypass expected entity encoding and inject executable script. The primary technical impact is cross-site scripting with high integrity impact in applications that trust fast-xml-parser output as safely encoded content.

Why it matters to the business

Applications that accept XML from users, partners, feeds, APIs, integrations, or uploaded documents may unintentionally convert malicious XML into active browser content. Successful exploitation can lead to account takeover, unauthorized user actions, session or token theft, data exposure visible to the victim, fraudulent transactions, and reputational damage. Although the current EPSS is low and the issue is not in CISA KEV, the CVSS score is high because exploitation can be remote, unauthenticated, and may require no user interaction beyond normal application processing and rendering of attacker-supplied content.

How an attack unfolds

An attacker identifies an application or service that uses an affected version of fast-xml-parser to parse XML supplied through an API request, file upload, message queue, webhook, syndication feed, SAML-like document flow, or other XML ingestion path. The attacker crafts XML containing a DOCTYPE declaration with an entity name that includes a dot character arranged to shadow a built-in XML entity during replacement. Because the parser treats the dot as a wildcard, the malicious entity definition can cause characters that should remain safely encoded to be replaced with attacker-controlled markup or JavaScript-bearing content. The application then stores, reflects, logs, previews, or otherwise renders the parsed value in a web page without an additional safe-output-encoding layer. When a user or administrator views the affected content, the browser executes the injected script in the security context of the application.

How to fix it

Upgrade fast-xml-parser to version 5.3.5 or later wherever it is used. For source deployments tracking the Git repository, ensure the fix commit fe9a85270122036ae22637167ce38a5f71b73a5f or a later commit is present. Because the vulnerable range is 4.1.3 through versions before 5.3.5, do not rely on minor-version pinning within the 4.x line unless a downstream maintainer has explicitly backported the fix. Regenerate lockfiles and rebuild containers, serverless packages, frontend bundles, and transitive dependency trees so the patched parser is actually deployed. As defense in depth, disable or restrict DTD/DOCTYPE and custom entity processing where not required, treat parsed XML as untrusted data, apply context-appropriate output encoding at every browser-rendered sink, and enforce a restrictive Content Security Policy to reduce the impact of any remaining XSS path.

How to confirm the fix worked

Confirm dependency resolution with package manager tooling such as npm ls fast-xml-parser, yarn why fast-xml-parser, pnpm why fast-xml-parser, SCA reports, SBOMs, container scans, and build artifacts. Validate that no deployed artifact contains fast-xml-parser versions >=4.1.3 and <5.3.5. If using a Git-sourced dependency, verify that commit fe9a85270122036ae22637167ce38a5f71b73a5f or a later commit is included. Perform targeted functional testing by submitting benign XML containing DOCTYPE entity definitions with dot characters in entity names and verifying that built-in entities cannot be shadowed or converted into executable markup. Also test browser-rendered views that display parsed XML data to ensure output is encoded according to context and that injected tags or event handlers render as text rather than executing.

Typical attack path

1. Find an externally reachable feature that accepts XML or consumes XML from an attacker-influenced source.
2. Confirm or infer that the application uses fast-xml-parser version 4.1.3 through before 5.3.5.
3. Create XML containing a DOCTYPE declaration with a crafted entity name using a dot to collide with a built-in XML entity replacement.
4. Submit the XML through an API, upload, webhook, feed, or integration path.
5. Cause the application to parse the XML and produce output containing attacker-controlled markup that bypassed expected entity encoding.
6. Trigger rendering of the parsed output in a browser context, such as a preview page, admin console, report, message viewer, or stored record.
7. Execute JavaScript in the victim's browser to steal session data, perform actions as the victim, alter displayed content, or pivot within the application.

How to detect it

Look for evidence that untrusted XML containing unusual DOCTYPE or ENTITY declarations was submitted to endpoints, queues, uploads, webhooks, or integrations that parse XML and later render the parsed output. Useful sources include web server access logs, API gateway logs, WAF logs, application request logs, file upload metadata, message broker payload archives, object storage access logs, XML processing error logs, browser-side CSP violation reports, and application audit logs showing creation or modification of XML-backed records. Focus on payloads with DOCTYPE declarations that define entities with dots in their names, attempts to redefine or influence built-in XML entities, and XML values that decode into HTML tags, script blocks, JavaScript URLs, or event-handler attributes. For confirmed exposure, review stored records created from XML during the vulnerable period and investigate users who viewed those records for suspicious session activity, unexpected administrative actions, token use from unusual IPs, or CSP/XSS telemetry. Because no public exploit maturity or named threat actors are provided and the issue is not in KEV, detections should be behavior- and payload-based rather than actor-specific.

• <!DOCTYPE
• <!ENTITY
• <!ENTITY .
• <!ENTITY l.
• <!ENTITY g.
• <!ENTITY a.
• <!ENTITY q.
• <!ENTITY apos.
• <!ENTITY quot.
• <!ENTITY amp.
• <!ENTITY lt.
• <!ENTITY gt.
• &lt;script
• <script
• javascript:
• onerror=
• onload=
• <img src=x onerror=
• fast-xml-parser@4.1.3
• fast-xml-parser@4.1.4
• fast-xml-parser@4.2.
• fast-xml-parser@4.3.
• fast-xml-parser@4.4.
• fast-xml-parser@4.5.
• fast-xml-parser@5.0.
• fast-xml-parser@5.1.
• fast-xml-parser@5.2.
• "fast-xml-parser": "4.
• "fast-xml-parser":"4.
• "fast-xml-parser": "5.0
• "fast-xml-parser":"5.0
• "fast-xml-parser": "5.1
• "fast-xml-parser":"5.1
• "fast-xml-parser": "5.2
• "fast-xml-parser":"5.2

What your security team should do

• Inventory all applications, services, jobs, and client-side bundles that depend on fast-xml-parser directly or transitively.
• Prioritize remediation for internet-facing XML ingestion points, administrative consoles that render parsed XML, partner integration gateways, upload processors, and applications handling privileged user sessions.
• Upgrade to fast-xml-parser 5.3.5 or later, or verify inclusion of fix commit fe9a85270122036ae22637167ce38a5f71b73a5f for Git-based deployments.
• Regenerate and redeploy lockfiles, containers, functions, and static bundles to eliminate stale vulnerable copies.
• Add dependency scanning gates that fail builds when fast-xml-parser versions >=4.1.3 and <5.3.5 are introduced.
• Review XML-processing code paths and disable DTD/DOCTYPE or entity processing unless explicitly required.
• Audit browser-rendered sinks that display parsed XML content and enforce framework-native escaping or context-specific output encoding.
• Deploy or tighten Content Security Policy controls to reduce the blast radius of XSS, especially by avoiding unsafe-inline script execution.
• Search historical logs and stored XML payloads for suspicious DOCTYPE declarations and entity names containing dots, particularly where submitted by unauthenticated or low-trust users.