On 15 April 2026 SUSE published SUSE-SU-2026:1369-1, a glibc update for SUSE Linux Enterprise 15 and openSUSE Leap 15.6 that fixes two flaws in how the library handles DNS responses. Both carry a moderate rating, but they’re worth applying because they touch code that runs in almost any program that resolves network names.
What actually breaks
glibc ships its own DNS backend, the one used when nsswitch.conf delegates resolution to dns. Both CVEs sit on that path.
CVE-2026-4437 is an out-of-bounds read in DNS response processing. If a configured server returns a crafted response, the resolver can treat a section that is not the answer section as if it were, in violation of the DNS specification. In practice that means out-of-bounds memory accesses when an application calls gethostbyaddr or gethostbyaddr_r with the DNS backend active. The most likely outcome is the process crashing, so denial of service.
CVE-2026-4438 is subtler: under certain responses the resolver can return an invalid hostname to the caller, again contrary to the standard. An application that trusts that name to make decisions (logging, hostname-based access control lists, audit records) gets data that should never have passed validation.
The affected glibc versions run from 2.34 to 2.43. The attacker doesn’t need to be on your local network: it’s enough to control, or be able to poison, a response from the DNS server your system queries.
Who is affected
Any SUSE/openSUSE system listed in the advisory that uses the glibc resolver, which is the default. Servers that do reverse DNS lookups regularly carry the most weight: load balancers, mail servers checking the PTR of whoever connects, monitoring tools and any service that logs the client’s hostname. That’s where gethostbyaddr gets called constantly and where a crafted response has the most surface to cause harm.
Severity and mitigation
SUSE rates both flaws as moderate. There’s no demonstrated code execution; the realistic impact is a service crash (CVE-2026-4437) or working with a hostname that isn’t valid (CVE-2026-4438).
The fix is straightforward: update the glibc package with zypper.
sudo zypper refresh
sudo zypper patchAfter patching, restart the services that have glibc loaded in memory, or reboot the machine if you want to be sure nothing keeps using the old version. There’s no convenient mitigation that avoids updating: the vulnerable code is in the resolver itself, so patching is the way to go. If you run openSUSE, you’ll find more context on the distribution’s cycle in the openSUSE page.
Source
- Official advisory: SUSE-SU-2026:1369-1
- CVE-2026-4437 on NVD
- CVE-2026-4438 on NVD