CVE-2026-26278

What it actually does

fast-xml-parser versions 4.1.3 through 5.3.5 can be driven into unbounded XML entity expansion when parsing XML that includes a DOCTYPE with nested or recursive entity definitions. A small attacker-controlled XML document can expand into a very large in-memory representation or force repeated entity substitution, consuming CPU time and potentially memory until the Node.js process becomes unresponsive. The practical impact is denial of service: no authentication or user interaction is required if an application exposes XML parsing to the network, and the CVSS vector indicates high availability impact with no direct confidentiality or integrity impact. Version 5.3.6 and commit ecb2ca118ad3d6c62f2cc90416b58da24db5d18b address the issue in naturalintelligence/fast-xml-parser; internationalcolorconsortium/iccdev is listed as affected with a fix in commit 2eb25ab95f0db7664ec3850390b6f89e302e7039.

Why it matters to the business

Applications, APIs, ingestion pipelines, webhooks, file upload processors, and background workers that accept XML from untrusted sources can be slowed or frozen by a very small malicious request or file. This can cause service outages, request backlog, failed transactions, autoscaling cost spikes, degraded customer experience, and operational incident response even though the flaw does not directly expose data. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS at 0.00843 with no reported mature public exploit, but it is still important for internet-facing XML processing paths because exploitation is simple once an attacker can submit XML.

How an attack unfolds

An attacker first identifies an endpoint, queue, upload feature, integration, or service that parses XML using an affected fast-xml-parser version or a downstream component that embeds it. The attacker submits a crafted XML document containing a DOCTYPE section with many nested entity declarations, commonly similar to a "Billion Laughs" payload. When the application parses the XML with entity processing enabled, the parser repeatedly expands the defined entities without an effective expansion limit. A small request can therefore cause seconds or minutes of CPU-bound processing, high event-loop latency, memory pressure, request timeouts, and worker saturation. Repeated submissions can keep the application or parsing workers unavailable, resulting in a denial-of-service condition. No evidence in the provided data indicates active exploitation by named threat actors, KEV inclusion, ransomware usage, or reliable remote code execution from this flaw.

How to fix it

Upgrade naturalintelligence/fast-xml-parser to version 5.3.6 or later. For source-based deployments, ensure the fix from commit ecb2ca118ad3d6c62f2cc90416b58da24db5d18b is present. For internationalcolorconsortium/iccdev, update to a revision containing commit 2eb25ab95f0db7664ec3850390b6f89e302e7039. If immediate upgrade is not possible, disable XML entity processing by configuring fast-xml-parser with `processEntities: false`, and reject XML containing `<!DOCTYPE` or `<!ENTITY` at trust boundaries where those features are not explicitly required. Add request body size limits, parser timeouts, worker isolation, rate limiting, queue backpressure, and circuit breakers around XML ingestion paths. Ensure software composition analysis covers transitive dependencies and downstream packages that bundle or pin vulnerable fast-xml-parser versions.

How to confirm the fix worked

Confirm dependency versions with package lockfiles, SBOMs, container image scans, and runtime dependency inspection; affected fast-xml-parser versions are 4.1.3 through 5.3.5, and fixed version is 5.3.6 or later. Verify that the deployed artifact actually contains the patched dependency, not only the source repository. Review XML parser configuration and confirm `processEntities: false` is set where entity expansion is not required. Test exposed XML ingestion paths with a safe, bounded entity-expansion test payload in a non-production environment and confirm the request is rejected quickly or completes within expected limits without CPU spikes. Validate that WAF/API gateway rules, upload validators, or application middleware reject unexpected `DOCTYPE` and `ENTITY` declarations. Monitor after deployment for normal request latency, reduced parser CPU time, and absence of recurring XML parse timeouts.

Typical attack path

1. Find an application feature that accepts XML over HTTP, message queues, file uploads, API integrations, or batch import jobs.
2. Confirm that malformed or complex XML is processed server-side rather than rejected at the edge.
3. Send XML containing a DOCTYPE declaration with nested or recursively referenced entity definitions.
4. Trigger parsing with entity processing enabled in fast-xml-parser versions 4.1.3 through 5.3.5 or an affected downstream product.
5. Force excessive entity expansion, causing high CPU usage, event-loop blocking, memory pressure, long response times, or process unresponsiveness.
6. Repeat requests or uploads to sustain application-level denial of service and exhaust worker capacity.

How to detect it

To determine whether exploitation has already occurred, review application access logs, API gateway logs, WAF logs, upload metadata, message queue payload samples, and XML ingestion service logs for requests or files containing `<!DOCTYPE` and `<!ENTITY` declarations, especially nested entity chains. Correlate these events with abnormal CPU saturation, Node.js event-loop lag, memory pressure, garbage collection spikes, request timeouts, HTTP 408/429/500/502/503/504 responses, worker restarts, container OOM kills, autoscaling events, queue backlog growth, or health-check failures. Inspect retained request bodies or quarantined uploaded files for repeated entity names such as `lol`, deeply nested entity references, or unusually small XML inputs that produce very long processing times. Because exploitation is a denial-of-service technique rather than a persistence mechanism, durable host artifacts may be limited; focus on traffic/content evidence and operational telemetry around the time of service degradation. No named threat actor or ransomware campaign is indicated in the provided data.

• <!DOCTYPE
• <!ENTITY
• <!ENTITY lol
• &lol;
• &lol1;
• &lol2;
• &lol3;
• &lol4;
• &lol5;
• &lol6;
• &lol7;
• &lol8;
• &lol9;
• Billion Laughs
• processEntities: true
• processEntities=true
• XML parse timeout
• entity expansion
• Entity expansion
• JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed
• 503 Service Unavailable
• 504 Gateway Timeout

What your security team should do

• Prioritize remediation for internet-facing APIs, webhook receivers, file upload services, and integration workers that parse untrusted XML.
• Upgrade fast-xml-parser to 5.3.6 or later, or deploy builds containing commit ecb2ca118ad3d6c62f2cc90416b58da24db5d18b; update affected downstream components such as iccdev to a fixed revision.
• Disable entity processing with `processEntities: false` unless the business function explicitly requires XML entity expansion.
• Add preventive controls to reject XML containing `<!DOCTYPE` or `<!ENTITY` from untrusted sources where those constructs are unnecessary.
• Search SBOMs, lockfiles, container images, and vendor packages for transitive use of fast-xml-parser versions 4.1.3 through 5.3.5.
• Implement parser execution time limits, request size limits, queue backpressure, rate limiting, and worker isolation to reduce denial-of-service blast radius.
• Review historical logs for requests or files containing DOCTYPE and ENTITY declarations correlated with high CPU, timeouts, 5xx responses, process restarts, or queue backlog.
• Track dependency advisory updates even though this issue is not currently KEV-listed and has low EPSS, because entity-expansion denial-of-service payloads are easy to adapt.