CVE-2026-89092

What it actually does

A stack overflow in the GNU C Library Name Service Cache Daemon (nscd, glibc 2.3.4 onward) can be triggered when an nscd worker processes an oversized DNS response. The overflow is confined to an nscd thread stack and typically aborts that thread. In a narrow case, if the stack pointer lands in heap memory, other nscd caches may be overwritten with corrupt data before the crash. Confidentiality is unaffected. Integrity impact is limited to cached name-service data; availability impact is limited to loss of the cache and slower fallback lookups—not a full denial of service.

Why it matters to the business

Hosts that run nscd against untrusted DNS may see slower name resolution or briefly wrong cached answers if nscd crashes or its cache is damaged. nscd is normally an isolated, unprivileged service without a shell, so a crash does not readily become host compromise. Urgency is low: CVSS 4.2 (adjacent, high complexity, low integrity and availability), EPSS ~0.00265 and flat over 30 days, not in CISA KEV, not associated with ransomware, exploit maturity none, and 22 days since publication with no known in-the-wild use. Systems without nscd, or that only query trusted resolvers, are largely unaffected.

How an attack unfolds

An attacker who can answer DNS queries for a host running nscd—by controlling or impersonating a resolver on the adjacent network, or otherwise causing the host to use an untrusted nameserver—returns a DNS response large enough to overflow an nscd thread stack. nscd must be enabled and must use that untrusted server. Complexity is high: the answer must exceed the thread stack, and common nameservers such as BIND 9 have historically been unable to emit records of that size. The usual result is an nscd crash and degraded lookup performance, not code execution. Cache corruption via stack-to-heap overwrite is described as a remote possibility only. No named threat actors or campaigns are tied to this issue.

How to fix it

Install the glibc/nscd update from your Linux distribution when it is published; no specific upstream fixed version was listed with this advisory. Until then, disable nscd if it is not required; point remaining nscd instances only at trusted internal recursive resolvers and never at untrusted or Internet-facing DNS; keep nscd running as its dedicated unprivileged user without a shell (typical packaging default); and apply network or resolver controls that reject unusually large DNS payloads on adjacent segments. Do not expose nscd to untrusted name servers.

How to confirm the fix worked

Find hosts with glibc 2.3.4 or later and nscd enabled (nscd service status, nscd -g, or /var/run/nscd). Confirm which resolvers nscd uses via nscd.conf and system resolver configuration. After patching, verify the installed glibc/nscd package matches the vendor advisory, restart nscd, and confirm stable lookups under normal load. Hosts without nscd, or with nscd disabled, are not exposed on this path.

Typical attack path

1. Obtain a position from which the target will accept DNS answers (adjacent-network resolver, on-path influence, or an untrusted nameserver the host already uses)
2. Confirm nscd is enabled and caching DNS on the target
3. Cause the target to perform a name lookup that nscd will resolve via DNS
4. Return an abnormally large DNS response that overflows an nscd thread stack
5. Induce an nscd thread crash and, rarely, overwrite other nscd caches if the stack pointer reaches the heap
6. Rely on slower or incorrect name resolution rather than a full outage or remote code execution

How to detect it

There is no known in-the-wild exploitation and no associated threat actors, so hunt for nscd crash artifacts rather than attacker tooling. Review syslog and journald for nscd.service failures, segmentation faults, core dumps, and repeated restarts; correlate with DNS (UDP/TCP 53) from untrusted resolvers showing unusually large responses. Wrong or truncated cached name results coinciding with nscd restarts may indicate cache integrity impact. Hosts that do not run nscd could not have been exploited via this flaw.

• nscd: segmentation fault
• nscd.service: Main process exited
• nscd.service: Failed with result 'core-dump'
• kernel: nscd[*]: segfault
• core.*nscd
• /var/run/nscd/
• /var/db/nscd/
• /var/cache/nscd/

What your security team should do

• Inventory nscd-enabled hosts first; this is low severity, high complexity, adjacent-network, not KEV, and has no known exploit
• Disable nscd where it is not needed to remove the attack surface
• Ensure remaining nscd instances query only trusted internal resolvers
• Apply distribution glibc/nscd updates in the normal patch cycle once packages exist
• Do not treat this as mass exploitation or ransomware; EPSS is ~0.00265 and stable with exploit maturity none