CVE-2026-32141

What it actually does

The vulnerability is an unauthenticated denial-of-service flaw in the flatted JavaScript package before version 3.4.0. The parse() function performs an unbounded recursive revive() phase while resolving circular references. A specially crafted serialized payload containing deeply nested or self-referential reference indices can cause excessive recursion, trigger a JavaScript stack overflow, and terminate the Node.js process using the vulnerable parser. The impact is availability loss only; the issue does not directly provide code execution, data disclosure, or data modification.

Why it matters to the business

Applications, APIs, workers, and services that accept untrusted input and parse it with vulnerable versions of flatted can be crashed remotely with a low-complexity request. In production, this can cause service outages, failed transactions, degraded customer experience, queue backlogs, container restarts, alert noise, and potential cascading failures if dependent services repeatedly retry failed operations. Although the EPSS score is currently low and there is no known KEV listing, the flaw is easy to trigger where exposed parsing paths exist, so internet-facing or high-volume services should treat it as a practical availability risk.

How an attack unfolds

An attacker first identifies an application endpoint, message consumer, API, webhook, or other input path that deserializes attacker-controlled data using flatted.parse() from a vulnerable flatted version. The attacker then sends a crafted flatted JSON payload with intentionally deep nesting or circular/self-referential index structures. During parsing, flatted enters the revive() resolution phase and recursively follows the malicious structure without a safe recursion limit. The JavaScript runtime exhausts the call stack and raises a stack overflow, commonly terminating the request handler or crashing the Node.js process if the exception is uncaught. The attacker can repeat the payload to keep the service unstable, especially in environments where process managers or orchestrators automatically restart crashed instances.

How to fix it

Upgrade flatted to version 3.4.0 or later wherever it is used directly or transitively. Because the affected component is commonly introduced through npm dependency trees, update package manifests and lockfiles, then rebuild and redeploy affected applications, containers, serverless bundles, and worker images. If direct upgrade is temporarily blocked, mitigate by rejecting untrusted flatted payloads, enforcing strict request body size and nesting-depth limits, validating input before calling flatted.parse(), wrapping parse operations with defensive exception handling, and isolating parsing workloads so one malformed payload cannot terminate critical service processes. Also ensure process managers, Kubernetes, systemd, PM2, or similar supervisors have sane restart limits to avoid restart storms.

How to confirm the fix worked

Confirm that no deployed package tree contains flatted versions earlier than 3.4.0 by inspecting package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, SBOMs, container images, and production build artifacts. Run dependency scanners or commands such as npm ls flatted in each affected project. Validate that applications have been rebuilt after the dependency update and that runtime containers or bundles include the patched version. Where safe, perform a controlled negative test in a non-production environment using malformed deeply nested/circular flatted input and verify the service rejects or handles it without crashing. Confirm application logs no longer show stack overflow crashes in flatted parse paths after remediation.

Typical attack path

1. Find a remotely reachable feature that accepts serialized JSON-like data, webhook bodies, API input, job payloads, cache data, or messages that may be parsed with flatted.
2. Confirm or infer that the target uses a vulnerable flatted release before 3.4.0, often through dependency manifests, bundled JavaScript, error messages, or software composition data.
3. Create a malicious flatted payload containing deeply nested references or self-referential $ indices designed to force unbounded recursion during parse().
4. Send the payload to the vulnerable endpoint or message channel.
5. Trigger a RangeError or stack overflow during the recursive revive() phase, causing the Node.js process, worker, or request handler to crash.
6. Repeat requests or messages to maintain denial of service and exhaust restart capacity, autoscaling limits, or operational response processes.

How to detect it

To determine whether exploitation has already occurred, review application logs, Node.js runtime logs, process manager logs, container orchestration events, API gateway logs, load balancer logs, and message queue dead-letter or retry logs for crashes correlated with unusual inbound payloads. Look for RangeError stack overflow messages, stack traces containing flatted parse or revive functions, sudden Node.js process exits, repeated container restarts, PM2/systemd restart loops, HTTP 500/502/503 spikes, and repeated requests to the same parsing endpoint shortly before failures. For message-driven systems, inspect poison messages or dead-letter queues that repeatedly caused worker crashes. In containerized environments, correlate restart timestamps with ingress logs and request body metadata such as unusually large payloads, deeply nested JSON-like structures, or repeated malformed serialized arrays. There are no universally unique network IOCs for this vulnerability because payload structure and affected endpoints vary by application, so detection should focus on crash artifacts and suspicious malformed input preceding availability events.

• RangeError: Maximum call stack size exceeded
• Maximum call stack size exceeded
• at revive
• flatted
• flatted.parse
• parse()
• Node.js process exited
• process exited with code 1
• Uncaught RangeError
• CrashLoopBackOff
• Back-off restarting failed container
• PM2: App [
• exited with code [1] via signal [SIGINT]
• systemd: Main process exited
• npm ls flatted
• node_modules/flatted/package.json
• "flatted"

What your security team should do

• Inventory all applications, services, workers, and packages that include webreflection flatted, including transitive npm dependencies and bundled frontend/backend artifacts.
• Prioritize remediation for internet-facing APIs, webhook receivers, queue consumers, job processors, and any service that parses attacker-controlled or partner-controlled serialized payloads.
• Upgrade flatted to 3.4.0 or later and redeploy all affected runtime artifacts, including containers and serverless packages.
• Add request/message size limits, nesting-depth controls, schema validation, and safe exception handling around deserialization paths that process untrusted input.
• Search historical logs for Node.js stack overflow crashes, process restarts, and errors referencing flatted parse or revive functions.
• Create monitoring alerts for repeated process crashes, container restart loops, HTTP 5xx spikes, and RangeError stack-overflow messages.
• If exploitation is suspected, preserve application logs, process manager logs, container runtime events, inbound request samples, and queue messages before rotation or cleanup.