CVE-2026-25128

What it actually does

In fast-xml-parser versions 5.0.9 through 5.3.3, numeric XML entity decoding does not safely handle entity values that resolve to code points outside the valid Unicode range. When untrusted XML contains values such as � or �, the parser can throw a RangeError during entity processing. If the consuming application does not catch that exception, the process or request handler can crash, producing a denial of service. The issue affects availability only; it does not directly provide code execution, data disclosure, or data modification.

Why it matters to the business

Any service, API, queue consumer, integration worker, or backend job that accepts XML from external or semi-trusted sources and parses it with an affected fast-xml-parser version can be crashed by a small malformed XML payload. The main business risk is service interruption, failed transactions, delayed processing, degraded customer-facing integrations, and operational noise from repeated restarts. The vulnerability has a high availability CVSS impact, but current exploitation signals are lower urgency because it is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported public exploit maturity in the provided data.

How an attack unfolds

An attacker first identifies an endpoint, upload workflow, webhook, message queue, or integration that accepts XML input and is backed by an application using fast-xml-parser 5.0.9 through 5.3.3. The attacker sends otherwise minimal XML containing an out-of-range numeric entity, for example a decimal or hexadecimal entity that exceeds valid Unicode code point limits. During parsing, fast-xml-parser attempts to process the entity and raises a RangeError. If the application lacks defensive exception handling around parsing, the error becomes uncaught and can terminate the process, crash a worker, fail a request pipeline, or trigger container/process restarts. Repeating the payload can sustain a denial-of-service condition without authentication if the XML-processing path is exposed anonymously.

How to fix it

Upgrade fast-xml-parser to version 5.3.4 or later wherever versions 5.0.9 through 5.3.3 are present. Rebuild and redeploy applications so the fixed dependency is actually loaded at runtime, including container images, serverless packages, bundled JavaScript artifacts, and lockfile-pinned deployments. Add application-level safeguards around XML parsing: reject or sanitize malformed numeric entities before parsing, enforce request size and rate limits, wrap parser calls in try/catch blocks, return controlled 4xx errors for invalid XML, and ensure worker supervisors restart safely without restart storms. If dependency data is being tracked through distribution package advisories, also verify any relevant fixed package records are installed, including linux-oracle for Ubuntu 24.04 LTS fixed in 6.8.0-1039.40, linux-nvidia-6.8 for Ubuntu 22.04 LTS fixed in 6.8.0-1042.45~22.04.1, and linux-oracle-6.8 for Ubuntu 22.04 LTS fixed in 6.8.0-1039.40~22.04.1; however, the described application flaw is remediated by updating fast-xml-parser itself.

How to confirm the fix worked

Confirm dependency inventory, package lockfiles, SBOMs, and runtime package metadata show fast-xml-parser version 5.3.4 or later and no nested dependency remains in the affected 5.0.9 through 5.3.3 range. In Node.js applications, validate with package manager tooling such as npm ls fast-xml-parser, yarn why fast-xml-parser, pnpm why fast-xml-parser, or equivalent SBOM scanning. Test the XML parsing path in a non-production environment with malformed numeric entities such as � and �; the application should reject the input gracefully and must not crash, restart, or emit an uncaught RangeError. Review deployment artifacts and running containers to ensure the rebuilt application contains the fixed dependency, not only an updated source repository.

Typical attack path

1. Discover an application endpoint, webhook, file import, API route, or message-processing path that accepts XML.
2. Send a crafted XML payload containing an out-of-range numeric entity such as � or �.
3. Trigger fast-xml-parser numeric entity processing in an affected version, 5.0.9 through 5.3.3.
4. Cause a RangeError during parsing.
5. Rely on missing exception handling to crash the application process, worker, or request handler.
6. Repeat requests or messages to maintain service disruption.

How to detect it

This vulnerability does not create a distinctive post-exploitation footprint because successful exploitation primarily causes denial of service rather than persistence or unauthorized access. To determine whether it was already attempted or exploited, review HTTP access logs, API gateway logs, WAF logs, load balancer logs, application logs, APM traces, message broker payload logs where available, process manager logs, container orchestration events, and crash dumps for malformed XML numeric entities followed by RangeError exceptions, 5xx responses, worker exits, or container restarts. Focus searches on XML-consuming routes and on timestamps where services experienced unexplained crashes or restart loops. Look for request bodies, uploaded files, webhook payloads, or queued messages containing unusually large decimal or hexadecimal XML character references. Correlate strings such as � or � with Node.js uncaught exception logs, RangeError messages, elevated error rates, and supervisor restarts. Since exploit maturity is listed as none and EPSS is low, absence of these artifacts should reduce concern, but exposed XML endpoints should still be checked because exploitation requires only a small crafted payload.

• �
• �
• RangeError: Invalid code point
• RangeError
• Invalid code point 9999999
• Invalid code point 16777215
• uncaughtException
• UnhandledPromiseRejection
• fast-xml-parser
• XMLValidator
• XMLParser
• crash loop
• CrashLoopBackOff

What your security team should do

• Prioritize internet-facing or unauthenticated XML ingestion paths, including APIs, webhooks, SSO/SAML-like XML handlers, file uploads, B2B integrations, and message consumers.
• Inventory all applications and transitive dependencies using fast-xml-parser and upgrade affected versions 5.0.9 through 5.3.3 to 5.3.4 or later.
• Add regression tests using out-of-range numeric XML entities to ensure malformed XML is handled as a controlled validation failure rather than a process crash.
• Deploy WAF, API gateway, or application-layer filtering for suspicious out-of-range numeric XML entities where XML endpoints cannot be patched immediately.
• Review application logs, process supervisor logs, container restart events, and APM traces for RangeError crashes correlated with XML requests or messages.
• Tune monitoring for repeated 5xx responses, worker exits, crash loops, or restart spikes on XML-processing services.
• Because the vulnerability is not KEV-listed and has low EPSS in the provided data, treat remediation as important for exposed XML services but prioritize it after actively exploited internet-facing vulnerabilities if patch capacity is constrained.