CVE-2026-27942

What it actually does

In fast-xml-parser versions prior to 5.3.8, using the XML builder with the option `preserveOrder:true` can trigger uncontrolled recursive processing and exhaust the JavaScript call stack. When attacker-controlled or otherwise malformed input is passed to the builder in this mode, the Node.js process can throw a stack overflow error and crash. The primary technical impact is denial of service through application unavailability; the issue does not indicate confidentiality or integrity compromise by itself.

Why it matters to the business

Applications, APIs, workers, or integration services that build XML using vulnerable fast-xml-parser versions may be remotely crashed if they process untrusted data, causing failed transactions, interrupted data exchange, degraded service availability, and operational incidents. Although EPSS is currently low and there is no known KEV listing or mature public exploitation signal, the vulnerability is easy to trigger where exposed parsing/building paths exist and should be remediated during normal dependency patch cycles, with higher urgency for internet-facing services or message-processing pipelines.

How an attack unfolds

An attacker first identifies an application endpoint, queue consumer, webhook, file import function, or API workflow that accepts data later converted into XML using fast-xml-parser's XML builder. If the application invokes the builder with `preserveOrder:true` and does not sufficiently constrain input structure or size, the attacker submits specially structured nested or malformed data that causes excessive recursion during XML construction. The vulnerable library exhausts the JavaScript stack, commonly resulting in a `RangeError: Maximum call stack size exceeded` and termination or restart of the Node.js process. Repeated submissions can keep the affected service unstable or unavailable until the dependency is upgraded, the vulnerable option is disabled, or input validation/rate limiting blocks the payloads.

How to fix it

Upgrade fast-xml-parser to version 5.3.8 or later. For source-based consumers tracking the Git repository, ensure the dependency includes fix commit `c692040f6b5f5045d38b66b1da04e4d3abc97052` or a later trusted revision. Regenerate and redeploy lockfiles and container images so runtime artifacts no longer include vulnerable versions. If immediate upgrade is not possible, avoid using XML builder with `preserveOrder:true`; configure `preserveOrder:false` where functionally acceptable. Add input validation before XML building, including maximum depth, maximum object size, maximum array length, maximum request body size, and rejection of unexpected structures. Apply rate limiting and worker/process supervision to reduce denial-of-service impact, but treat these as compensating controls rather than a fix.

How to confirm the fix worked

Confirm all package manifests and lockfiles resolve fast-xml-parser to 5.3.8 or later, or to a Git revision at or after `c692040f6b5f5045d38b66b1da04e4d3abc97052`. Use software composition analysis, `npm ls fast-xml-parser`, `yarn why fast-xml-parser`, or equivalent dependency inventory tooling to find both direct and transitive usage. Review application code for `new XMLBuilder({ preserveOrder: true })`, `preserveOrder:true`, or dynamically supplied builder options. Validate deployed artifacts, not only source repositories, by inspecting production container images or build outputs for `node_modules/fast-xml-parser/package.json`. In a controlled non-production environment, exercise XML-building paths with deeply nested test input and confirm the service rejects the input or handles it without stack overflow or process termination.

Typical attack path

1. Identify an application feature that accepts user-controlled data and returns, stores, or forwards XML.
2. Confirm or infer that the application uses fast-xml-parser XMLBuilder with `preserveOrder:true`.
3. Send deeply nested, cyclic-like, or otherwise problematic structured input that is passed to the XML builder.
4. Trigger stack exhaustion during XML generation, causing the Node.js process or request handler to crash.
5. Repeat requests or messages to create sustained denial of service.

How to detect it

To determine whether exploitation has already occurred, review application logs, Node.js process logs, container logs, API gateway logs, load balancer logs, queue consumer logs, and process supervisor events for stack overflow crashes near requests or messages that trigger XML generation. Look for repeated `RangeError: Maximum call stack size exceeded` errors, stack traces referencing `fast-xml-parser`, `XMLBuilder`, or `node_modules/fast-xml-parser`, and service restarts immediately following requests with unusually large or deeply nested JSON/XML-like payloads. Correlate crashes with source IPs, API routes, user agents, webhook senders, uploaded files, or queue message identifiers to identify repeated triggering patterns. Because this vulnerability causes availability impact rather than creating a persistent artifact, absence of file-system changes does not rule out attempted exploitation; the strongest evidence is correlated crash telemetry and repeated malformed input reaching XML-building code paths.

• RangeError: Maximum call stack size exceeded
• Maximum call stack size exceeded
• node_modules/fast-xml-parser
• fast-xml-parser
• XMLBuilder
• preserveOrder:true
• preserveOrder: true
• new XMLBuilder({ preserveOrder: true })
• new XMLBuilder({preserveOrder:true})
• Process exited with code 1
• JavaScript heap out of memory
• uncaughtException
• UnhandledPromiseRejection
• Error: write EPIPE

What your security team should do

• Prioritize upgrade of fast-xml-parser to 5.3.8 or later for internet-facing APIs, webhook receivers, file import services, and asynchronous workers that process untrusted data.
• Search code repositories and deployed artifacts for `preserveOrder:true` and review whether untrusted input can reach XMLBuilder.
• Add depth, size, and schema validation controls before XML generation where the XML builder receives external input.
• Monitor application logs and process supervisors for stack overflow crashes involving fast-xml-parser or XMLBuilder.
• Ensure dependency scanning covers transitive JavaScript dependencies and fails builds that include vulnerable fast-xml-parser versions.
• Use rate limiting, request body size limits, queue throttling, and automatic process restart as temporary safeguards until the dependency is fully patched.