CVE-2026-33036

What it actually does

CVE-2026-33036 is an availability vulnerability in naturalintelligence fast-xml-parser versions 4.0.0-beta.3 through 5.5.5. The parser’s entity expansion controls, such as maxTotalExpansions and maxExpandedLength, are applied to DOCTYPE-defined entities but not to numeric character references such as &#NNN; and &#xHH; or standard XML entities handled in the lastEntities loop. As a result, XML containing a very large number of numeric or standard entity references can bypass configured expansion limits, causing excessive CPU consumption and memory allocation during parsing. In Node.js applications, this can lead to event-loop starvation, process crashes, out-of-memory failures, container restarts, or degraded service availability.

Why it matters to the business

Applications that accept and parse untrusted XML can be forced offline or made intermittently unavailable by a single crafted request or message. This can disrupt APIs, integrations, background processing pipelines, file ingestion workflows, authentication flows that consume XML, and services using XML-based partner or customer data. Although the vulnerability does not directly expose or modify data, it can create operational outages, failed transactions, increased infrastructure costs from crash loops or autoscaling, and customer-facing service degradation. The issue is not currently listed in CISA KEV and has low EPSS at the time provided, but it is low-complexity, network-exploitable, unauthenticated, and affects a widely used JavaScript XML parsing library, so internet-facing XML ingestion points should be prioritized.

How an attack unfolds

An attacker first identifies an endpoint, queue, upload feature, API, webhook, or integration that accepts XML and is parsed by an affected fast-xml-parser version. They then submit XML containing a very large number of numeric character references, hexadecimal character references, or standard XML entities. Because vulnerable versions count expansion only for DOCTYPE-defined entities, the attacker’s payload avoids the configured entity expansion safeguards. During parsing, fast-xml-parser repeatedly replaces those references, allocating large strings and consuming CPU. With sufficiently large input, the Node.js process may become unresponsive, exceed heap limits, crash, or trigger repeated restarts. If the vulnerable parser runs in a shared service, the denial of service may affect unrelated requests handled by the same process.

How to fix it

Upgrade naturalintelligence fast-xml-parser to version 5.5.6 or later. Treat this as the primary fix because application-level entity expansion limits in affected versions can be bypassed. If immediate upgrade is not possible, apply compensating controls: reject or strictly limit XML from untrusted sources, enforce maximum request and file sizes before parsing, rate-limit XML submission endpoints, isolate XML parsing in a worker process with strict memory and CPU limits, set conservative Node.js heap/container limits with safe restart behavior, and add pre-parse validation to reject inputs containing unusually high counts of numeric character references, hexadecimal character references, or standard entities. Review direct and transitive dependencies to ensure no application component continues to bundle fast-xml-parser versions 4.0.0-beta.3 through 5.5.5.

How to confirm the fix worked

Confirm the deployed dependency tree resolves fast-xml-parser to 5.5.6 or later using package manager tooling such as npm ls fast-xml-parser, yarn why fast-xml-parser, pnpm why fast-xml-parser, or software composition analysis. Verify lockfiles and production artifacts, not only package.json, because vulnerable versions may be present transitively. Test XML ingestion paths with a safe, bounded payload containing repeated numeric references and verify that parsing is rejected quickly or completes within expected CPU and memory limits. Confirm that application logs no longer show heap exhaustion, parser timeouts, crash loops, or restarts when handling malformed or entity-heavy XML. Validate that upstream request-size limits, upload limits, queue message-size limits, and rate limits are active for XML-processing routes.

Typical attack path

1. Identify an application feature or service that accepts XML from untrusted or semi-trusted sources.
2. Confirm that the XML is processed by an affected fast-xml-parser version, directly or through a dependent package.
3. Craft XML containing a very large number of numeric character references such as repeated A or hexadecimal references such as repeated A.
4. Send the crafted XML to the target endpoint, upload workflow, message queue, webhook, or integration.
5. Trigger parsing so the vulnerable replacement logic processes numeric or standard entities without enforcing expansion limits.
6. Cause high CPU usage, large memory allocation, event-loop blocking, process termination, container restart, or service unavailability.
7. Repeat requests or messages to sustain the outage or amplify impact across multiple workers or services.

How to detect it

To determine whether exploitation has already occurred, review telemetry from services that accept XML, including HTTP access logs, reverse proxy logs, WAF logs, API gateway logs, application logs, container runtime events, Node.js process logs, APM traces, queue dead-letter logs, upload-processing logs, and orchestration restart histories. Look for requests, files, or messages containing unusually large numbers of numeric character references such as A or hexadecimal references such as A, especially if followed by long response times, 5xx errors, request timeouts, worker crashes, pod/container restarts, or Node.js heap exhaustion. In application logs, correlate XML parsing attempts with CPU saturation, memory spikes, event-loop delay, garbage collection pressure, and fatal JavaScript heap errors. In WAF or API gateway logs, search request bodies, sampled payloads, and blocked/allowed events for repeated entity-reference patterns. In package and deployment telemetry, identify services running fast-xml-parser versions 4.0.0-beta.3 through 5.5.5 and focus retrospective analysis around XML submission paths. Absence of payload logging does not prove absence of exploitation; use timing, crash, memory, and restart correlations around XML-processing endpoints or consumers.

• fast-xml-parser@4.0.0-beta.3
• fast-xml-parser@5.5.5
• node_modules/fast-xml-parser/src/xmlparser/OrderedObjParser.js
• replaceEntitiesValue
• &#[0-9]+;
• &#x[0-9A-Fa-f]+;
• &
• <
• >
• "
• '
• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed
• Allocation failed - JavaScript heap out of memory
• maxTotalExpansions
• maxExpandedLength

What your security team should do

• Inventory applications, services, serverless functions, workers, and containers that use fast-xml-parser directly or transitively.
• Prioritize remediation for internet-facing XML APIs, upload endpoints, webhooks, partner integrations, SAML/XML workflows, and message consumers that process untrusted XML.
• Upgrade fast-xml-parser to 5.5.6 or later and rebuild/redeploy affected artifacts from clean dependency lockfiles.
• Add temporary controls that reject oversized XML and entity-dense XML until all vulnerable deployments are upgraded.
• Configure runtime isolation for XML parsing, including memory limits, CPU limits, worker isolation, request timeouts, and safe circuit breakers.
• Search logs and telemetry for recent spikes in XML parsing errors, Node.js out-of-memory crashes, container restarts, request timeouts, and repeated requests containing numeric or hexadecimal XML character references.
• Add SIEM and WAF detections for unusually high counts of patterns such as &#NNN; and &#xHH; in request bodies, uploaded XML, or queue messages where logging is available.
• Monitor dependency alerts and downstream packages that may embed or pin affected fast-xml-parser versions.