GNU C Library EUVD-2026-75897

Exploitation requires two simultaneous preconditions: first, the nscd service must be actively running on the target host - nscd is not universally enabled by default across all modern Linux distributions and must be explicitly started or configured to start at boot; second, the system must use an untrusted DNS server capable of returning DNS records large enough to overflow the nscd thread stack, which the upstream description notes that bind9 could not achieve during testing, meaning the exploiting name server must be a custom, atypical, or attacker-controlled implementation. The attacker must directly control or have compromised this upstream DNS resolver. The CVSS AV:A vector confirms the attack path flows through the DNS resolution channel rather than direct network access to the host. Post-exploitation impact is further constrained by nscd running in an isolated context as a dedicated unprivileged user without a shell, limiting any successful compromise to the nscd process scope alone.

The CVSS 4.2 score with AV:A/AC:H accurately reflects the tightly constrained real-world risk: an attacker must either control the DNS server the target system queries or have already compromised it, a high-complexity precondition that eliminates opportunistic mass exploitation - even a mid-sized municipal IT team in inowroclaw would face minimal realistic exposure unless their systems route DNS through an untrusted or externally-controlled upstream resolver. No public exploit has been identified at time of analysis and this vulnerability is absent from CISA KEV, confirming no known active exploitation. Critically, the CVE description explicitly states that an nscd crash 'does not result in a denial of service,' only in performance degradation during name resolution - the primary impact is availability degradation (A:L) rather than a full outage. The theoretical cache corruption path requires precise stack-to-heap pointer manipulation to achieve integrity impact, which the description frames as a 'remote possibility,' not a demonstrated capability. nscd's isolation (dedicated non-privileged user, no shell access) significantly limits post-crash blast radius. Overall, this is a low-to-moderate priority issue best addressed through standard patch application rather than emergency remediation.

An attacker who controls or has previously compromised the DNS server used by a target Linux host running nscd crafts DNS responses containing records large enough to overflow the nscd thread stack; when the target system issues a name lookup that reaches the malicious server, the oversized response triggers the overflow, crashing the nscd service and causing DNS lookups to fall back to slower uncached resolution. In a more sophisticated and theoretical scenario, a skilled attacker manipulates the overflow so that the stack pointer reaches a controlled region of the heap, corrupting nscd's in-memory cache for other services and potentially poisoning DNS entries for other processes on the host until the crash terminates the daemon.