CVE-2026-69186: c-ares Asynchronous Resolver DoS Vulnerability

CVE-2026-69186 Overview

CVE-2026-69186 is a resource exhaustion vulnerability in c-ares, an asynchronous DNS resolver library used by many networking applications. Versions prior to 1.34.7 allow a malicious DNS response to trigger disproportionate heap allocations. The parser trusts the attacker-controlled ANCOUNT, NSCOUNT, and ARCOUNT header fields before verifying that the response actually contains enough bytes for the claimed records. Repeated malformed responses create large allocation and release cycles that degrade or deny name resolution in the calling application. The flaw is classified as [CWE-400] Uncontrolled Resource Consumption and is fixed in c-ares 1.34.7.

Critical Impact
A remote attacker able to deliver DNS responses to a vulnerable resolver can exhaust memory and disrupt name resolution without requiring authentication or user interaction.

Affected Products

c-ares asynchronous resolver library versions prior to 1.34.7
Applications and runtimes that embed vulnerable c-ares builds for DNS resolution
Downstream distributions packaging c-ares below 1.34.7

Discovery Timeline

2026-09-18 - CVE-2026-69186 published to NVD
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-69186

Vulnerability Analysis

The defect resides in ares_dns_parse() within src/lib/record/ares_dns_parse.c. When c-ares receives a DNS response, process_answer() calls the parser before validating the transaction ID or the question section. The parser reads the ANCOUNT, NSCOUNT, and ARCOUNT fields from the DNS header and immediately passes those values to ares_dns_record_rr_prealloc(), which in turn calls ares_array_set_size() to reserve storage for the claimed number of resource records.

Because the byte length of the packet is not checked against those counts, an attacker can send a small UDP payload declaring the maximum number of records. c-ares then reserves large blocks of heap memory to hold records that will never be parsed. When the packet ultimately fails validation, the memory is released. Repeating this cycle at high frequency exhausts memory and CPU, disrupting resolution for the host process.

Root Cause

The root cause is trusting attacker-controlled header counts before performing sufficient length validation on the received datagram. The preallocation step runs prior to transaction ID matching, so unsolicited or spoofed responses can drive allocations even when they would later be discarded.

Attack Vector

Exploitation requires the ability to deliver DNS responses to a process using vulnerable c-ares. This is achievable by an on-path attacker, an operator of an authoritative or upstream resolver reached during recursion, or any host that can spoof responses toward the resolver's source port. No authentication or user interaction is required.

// Patch: remove premature preallocation based on untrusted counts
// Source: https://github.com/c-ares/c-ares/commit/e47c203f91cd8b749c8736bc18d75a31ffdec8f4

  (*dnsrec)->raw_rcode = rcode;

-  if (*ancount > 0) {
-    status =
-      ares_dns_record_rr_prealloc(*dnsrec, ARES_SECTION_ANSWER, *ancount);
-    if (status != ARES_SUCCESS) {
-      goto fail; /* LCOV_EXCL_LINE: OutOfMemory */
-    }
-  }
-
-  if (*nscount > 0) {
-    status =
-      ares_dns_record_rr_prealloc(*dnsrec, ARES_SECTION_AUTHORITY, *nscount);
-    if (status != ARES_SUCCESS) {
-      goto fail; /* LCOV_EXCL_LINE: OutOfMemory */
-    }
-  }
-
-  if (*arcount > 0) {
-    status =
-      ares_dns_record_rr_prealloc(*dnsrec, ARES_SECTION_ADDITIONAL, *arcount);
-    if (status != ARES_SUCCESS) {
-      goto fail; /* LCOV_EXCL_LINE: OutOfMemory */
-    }
-  }
-
   return ARES_SUCCESS;

 fail:

The patch removes the early bulk preallocation, deferring record storage until the parser has confirmed enough bytes exist for each record. See the GitHub commit e47c203 and the backport commit eaded4c.

Detection Methods for CVE-2026-69186

Indicators of Compromise

Bursts of small inbound UDP DNS responses that do not correspond to outstanding queries from the host.
Sustained memory growth or repeated allocate-free cycles in processes linked against libcares.
Application logs showing repeated DNS resolution failures or timeouts under otherwise normal conditions.

Detection Strategies

Inventory hosts and container images that ship c-ares below 1.34.7 using software composition analysis.
Inspect DNS response traffic for packets where declared ANCOUNT, NSCOUNT, or ARCOUNT values are inconsistent with datagram length.
Correlate resolver process memory pressure with spikes in inbound UDP/53 traffic from unexpected sources.

Monitoring Recommendations

Alert on resolver processes whose resident memory grows without a matching increase in query volume.
Monitor DNS response error rates and retry counts across services that embed c-ares.
Track upstream DNS servers for anomalous response patterns and enforce response source validation.

How to Mitigate CVE-2026-69186

Immediate Actions Required

Upgrade c-ares to version 1.34.7 or later across all affected systems and container images.
Rebuild and redeploy any applications that statically link c-ares against a vulnerable release.
Restrict which hosts can send DNS responses to sensitive resolvers using network segmentation and firewall policy.

Patch Information

The fix is delivered in c-ares release v1.34.7 via pull request #1134. Full technical background is in the GHSA-jv8r-gqr9-68wj advisory. Distribution maintainers have backported the patch; apply vendor updates as they become available.

Workarounds

Route DNS traffic through a trusted upstream resolver that validates response length and header fields before forwarding.
Enforce strict egress and ingress rules on UDP/53 so only approved resolvers can deliver responses to application hosts.
Prefer DNS over TLS or DNS over HTTPS where supported, which reduces exposure to spoofed UDP responses.

bash

# Verify installed c-ares version on Linux distributions
ldconfig -p | grep libcares
strings /usr/lib/x86_64-linux-gnu/libcares.so.2 | grep -Ei 'ares.*1\.'

# Debian/Ubuntu upgrade example (once distribution ships >= 1.34.7)
sudo apt update && sudo apt install --only-upgrade libc-ares2

# Container image rebuild pattern
# Rebuild base images so downstream services relink against libcares >= 1.34.7