CVE-2026-5435

What it actually does

This vulnerability is an out-of-bounds write in deprecated GNU C Library resolver/debugging functions ns_printrrf, ns_printrr, and fp_nquery. When these functions print DNS TSIG records, they may fail to respect the caller-provided output buffer length and write past the end of that buffer. In software that calls these APIs on attacker-controlled DNS data, a maliciously crafted TSIG record could corrupt process memory, potentially causing a crash, data corruption, or, depending on compiler protections and memory layout, limited code execution or control-flow manipulation within the affected process.

Why it matters to the business

Applications and services that use affected glibc resolver printing functions on untrusted DNS responses may be remotely disrupted or potentially compromised without authentication or user interaction. Because glibc is a foundational system library, exposure depends less on whether glibc is installed and more on whether installed applications call the affected deprecated APIs. The vulnerability is not currently listed in CISA KEV, has low EPSS, and has no known public exploit maturity, so broad active exploitation is not indicated; however, affected software should still be updated or rebuilt promptly because memory corruption in a core library can have high operational impact when reachable in network-facing services.

How an attack unfolds

An attacker first identifies software that uses the deprecated glibc DNS printing APIs to parse or display DNS data, especially TSIG records, from untrusted network input. The attacker then sends or causes the target to process a specially crafted DNS message containing a malformed or oversized TSIG record. When the vulnerable application invokes ns_printrrf, ns_printrr, or fp_nquery to print that record, the function may write beyond the intended buffer. The immediate outcome is likely process termination or memory corruption. In a favorable target-specific scenario, the attacker may be able to shape the overwrite to influence adjacent memory and achieve further impact, but exploitation reliability will vary significantly by application, architecture, hardening settings, and how the vulnerable API is used.

How to fix it

Upgrade GNU C Library packages to vendor-provided fixed versions as soon as they become available. No fixed versions were provided in the supplied data, so use the relevant Linux distribution or appliance vendor advisory as the source of truth. After updating glibc, restart affected services and long-running processes, or reboot systems, because processes already loaded with the vulnerable library will not benefit until restarted. Where immediate patching is not possible, reduce exposure by disabling or replacing software paths that call ns_printrrf, ns_printrr, or fp_nquery on untrusted DNS data, avoiding TSIG record printing from untrusted inputs, and applying compiler/runtime hardening such as stack canaries, ASLR, RELRO, FORTIFY_SOURCE, and memory-safe bounds checks in consuming applications. Developers should migrate away from these deprecated APIs and enforce explicit output length validation before formatting DNS records.

How to confirm the fix worked

Confirm installed glibc package versions against the fixed version listed by the operating system or appliance vendor once available. Validate that all affected services were restarted after the library update by checking process start times and loaded library mappings. For source-built applications, review code and dependencies for calls to ns_printrrf, ns_printrr, or fp_nquery, then rebuild and retest after applying patched glibc or code-level mitigations. Exposure testing should focus on whether network-reachable software processes untrusted DNS TSIG records through the affected functions; the mere presence of glibc is not sufficient to prove exploitability. In staging, use controlled malformed DNS TSIG test cases to verify that applications no longer crash or corrupt memory while processing DNS record printing paths.

Typical attack path

1. Identify a network-exposed application, diagnostic tool, resolver component, or DNS-related service linked against affected GNU C Library versions.
2. Confirm or infer that the application processes attacker-controlled DNS messages and uses ns_printrrf, ns_printrr, or fp_nquery for DNS record printing or logging.
3. Craft a DNS message containing a TSIG record designed to trigger excessive output during record printing.
4. Deliver the malicious DNS response or query path to the target application through direct network interaction, spoofed DNS traffic, malicious DNS infrastructure, or an upstream resolver workflow.
5. Trigger the vulnerable print routine and cause an out-of-bounds write in the application process.
6. Leverage the result for denial of service, memory corruption, or potentially further compromise depending on target-specific exploitability.

How to detect it

To determine whether this was already exploited, focus on applications that parse, print, log, or debug DNS records and are linked to affected glibc versions. Review application logs, system journals, crash reports, and core dumps for segmentation faults, aborts, or memory corruption events occurring during DNS processing, especially around TSIG records. Examine DNS server, resolver, network sensor, and packet capture logs for unusual or malformed TSIG records immediately before service crashes or restarts. Useful log sources include systemd journal, syslog, kernel logs, application-specific DNS logs, crash dump frameworks, endpoint detection telemetry, and network packet captures. Because no public exploit artifacts or KEV activity are indicated, detection should emphasize behavioral evidence: crashes in DNS-processing processes, anomalous TSIG-bearing DNS traffic, repeated remote-triggered restarts, and stack traces referencing ns_printrrf, ns_printrr, fp_nquery, or glibc resolver printing routines.

• ns_printrrf
• ns_printrr
• fp_nquery
• TSIG
• SIGSEGV
• segmentation fault
• buffer overflow detected
• *** buffer overflow detected ***
• malloc(): corrupted top size
• double free or corruption
• corrupted size vs. prev_size
• glibc detected
• core dumped
• systemd-coredump
• /var/lib/systemd/coredump/
• /var/crash/
• /var/log/syslog
• /var/log/messages

What your security team should do

• Inventory Linux systems, containers, appliances, and statically or dynamically linked applications that use GNU C Library 2.2 or newer.
• Prioritize review of DNS servers, resolvers, network monitoring tools, debugging utilities, mail gateways, security appliances, and custom software that parses or logs DNS records.
• Track operating system and appliance vendor advisories for the first fixed glibc packages, since no fixed version was provided in the input.
• Patch glibc when fixed packages are available and restart all affected services or reboot systems to clear vulnerable library instances from memory.
• Ask application owners and vendors whether their products call ns_printrrf, ns_printrr, or fp_nquery on untrusted DNS data, especially TSIG records.
• Add monitoring for crashes or abnormal restarts in DNS-processing services and tools while patches are pending.
• Treat crashes correlated with DNS TSIG traffic as suspicious and preserve core dumps, packet captures, and application logs for investigation.
• Do not rely solely on the low EPSS score; prioritize systems where the vulnerable code path is exposed to network-originated DNS data.