CVE-2026-34043

What it actually does

The flaw is a CPU-exhaustion denial-of-service condition in the `serialize-javascript` / Yahoo Serialize functionality prior to version 7.0.5. When the library is asked to serialize a specially crafted array-like object—an object inheriting from `Array.prototype` with an extremely large `length` value—the serializer iterates as though it is processing a huge array. This can drive a Node.js or JavaScript runtime process to 100% CPU and cause the request handler, worker, build process, server-side rendering process, API process, or other application component using the serializer to hang indefinitely. The impact is availability-only: the vulnerability does not provide code execution, data disclosure, or data modification by itself.

Why it matters to the business

Applications that serialize attacker-influenced JavaScript objects may become slow or unavailable if a crafted input reaches the vulnerable serialization path. This can interrupt APIs, web applications, server-side rendering, background workers, or build tooling that depends on the affected package. The CVSS score is moderate and EPSS is currently low, with no known KEV listing or mature public exploitation indicated, but internet-exposed services that deserialize, transform, or re-serialize user-controlled objects should still treat the issue as operationally relevant because a single request may be enough to tie up a worker process.

How an attack unfolds

An attacker first identifies an application endpoint or workflow where user-controlled data is converted into an object and later passed to the vulnerable serializer. The attacker submits input that results in an array-like object: it behaves like an array through prototype inheritance but contains an artificially large `length` property. When the application invokes the vulnerable serialization routine, the library attempts to process the object as if it contains an enormous number of array elements. The JavaScript process enters a long-running CPU-bound loop, pegging a core at or near 100% and preventing normal processing. Repeated requests or concurrency against multiple workers can amplify the effect into broader service degradation or outage.

How to fix it

Upgrade the affected `serialize-javascript` / Yahoo Serialize package to version 7.0.5 or later wherever it is used. If fixed versions are managed through package-lock, yarn.lock, pnpm-lock, vendored dependencies, or framework transitive dependencies, regenerate and redeploy lockfiles so the vulnerable version is actually removed from runtime artifacts. If immediate upgrade is not possible, reduce exposure by preventing untrusted input from reaching serialization routines, rejecting objects with suspiciously large `length` values, enforcing request size and schema validation, applying CPU and request timeouts, isolating serialization work in bounded worker pools, and using process supervisors to restart hung workers. These mitigations reduce blast radius but should not replace upgrading to the patched version.

How to confirm the fix worked

Confirm the installed dependency version is 7.0.5 or later in all application packages, build images, deployed containers, serverless bundles, and vendored dependency trees. Use package inventory commands such as `npm ls serialize-javascript`, `yarn why serialize-javascript`, or equivalent software composition analysis tooling to verify there are no vulnerable copies remaining. Validate lockfiles and deployment artifacts, not just source manifests. In a controlled non-production environment, test that crafted array-like objects with very large `length` values no longer cause serialization to hang or consume sustained CPU. Monitor post-deployment process CPU, request latency, worker restarts, and event-loop lag to confirm normal behavior under malformed input.

Typical attack path

1. Identify an application, API, rendering path, or job processor that uses the vulnerable serialization library before version 7.0.5.
2. Find an input path where attacker-controlled data can influence the object passed into serialization.
3. Craft data that becomes an array-like object inheriting from `Array.prototype` with a very large `length` property.
4. Submit the crafted payload to the exposed endpoint or processing workflow.
5. Trigger serialization of the crafted object, causing CPU exhaustion and a hung process.
6. Repeat requests or target multiple workers to degrade or deny service across the application tier.

How to detect it

Look for signs of attempted or successful denial of service rather than compromise artifacts. Relevant sources include web access logs, API gateway logs, WAF logs, application logs, Node.js process logs, APM traces, container metrics, host CPU telemetry, event-loop lag metrics, and process supervisor restart records. Investigate periods with sustained 100% CPU on Node.js or JavaScript worker processes, sharp increases in request latency, request timeouts, event-loop stalls, or worker restarts that correlate with inbound requests containing unusually large numeric `length` fields or malformed JSON/object payloads. If request body logging is available, search for repeated payloads containing very large `length` values or structures attempting to create array-like objects. There are no known named threat actors, KEV exploitation, or ransomware campaigns associated with this issue in the supplied intelligence.

• "length":999999999
• "length":4294967295
• "length":2147483647
• "length":1000000000
• RangeError: Invalid array length
• JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed
• event loop lag
• request timeout
• upstream timed out
• worker timeout
• CPU 100%
• serialize-javascript

What your security team should do

• Prioritize upgrading all uses of the affected serialization package to version 7.0.5 or later, especially in internet-facing services and server-side rendering paths.
• Run software composition analysis across repositories, containers, and deployed artifacts to identify direct and transitive uses of vulnerable versions.
• Add or tighten input schema validation to reject unexpected array-like objects, excessive numeric `length` values, and oversized request bodies before business logic invokes serialization.
• Apply operational safeguards such as request timeouts, reverse-proxy rate limits, worker CPU limits, event-loop lag monitoring, and automatic worker restarts for services that process untrusted input.
• Review logs and telemetry for unexplained CPU spikes, request timeouts, stalled Node.js workers, or repeated malformed payloads targeting endpoints that perform serialization.
• Because this is not currently listed in KEV and has low EPSS, handle as a scheduled but timely remediation item unless the affected code is exposed to unauthenticated users or protects a critical availability path, in which case escalate priority.