CVE-2026-58045

What it actually does

The vulnerability is a denial-of-service flaw in Node.js 22.x, 24.x, and 26.x affecting the synchronous node:zlib APIs. A maliciously crafted or spoofed TypedArray-like object can present an inconsistent byteLength value that reaches an internal assertion in the synchronous compression/decompression path. When the assertion is triggered, the Node.js runtime aborts the entire process rather than returning a normal JavaScript exception. Confidentiality and integrity are not directly impacted, but availability of the affected process is.

Why it matters to the business

Applications that process attacker-influenced data through synchronous zlib functions can be crashed on demand, causing service interruptions, failed jobs, dropped requests, or repeated process restarts. The risk is highest for internet-facing APIs, message processors, file-ingestion services, or worker systems that pass untrusted objects into synchronous compression or decompression routines. Although exploitation is currently not known to be active and EPSS is low, the issue affects supported Node.js major lines and can have operational impact where a single Node.js process handles critical workload.

How an attack unfolds

An attacker first needs a path that causes attacker-controlled JavaScript values or attacker-influenced objects to be passed to one of the synchronous node:zlib functions. The attacker supplies a crafted TypedArray or TypedArray-like object with a spoofed byteLength that is accepted far enough into the synchronous zlib implementation to violate an internal runtime assertion. Instead of safely rejecting the object, Node.js aborts the process. If the application supervisor automatically restarts the process, the attacker can repeat the request or job to create a sustained denial of service. Exploitation does not require stealing data or achieving code execution; the goal is reliable process termination.

How to fix it

Upgrade affected Node.js 22.x, 24.x, and 26.x installations to the vendor-provided patched security releases for the relevant major version as soon as they are available in the deployment channel. Rebuild containers, serverless runtimes, base images, developer workstations, and CI images that embed affected Node.js versions. As interim mitigation, avoid passing untrusted or user-controllable objects directly to synchronous node:zlib APIs; prefer asynchronous zlib APIs where feasible; normalize inputs into trusted Buffer instances before compression or decompression; reject unexpected TypedArray-like objects; and isolate risky processing in worker processes with rate limits and restart backoff. Do not rely solely on process managers to restart crashed services, because repeated exploitation can still cause persistent outage.

How to confirm the fix worked

Confirm the deployed runtime version is no longer an affected Node.js 22.x, 24.x, or 26.x build and matches the patched release line distributed by Node.js or the operating-system/package vendor. Inventory runtime versions using commands such as node --version in production images, CI images, developer images, and host packages. Review application code for use of synchronous node:zlib APIs and verify untrusted inputs are validated or normalized before use. In staging, run regression tests around compression/decompression endpoints and file/message ingestion workflows to ensure malformed inputs are rejected without process termination. Confirm application logs and process supervisors no longer show assertion failures, abort signals, or crash loops during negative testing.

Typical attack path

1. Identify a Node.js service or job running an affected 22.x, 24.x, or 26.x runtime.
2. Find an input path that invokes synchronous node:zlib functionality such as gzipSync, gunzipSync, deflateSync, inflateSync, brotliCompressSync, or brotliDecompressSync.
3. Submit data or an object that results in a spoofed TypedArray byteLength reaching the synchronous zlib API.
4. Trigger the reachable assertion and cause the Node.js process to abort.
5. Repeat the trigger to keep the service unavailable or force repeated restarts.

How to detect it

To assess whether the flaw may already have been exploited, review application logs, process-manager logs, container logs, system journals, crash reporters, and APM events for abrupt Node.js process termination correlated with requests, files, messages, or jobs that use compression or decompression. Look for assertion failures, abort signals, core dumps, exit code 134, SIGABRT, and repeated restart loops in Node.js services using node:zlib synchronous APIs. Correlate crashes with access logs or queue metadata immediately before termination, especially requests that submit compressed content, upload files, send encoded payloads, or trigger archive processing. If core dumps are retained, inspect stack traces for synchronous zlib functions. There are no known public threat actors or ransomware campaigns associated with this vulnerability at this time, so detection should focus on crash artifacts and repeated triggering behavior rather than actor-specific infrastructure.

• Assertion failed
• SIGABRT
• exit code 134
• core dumped
• node:zlib
• zlib.gzipSync
• zlib.gunzipSync
• zlib.deflateSync
• zlib.deflateRawSync
• zlib.inflateSync
• zlib.inflateRawSync
• zlib.unzipSync
• zlib.brotliCompressSync
• zlib.brotliDecompressSync
• process abort
• restart loop

What your security team should do

• Prioritize inventory of all Node.js 22.x, 24.x, and 26.x runtimes, including containers, base images, serverless functions, CI runners, and packaged applications.
• Patch or rebuild affected runtimes to vendor-fixed Node.js releases when available; otherwise apply interim input-normalization and isolation controls.
• Search code repositories for synchronous node:zlib API usage and treat paths handling external input as highest risk.
• Add monitoring for Node.js process aborts, assertion failures, SIGABRT exits, and restart loops in services that use compression or decompression.
• Apply rate limiting and request/job quarantine on endpoints or queues that trigger compression/decompression workflows.
• Because this issue is not currently in CISA KEV and has low EPSS, handle it as an availability-hardening priority, escalating for externally reachable or business-critical services.