CVE-2026-0915: 
NixOS vulnerability analysis and mitigation

CVE-2026-0915 is an information disclosure vulnerability in the GNU C Library (glibc) affecting versions 2.0 through 2.42, where calling getnetbyaddr or getnetbyaddr_r with a DNS backend configured in nsswitch.conf and querying for a zero-valued network can leak stack contents to the configured DNS resolver. The flaw was publicly disclosed on January 15–16, 2026, and is tracked under glibc security advisory GLIBC-SA-2026-0002. It was reported by Igor Morgenstern and Aisle Research (oss-security). The vulnerability carries a CVSS v3.1 base score of 7.5 (High) with a network-accessible, unauthenticated attack vector (Red Hat CVE, Feedly).

The root cause is classified as CWE-908 (Use of Uninitialized Resource). Specifically, a defect in the _nss_dns_getnetbyaddr_r function causes it to pass uninitialized stack contents directly to the DNS resolver as part of a network DNS query when the queried network value is zero (net == 0x0) (oss-security). The vulnerable commit dates back to glibc 1.92-1 (commit 5f0e6fc702296840d2daa39f83f6cb1e40073d58), meaning the bug has existed since approximately 1996. Exploitation requires that nsswitch.conf specifies the DNS backend for the networks database and that an attacker can either control the net argument passed to these functions or observe DNS traffic between the application and its resolver. The leaked stack data is spatially limited to adjacent stack contents, but could potentially expose pointer values useful for ASLR bypass (oss-security).

Successful exploitation results in a loss of confidentiality: stack memory contents from the querying process are transmitted to the configured DNS resolver in plaintext as part of a DNS query. This could expose sensitive data such as authentication tokens, cryptographic keys, or memory pointers stored on the stack (Feedly). While there is no direct integrity or availability impact, leaked pointer values could be leveraged to accelerate ASLR bypass in a chained attack scenario. The vulnerability affects any Linux system running glibc 2.0–2.42 with DNS-backed network lookups configured, including downstream products such as IBM Netezza Appliance, IBM API Connect, IBM CICS Transaction Gateway, and Microsoft Azure Linux distributions (Red Hat Bugzilla, Feedly).

A proof-of-concept exploit has been published on GitHub (PoC GitHub), though there is no confirmed evidence of active in-the-wild exploitation as of the time of this report (Feedly). The EPSS score is approximately 0.018% (0.000180), indicating a low probability of exploitation in the near term. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No specific threat actor attribution has been reported. Exploitation requires network-adjacent access to observe DNS traffic between the vulnerable application and its resolver, raising the practical attack complexity beyond what the CVSS network vector alone suggests (oss-security).

1. Reconnaissance: Identify target systems running glibc 2.0–2.42 with nsswitch.conf configured to use the DNS backend for the networks database (i.e., networks: dns or similar entry present).
2. Position for DNS observation: Gain network-adjacent access to intercept DNS traffic between the target host and its configured DNS resolver (e.g., via ARP spoofing, rogue DNS server, or control of the upstream resolver).
3. Trigger the vulnerable code path: Cause the target application to call getnetbyaddr() or getnetbyaddr_r() with a net argument of zero (0x0). This may be achievable by controlling input to an application that performs network-by-address lookups, or by crafting a scenario where the default network is queried.
4. Capture the DNS query: Intercept the outbound DNS query generated by _nss_dns_getnetbyaddr_r. The query will contain uninitialized stack bytes appended to the DNS request payload.
5. Extract and analyze leaked data: Parse the captured DNS query to recover the leaked stack contents, which may include memory pointers (useful for ASLR bypass), session tokens, or other sensitive values from the process's stack frame (oss-security).

• Network: Anomalous or malformed DNS queries for network-type records (PTR/IN-ADDR lookups for network 0.0.0.0) originating from application servers; DNS queries with unexpected trailing bytes or oversized payloads beyond standard query structure.
• Network: Unusual DNS traffic patterns where queries for zero-valued networks (0.0.0.0) are observed, particularly from services that perform reverse network lookups.
• Logs: System or application logs showing calls to getnetbyaddr with a network value of zero; DNS resolver logs recording queries for 0.in-addr.arpa from unexpected hosts.
• Process: Processes linked against glibc performing unexpected DNS lookups for network address 0.0.0.0 or 0.0.0.0/0 in network monitoring tools (e.g., strace, tcpdump).

The fix was introduced in glibc 2.43 (fix commit e56ff82d5034ec66c6a78f517af6faa427f65b0b) (oss-security). Red Hat has issued patches for affected RHEL versions: RHSA-2026:1334 (RHEL 10), RHSA-2026:2786 (RHEL 9), and RHSA-2026:4772 (RHEL 8) (Red Hat Bugzilla). Ubuntu addressed the issue via USN-8005-1, and Debian issued fixes in the 13.4 and 12.14 point releases. As an immediate workaround, administrators should review nsswitch.conf and remove or replace the dns backend for the networks database if not required, and implement network segmentation to restrict which systems can reach configured DNS resolvers. IBM has released patches for affected products including Netezza Appliance and API Connect (IBM Netezza, IBM API Connect).

The vulnerability received notable coverage from the Linux community given that the underlying bug dates back to glibc 1.92 (circa 1996), making it a decades-old flaw (Phoronix). Security news outlet SecurityOnline.info highlighted it alongside other glibc heap corruption issues disclosed in the same batch (SecurityOnline). Discussion on Hacker News and Reddit's r/linux generated community interest, with users noting the rarity of calling getnetbyaddr with a zero value in practice. The glibc maintainer Carlos O'Donell published the formal advisory on the oss-security mailing list and noted that exploitation requires network-adjacent access, tempering alarm (oss-security).