CVE-2026-69184: c-ares Library DNS Compression DoS Vulnerability

CVE-2026-69184 Overview

CVE-2026-69184 is a denial-of-service vulnerability in the c-ares asynchronous DNS resolver library affecting versions prior to 1.34.7. The flaw resides in ares_dns_name_parse(), which enforces backward DNS compression pointers but fails to bound the total number of pointer hops or the assembled name length. A malicious DNS server can return a response containing a long descending pointer chain paired with many resource records whose NAME or RDATA fields reference that chain. Repeated decompression work grows quadratically with message size, stalling the single-threaded c-ares event loop and blocking DNS resolution for the calling application. The issue is classified under [CWE-407] (Inefficient Algorithmic Complexity) and does not cause memory corruption or information disclosure.

Critical Impact
A single crafted DNS response can stall the c-ares event loop and deny DNS resolution for any application relying on the library.

Affected Products

c-ares library versions prior to 1.34.7
Applications embedding c-ares for asynchronous DNS resolution (for example, curl, Node.js, and various network utilities)
Downstream distributions packaging vulnerable c-ares versions

Discovery Timeline

2026-09-18 - CVE-2026-69184 published to NVD
2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-69184

Vulnerability Analysis

The c-ares library parses DNS wire-format messages that use RFC 1035 name compression. Compression allows a name to reference an earlier offset in the message via a two-byte pointer instead of repeating labels. The ares_dns_name_parse() function correctly enforces that pointers must move backward, which prevents infinite loops, but it does not cap the total number of indirections followed or the cumulative length of the assembled name.

An attacker controlling a DNS server can craft a response that chains many backward pointers into a long descending sequence. Additional resource records inside the same message reference nodes in that chain from their NAME or RDATA fields. Each reference forces the parser to walk the pointer chain again, producing quadratic work relative to the message size.

Because c-ares runs a single-threaded event loop, this parsing cost blocks all pending DNS operations on the caller. Applications that depend on c-ares for name resolution lose the ability to complete lookups until the parser returns.

Root Cause

The root cause is missing bounds enforcement in the DNS name decompression path. The parser lacked both a hard limit on the number of compression-pointer hops and a check against the RFC 1035 255-octet maximum for an assembled name. Without these limits, pointer-only names never grow the label buffer and therefore never trip any implicit length guard, allowing unbounded work per name.

Attack Vector

Exploitation requires an attacker to serve a crafted response to a target running a vulnerable c-ares version. This can occur when the target queries an attacker-controlled authoritative server, when an on-path attacker spoofs a response, or in scenarios such as DNS rebinding or malicious upstream resolvers. No authentication or user interaction is required.

// Patch: enforce name length and indirection limits in ares_dns_name.c
#include "ares_private.h"

/* RFC 1035 3.1 limits a name to 255 octets.  We track presentation length
 * (label octets plus one separator before each label after the first), which is
 * up to ~2 octets looser than the strict wire limit and so never rejects a
 * compliant name.  Shared by the read and write paths. */
#define ARES_MAX_NAME_PRESENTATION_LEN 255

/* A name of <= 255 octets holds at most 128 labels, so it can never legitimately
 * require more than that many compression-pointer jumps.  Bounding the number of
 * indirections stops a name built purely from pointers (which never adds label
 * bytes, so the length cap never fires) from being walked without limit. */
#define ARES_MAX_INDIRS 128

typedef struct {
  char  *name;
  size_t name_len;
// Source: https://github.com/c-ares/c-ares/commit/5c8341ba6ff3a8e4e4dfd616f8ed0418838b8b7b

The patch introduces two constants: ARES_MAX_NAME_PRESENTATION_LEN caps the assembled name at 255 octets, and ARES_MAX_INDIRS caps the number of pointer hops at 128. Together they bound worst-case parsing work.

Detection Methods for CVE-2026-69184

Indicators of Compromise

DNS responses containing unusually long chains of compression pointers relative to answer content
Application-level timeouts or hangs in processes that link against c-ares, correlated with recent DNS activity
Elevated CPU consumption in the thread running the c-ares event loop while awaiting a DNS response
Repeated queries to attacker-controlled or newly registered authoritative name servers

Detection Strategies

Inventory installed c-ares versions across servers, containers, and embedded applications; flag any version earlier than 1.34.7
Inspect DNS traffic for oversized response messages or responses containing many resource records whose names resolve through compression pointers
Monitor application logs from curl, Node.js, and other c-ares consumers for DNS timeout patterns tied to specific upstream resolvers

Monitoring Recommendations

Alert on DNS response sizes approaching the 512-byte UDP limit or unusually large TCP DNS responses from non-authoritative sources
Track process-level CPU spikes in DNS-dependent services and correlate with outbound resolver traffic
Log and review outbound DNS queries destined for domains outside the organization's normal resolution profile

How to Mitigate CVE-2026-69184

Immediate Actions Required

Upgrade c-ares to version 1.34.7 or later on all systems where the library is present
Rebuild or repackage applications that statically link c-ares against the patched release
Restrict outbound DNS resolution to trusted, validating recursive resolvers to reduce exposure to malicious authoritative servers

Patch Information

The fix is available in c-ares release v1.34.7. The corrective changes are tracked in pull request #1164 and backported in pull request #1210, with commits f1288bbc and 5c8341ba. Full technical detail is documented in GHSA-pjmc-gx33-gc76.

Workarounds

Route DNS queries through a validating recursive resolver that normalizes responses and drops malformed messages before they reach c-ares clients
Enforce egress filtering that blocks direct outbound DNS to arbitrary Internet destinations from application hosts
Apply resolver-side response size limits and rate limits to reduce the impact window while patches are staged

bash

# Verify installed c-ares version and confirm patched release
ldconfig -p | grep libcares
strings $(ldconfig -p | grep libcares.so | awk '{print $NF}' | head -1) | grep -E '^1\.[0-9]+\.[0-9]+' | head

# Debian/Ubuntu
apt-get update && apt-get install --only-upgrade libc-ares2

# RHEL/Fedora
dnf upgrade c-ares