CVE-2026-4437

What it actually does

GNU glibc versions 2.34 through 2.43 can incorrectly process crafted DNS responses during reverse-name lookups performed through gethostbyaddr or gethostbyaddr_r when nsswitch.conf is configured to use the DNS backend. A malicious or compromised configured DNS server, or an attacker able to spoof or intercept DNS responses, can cause glibc to treat data from a non-answer section of a DNS response as if it were a valid answer. The assessed impact is primarily availability: affected applications that rely on reverse DNS lookups may behave incorrectly, fail lookups unexpectedly, or become unstable depending on how they handle the malformed resolver result.

Why it matters to the business

Systems and applications that depend on reverse DNS lookups for logging, access control, mail handling, authentication workflows, monitoring, or network service operations may experience disruption if they process malicious DNS responses. Because glibc is widely used across Linux distributions and many server workloads, exposure can be broad even when the vulnerable code path is only reached by applications that call gethostbyaddr or gethostbyaddr_r. The CVSS score indicates a high-severity availability risk, but current public exploitation maturity is listed as none, EPSS is low, and it is not currently listed in CISA KEV, so prioritization should focus first on internet-facing or DNS-dependent services using affected glibc versions.

How an attack unfolds

An attacker first needs a way to influence DNS responses received by a vulnerable system, such as controlling the configured recursive DNS server, compromising an upstream DNS component, performing DNS spoofing on an adjacent network, or otherwise injecting crafted DNS replies. The attacker then waits for or induces an application on the target system to perform a reverse DNS lookup using gethostbyaddr or gethostbyaddr_r through glibc’s NSS DNS backend. The attacker returns a deliberately malformed DNS response in which relevant data appears outside the answer section. Due to improper validation, glibc may accept that non-answer data as though it were a legitimate answer. The affected application may then make incorrect decisions based on the bogus resolution result or encounter resolver-related failure conditions that degrade service availability.

How to fix it

Upgrade GNU glibc to a vendor-provided fixed release as soon as packages are available for the affected Linux distribution. The currently supplied fixed-version list is empty, so use distribution security advisories and package repositories as the source of truth for the patched glibc build. After updating glibc, restart long-running services and containers so they load the corrected library; where feasible, reboot hosts to ensure all processes use the patched version. As temporary mitigations, restrict systems to trusted DNS resolvers, prevent untrusted network paths from spoofing DNS responses, monitor and harden recursive DNS infrastructure, and review applications that rely on reverse DNS for critical access-control or availability-sensitive decisions. If reverse DNS lookups are not required, consider removing or reducing DNS use in the relevant nsswitch.conf hosts configuration only after validating operational impact.

How to confirm the fix worked

Confirm the installed glibc package version is outside the affected 2.34 through 2.43 range or matches a vendor security-fixed build. On Linux systems, validate with distribution package tooling such as rpm, dpkg, apt, dnf, yum, zypper, or the distribution’s vulnerability scanner rather than relying only on the upstream version string, because vendors may backport patches. Review /etc/nsswitch.conf and confirm whether the hosts database includes dns. Identify applications that call reverse lookup APIs directly or indirectly, especially services that log or validate client hostnames. After patching, restart affected services and confirm their mapped libc dependency has been refreshed. Where test infrastructure permits, validate that crafted DNS responses with answer data outside the DNS answer section are rejected or do not disrupt application behavior.

Typical attack path

1. Identify Linux systems or services likely running GNU glibc 2.34 through 2.43 and performing reverse DNS lookups.
2. Gain the ability to control, spoof, or tamper with DNS responses sent to the target system’s configured resolver path.
3. Trigger or wait for a reverse lookup against an IPv4 in-addr.arpa or IPv6 ip6.arpa name.
4. Return a crafted DNS response where data appears in a non-answer section rather than as a valid answer.
5. Rely on vulnerable glibc resolver handling to treat the non-answer section as a valid answer.
6. Cause the dependent application to mis-handle the resolver result, potentially leading to service disruption or denial of service.

How to detect it

To assess possible prior exploitation, correlate DNS telemetry with application instability around reverse DNS lookups. Review recursive DNS server logs, packet captures, EDR network telemetry, and application logs for PTR lookups to in-addr.arpa or ip6.arpa followed by malformed responses where the DNS answer count is zero or unexpected while authority or additional sections contain records that resemble valid lookup data. Look for spikes in reverse lookup failures, resolver errors, service restarts, crashes, or denial-of-service symptoms shortly after suspicious DNS responses. Pay particular attention to systems configured with hosts: ... dns in /etc/nsswitch.conf and applications known to perform gethostbyaddr or gethostbyaddr_r calls. Because there are no known public exploit artifacts or fixed attacker infrastructure indicators from the supplied data, detection should focus on behavioral evidence: malformed DNS responses, suspicious control of resolver infrastructure, resolver-path tampering, and time-correlated application failures.

• /etc/nsswitch.conf
• hosts:
• dns
• gethostbyaddr
• gethostbyaddr_r
• in-addr.arpa
• ip6.arpa
• ANCOUNT=0
• Answer RRs: 0
• answer count: 0
• authority section
• additional section
• malformed DNS response
• resolver failure
• Temporary failure in name resolution
• Segmentation fault

What your security team should do

• Inventory Linux systems and container images using GNU glibc 2.34 through 2.43, prioritizing externally reachable services and systems that perform reverse DNS lookups.
• Track distribution security advisories and apply the first available vendor-fixed glibc packages; restart services or reboot systems after patching.
• Review /etc/nsswitch.conf for hosts entries that include dns and determine where reverse DNS lookups are operationally required.
• Harden DNS resolution paths by using trusted resolvers, restricting DNS traffic to approved servers, and blocking spoofed UDP/TCP 53 traffic from untrusted networks.
• Monitor DNS infrastructure and application logs for malformed reverse-lookup responses and resolver-related service failures.
• Avoid using reverse DNS results as a sole security-control input for authentication, authorization, or allow/deny decisions.
• Include base operating system and container image rebuilds in remediation plans because glibc is commonly inherited through images and downstream packages.