Updates are now available for the 26.x, 24.x, 22.x Node.js release lines for the following issues.

This security release includes the following dependency updates to address public vulnerabilities:

c-ares on 26.x, 24.x, 22.x

ca-cert (eMudhra Intermediate CA Compromise) on 26.x, 24.x, 22.x

OpenSSL on 24.x, 22.x

SQLite on 22.x

Undici on 26.x, 24.x, 22.x

c-ares is an asynchronous resolver library. Prior to 1.34.7, aresdnsnameparse() enforces backward DNS compression pointers but does not bound the total pointer hops or assembled name length. A malicious DNS server can send a response containing a long descending pointer chain and many resource records whose NAME or RDATA fields refer to the chain, causing repeated decompression work that grows quadratically with message size. A single crafted response can stall the single-threaded c-ares event loop and deny DNS resolution, without causing memory corruption or information disclosure. This issue is fixed in version 1.34.7.

A use-after-free / double-free vulnerability was found in c-ares' query-completion handling. The same flaw — a query's callback being invoked while the query is still linked in the channel's internal lookup structures — is present at multiple points in the resend/finish path (timeout handling, response handling, and query dispatch). If the query, or for aresgetaddrinfo() the owning hostquery, is freed as a side effect of that callback, it is then accessed and/or freed a second time.

It is reachable in two ways:

1. Application-triggered: a callback that re-enters c-ares, for example by calling arescancel(). The callback frees the query and it is freed again after the callback returns.

2. Remotely, with no application cooperation: via aresgetaddrinfo() over TCP. A malicious or on-path DNS server that returns a FORMERR without an OPT record (forcing an EDNS-downgrade retry), then a second response with the same query id, then resets the connection, causes aresgetaddrinfo()'s internal completion handler to re-enter (issuing a follow-on lookup whose send fails on the reset connection and completes immediately) and access a hostquery that has already been freed. An attacker can force a client onto TCP by setting the truncation (TC) bit in a UDP response.

This was reproduced deterministically under AddressSanitizer (heap-use-after-free in the aresgetaddrinfo() completion handler) against v1.34.6 and the development branch, using only the public API and the standard system allocator.

The same pattern was previously addressed at one call site under CVE-2025-31498; CVE-2026-33630 covers the remaining occurrences.

The consequence is memory corruption leading to a crash (denial of service); a use-after-free may have further impact depending on the allocator and build. Reliable code execution has not been demonstrated.

Fixed in c-ares 1.34.7.

c-ares has a Use After Free vulnerability when connection is cleaned up after error

c-ares is an asynchronous resolver library. From 1.32.3 through 1.34.4, there is a use-after-free in readanswers() when processanswer() may re-enqueue a query either due to a DNS Cookie Failure or when the upstream server does not properly support EDNS, or possibly on TCP queries if the remote closed the connection immediately after a response. If there was an issue trying to put that new transaction on the wire, it would close the connection handle, but readanswers() was still expecting the connection handle to be available to possibly dequeue other responses. In theory a remote attacker might be able to trigger this by flooding the target with ICMP UNREACHABLE packets if they also control the upstream nameserver and can return a result with one of those conditions, this has been untested. Otherwise only a local attacker might be able to change system behavior to make send()/write() return a failure condition. This vulnerability is fixed in 1.34.5.

c-ares is an asynchronous resolver library. From 1.32.3 through 1.34.4, there is a use-after-free in readanswers() when processanswer() may re-enqueue a query either due to a DNS Cookie Failure or when the upstream server does not properly support EDNS, or possibly on TCP queries if the remote closed the connection immediately after a response. If there was an issue trying to put that new transaction on the wire, it would close the connection handle, but readanswers() was still expecting the connection handle to be available to possibly dequeue other responses. In theory a remote attacker might be able to trigger this by flooding the target with ICMP UNREACHABLE packets if they also control the upstream nameserver and can return a result with one of those conditions, this has been untested. Otherwise only a local attacker might be able to change system behavior to make send()/write() return a failure condition. This vulnerability is fixed in 1.34.5.

CVE-2025-31498

Impact

Patches

Versions 1.32.3 - 1.34.4 are affected. Patch in 1.34.5.

Workarounds

None

References https://github.com/c-ares/c-ares/releases/tag/v1.34.5

Credit

Reported by Erik Lax

CVE-2024-25629

Impact Patches

Fixed in c-ares 1.27.0

Workarounds

No workarounds exist.

Credit

Vojtěch Vobr

c-ares is a C library for asynchronous DNS requests. aresreadline() is used to parse local configuration files such as /etc/resolv.conf, /etc/nsswitch.conf, the HOSTALIASES file, and if using a c-ares version prior to 1.27.0, the /etc/hosts file. If any of these configuration files has an embedded NULL character as the first character in a new line, it can lead to attempting to read memory prior to the start of the given buffer which may result in a crash. This issue is fixed in c-ares 1.27.0. No known workarounds exist.

Buffer overflow vulnerability in c-ares before 1161 thru 1170 via function aresparsesoareply in aresparsesoareply.c.

CVE-2023-32067. 0-byte UDP payload causes Denial of Service (https://github.com/c-ares/c-ares/security/advisories/GHSA-9g78-jv2r-p7vc)

c-ares is an asynchronous resolver library. When /dev/urandom or RtlGenRandom() are unavailable, c-ares uses rand() to generate random numbers used for DNS query ids. This is not a CSPRNG, and it is also not seeded by srand() so will generate predictable output. Input from the random number generator is fed into a non-compilant RC4 implementation and may not be as strong as the original RC4 implementation. No attempt is made to look for modern OS-provided CSPRNGs like arc4random() that is widely available. This issue has been fixed in version 1.19.1.

Description of issue(s): When /dev/urandom or RtlGenRandom() are unavailable, c-ares uses rand() to generate random numbers used for DNS query ids. This is not a CSPRNG, and it is also not seeded by srand() so will generate predictable output. Input from the random number generator is fed into a non-compilant RC4 implementation and may not be as strong as the original RC4 implementation. No attempt is made to look for modern OS-provided CSPRNGs like arc4random() that is widely available.

CVE-2023-31147 Insufficient randomness in generation of DNS query IDs (https://github.com/c-ares/c-ares/security/advisories/GHSA-8r8p-23f3-64c2)

aresinetnetpton() is vulnerable to a buffer underflow for certain ipv6 addresses, in particular "0::00:00:00/2" was found to cause an issue. C-ares only uses this function internally for configuration purposes which would require an administrator to configure such an address via aressetsortlist().

CVE-2023-31130. Moderate. Buffer Underwrite in aresinetnetpton() (https://github.com/c-ares/c-ares/security/advisories/GHSA-x6mf-cxr9-8q6v)

aresinetnetpton() is vulnerable to a buffer underflow for certain ipv6 addresses, in particular "0::00:00:00/2" was found to cause an issue. C-ares only uses this function internally for configuration purposes which would require an administrator to configure such an address via aressetsortlist().

CVE-2023-31130. Moderate. Buffer Underwrite in aresinetnetpton() (https://github.com/c-ares/c-ares/security/advisories/GHSA-x6mf-cxr9-8q6v)

c-ares is an asynchronous resolver library. When cross-compiling c-ares and using the autotools build system, CARESRANDOMFILE will not be set, as seen when cross compiling aarch64 android. This will downgrade to using rand() as a fallback which could allow an attacker to take advantage of the lack of entropy by not using a CSPRNG. This issue was patched in version 1.19.1.

When cross-compiling c-ares and using the autotools build system, CARESRANDOMFILE will not be set, as seen when cross compiling aarch64 android. This will downgrade to using rand() as a fallback which could allow an attacker to take advantage of the lack of entropy by not using a CSPRNG.

CVE-2023-31124. Low. AutoTools does not set CARESRANDOMFILE during cross compilation (https://github.com/c-ares/c-ares/security/advisories/GHSA-54xr-f67r-4pc4)

A possible use-after-free and double-free in c-ares lib version 1.16.0 if aresdestroy() is called prior to aresgetaddrinfo() completing. This flaw possibly allows an attacker to crash the service that uses c-ares lib. The highest threat from this vulnerability is to this service availability.

The c-ares function aresparsenaptrreply(), which is used for parsing NAPTR responses, could be triggered to read memory outside of the given input buffer if the passed in DNS response packet was crafted in a particular way.

A security vulnerability has been discovered in the c-ares library that is bundled with all versions of Node.js. Due to the difficulty of triggering and making use of this vulnerability we currently consider this a low-severity security flaw for Node.js users.

More information at https://c-ares.haxx.se/adv20160929.html