CVE-2026-33349

What it actually does

fast-xml-parser versions 4.0.0-beta.3 through versions before 5.5.7 contain a denial-of-service flaw in DocTypeReader’s enforcement of XML entity limits. If an application explicitly configures maxEntityCount or maxEntitySize as 0, JavaScript truthiness checks treat the value as false and skip the intended guard logic. This can allow XML documents with entity declarations or entity expansion payloads to bypass configured restrictions, causing excessive memory consumption and process instability or crashes.

Why it matters to the business

Applications that parse untrusted XML with affected fast-xml-parser versions may be vulnerable to service disruption if they use zero-valued entity limits. Successful exploitation can degrade or take down API endpoints, ingestion pipelines, message processors, or backend services that process XML. The CVSS score indicates moderate severity with high availability impact, but exploitation depends on a specific application configuration, reflected by the low EPSS score and lack of known KEV listing. Organizations should still remediate because XML parsing bugs can be triggered remotely wherever attacker-controlled XML is accepted.

How an attack unfolds

An attacker identifies an application endpoint, upload feature, integration, or message-processing path that accepts XML and parses it with a vulnerable version of fast-xml-parser. The vulnerable application must be configured with maxEntityCount or maxEntitySize set to 0, likely with the intent to fully block entities or entity content. The attacker submits a crafted XML document containing a document type definition and entity expansion structure. Because the parser evaluates the configured zero limit with a truthy check, the limit enforcement is skipped. The parser then processes entities beyond the intended boundary, consuming increasing memory and CPU until the Node.js process slows, becomes unresponsive, is killed by the runtime or container orchestrator, or causes broader service degradation.

How to fix it

Upgrade fast-xml-parser to version 5.5.7 or later. If package manifests allow broad version ranges, regenerate and redeploy lockfiles so the fixed version is actually installed in production artifacts. As defense in depth, reject XML containing DOCTYPE declarations or entity definitions when they are not required, enforce request body size limits at gateways and application servers, set parser limits to safe positive values rather than relying on zero as a blocking control, and isolate XML parsing work with memory and execution-time limits. For services that cannot immediately upgrade, add pre-parse validation to block `<!DOCTYPE`, `<!ENTITY`, and unusually large or nested XML payloads from untrusted sources.

How to confirm the fix worked

Confirm dependency resolution shows fast-xml-parser version 5.5.7 or later in deployed builds, containers, serverless packages, and transitive dependency trees. Use package-manager commands such as `npm ls fast-xml-parser`, `yarn why fast-xml-parser`, or `pnpm why fast-xml-parser` during build validation. Review parser configuration for maxEntityCount or maxEntitySize set to 0 and verify the upgraded parser enforces those settings as intended. Test representative XML ingestion paths with benign DOCTYPE/entity payloads to confirm they are rejected or safely bounded without excessive memory growth. Validate edge controls enforce request-size limits and that application monitoring does not show crashes, restarts, or out-of-memory events during XML parsing tests.

Typical attack path

1. Find an internet-facing or reachable service that accepts XML input, such as an API, file upload, webhook, import feature, or integration endpoint.
2. Confirm or infer that the service uses an affected fast-xml-parser version and permits XML documents containing a DOCTYPE declaration or entity definitions.
3. Send crafted XML containing entity declarations and expansion patterns designed to consume memory.
4. Rely on an application configuration where maxEntityCount or maxEntitySize is explicitly set to 0, causing vulnerable guard checks to be bypassed.
5. Repeat or scale requests to exhaust memory, crash parser workers, trigger container restarts, or make the service unavailable.

How to detect it

Review application, API gateway, WAF, and load balancer logs for XML requests containing DOCTYPE or ENTITY declarations, especially near service slowdowns, Node.js crashes, container restarts, or out-of-memory events. Correlate suspicious XML submissions with runtime logs showing heap exhaustion, fatal JavaScript allocation failures, high memory use, increased garbage collection, request timeouts, 5xx spikes, or orchestrator OOMKilled events. Inspect package manifests and lockfiles to identify affected fast-xml-parser versions and code/configuration where maxEntityCount or maxEntitySize is set to 0. Because there are no public exploit-specific artifacts in the provided intelligence, detection should focus on malicious XML structure and availability-impact telemetry rather than a fixed payload signature.

• <!DOCTYPE
• <!ENTITY
• SYSTEM "file://
• PUBLIC "-//
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• JavaScript heap out of memory
• Allocation failed - process out of memory
• Ineffective mark-compacts near heap limit
• OOMKilled
• maxEntityCount: 0
• maxEntitySize: 0
• fast-xml-parser

What your security team should do

• Inventory applications and services that use fast-xml-parser, including transitive dependencies in Node.js projects.
• Prioritize externally reachable XML-processing endpoints, file importers, webhooks, queues, and partner integrations that accept untrusted XML.
• Upgrade fast-xml-parser to 5.5.7 or later and rebuild deployment artifacts from clean lockfiles.
• Search code and configuration for maxEntityCount: 0 or maxEntitySize: 0 and replace reliance on zero-valued limits with patched parser behavior plus explicit DOCTYPE/entity blocking where appropriate.
• Add gateway, WAF, or application-layer controls to reject untrusted XML containing DOCTYPE or ENTITY declarations unless business-critical.
• Monitor for memory exhaustion, process crashes, container OOM kills, and spikes in XML parsing errors around public XML endpoints.
• Add regression tests for XML entity expansion and zero-valued parser-limit configurations to prevent reintroduction.