CVE-2026-58042

What it actually does

Node.js versions 22.x, 24.x, and 26.x contain a denial-of-service flaw in the dns.resolveAny() code path. When a DNS ANY lookup receives a response containing more than 256 A records, Node.js can abort the process instead of safely handling or rejecting the oversized result. Because the abort terminates the Node.js process, any service path that performs dns.resolveAny() against attacker-influenced domain names can be crashed remotely. Confidentiality and integrity are not directly affected, but availability can be severely impacted if the process is repeatedly restarted and retriggered.

Why it matters to the business

Applications that perform DNS ANY lookups on domains supplied or influenced by users, partners, webhooks, URLs, email addresses, or external integrations may be forced offline. The main operational risk is service interruption: API downtime, failed background jobs, disrupted integrations, increased restart loops, elevated infrastructure costs, and potential SLA violations. The CVSS score is moderate and EPSS is currently low, with no known KEV listing or mature public exploit reported, but internet-facing services that resolve untrusted domains should still treat this as a practical availability risk because exploitation does not require authentication once a vulnerable lookup path is reachable.

How an attack unfolds

An attacker first identifies an application feature that causes the server to resolve DNS records for a domain name they control or can influence. They configure authoritative DNS for that domain to return an ANY response containing more than 256 A records. When the vulnerable Node.js application calls dns.resolveAny() for the attacker-controlled domain, the malformed or oversized record set triggers an abort condition inside Node.js. The process exits unexpectedly, causing active requests or jobs to fail. If the service supervisor restarts the process, the attacker can repeat the request to create a persistent denial-of-service condition.

How to fix it

Upgrade Node.js 22.x, 24.x, and 26.x deployments to a vendor-fixed release as soon as fixed versions are published for the affected release lines. If immediate upgrade is not possible, reduce exposure by avoiding dns.resolveAny() for untrusted or user-controlled domains, replacing ANY lookups with narrower record-specific lookups such as A, AAAA, MX, TXT, or CNAME where possible. Add application-level validation and allowlisting for domains that may be resolved, enforce timeouts and request rate limits around DNS-triggering features, and isolate DNS resolution workers so a crash does not terminate the primary service process. Ensure process supervisors restart failed workers, but do not rely on restart alone as a mitigation because repeated triggering can sustain the outage.

How to confirm the fix worked

Confirm the Node.js runtime version used by production services, containers, CI images, serverless runtimes, and developer base images. Verify that no affected 22.x, 24.x, or 26.x runtime remains once vendor-fixed builds are available. Search application code and dependencies for dns.resolveAny() usage and determine whether its input can be influenced by untrusted parties. In a controlled non-production environment, test the patched runtime by resolving a lab-controlled domain that returns more than 256 A records to an ANY query and confirm the process handles the response without aborting. Validate operational controls by confirming rate limits, domain validation, crash isolation, and alerting for unexpected Node.js process exits.

Typical attack path

1. Identify a Node.js application or API endpoint that accepts a domain, URL, email address, webhook destination, or integration hostname.
2. Determine whether the application performs DNS ANY lookups using dns.resolveAny() or equivalent application logic.
3. Register or control a domain and configure its authoritative DNS server to return more than 256 A records in response to an ANY query.
4. Send input to the application that causes it to resolve the attacker-controlled domain.
5. Trigger the vulnerable dns.resolveAny() call and cause the Node.js process to abort.
6. Repeat the request after service restart to maintain denial of service or exhaust operational recovery mechanisms.

How to detect it

To determine whether this was already exploited, review application, process supervisor, container, and host logs for unexpected Node.js process exits or aborts correlated with inbound requests that supplied domains, URLs, webhook destinations, email addresses, or integration hostnames. Examine DNS resolver logs, authoritative DNS logs, passive DNS telemetry, and network captures for ANY queries followed by responses containing unusually large numbers of A records, especially more than 256 A records, and correlate those events with Node.js restarts or failed health checks. Review web/API access logs for repeated requests to features that perform DNS lookups using attacker-controlled domains. Look for crash loops in systemd, PM2, Kubernetes, Docker, serverless runtime, or process manager logs around the same timestamps. Because the vulnerability causes process termination rather than code execution, evidence is likely to appear as availability events, abort messages, restart-loop telemetry, and abnormal DNS query/response patterns rather than persistent malware artifacts.

• dns.resolveAny
• DNS ANY query
• ANY query
• more than 256 A records
• node process aborted
• Node.js process aborted
• node: abort
• SIGABRT
• core dumped
• CrashLoopBackOff
• Back-off restarting failed container
• PM2 | App [
• exited with code [134]
• systemd-coredump
• Process exited with signal SIGABRT

What your security team should do

• Inventory all Node.js 22.x, 24.x, and 26.x services, including containers, serverless functions, job workers, and embedded application runtimes.
• Prioritize externally reachable applications that accept URLs, domains, webhooks, email addresses, federation identifiers, or other inputs that may trigger DNS resolution.
• Search first-party code and critical dependencies for dns.resolveAny() and review whether calls can use attacker-influenced input.
• Upgrade to vendor-fixed Node.js releases for all affected major versions as soon as available; track official Node.js security advisories for the exact patched versions.
• As an interim mitigation, disable or replace DNS ANY lookups for untrusted domains and use record-specific DNS queries instead.
• Add rate limiting and abuse detection to endpoints that trigger DNS lookups.
• Monitor for sudden Node.js process aborts, restart loops, and repeated DNS ANY lookups to unusual or newly registered domains.
• Ensure service managers, container orchestrators, and alerting systems surface crash-loop behavior quickly so repeated exploitation is visible.