CVE-2005-0877

Why Exploitable?

This vulnerability in dnsmasq before 2.21 allows remote attackers to poison the DNS cache by injecting unsolicited answers. Although EPSS data is not available and no public exploits or PoCs are indexed in Watchstack, the high severity and the nature of the attack (cache poisoning) make it a significant risk. Since it is not in CISA KEV, there is no evidence of active exploitation in the wild, but the vulnerability is old and may still affect unpatched systems. Organizations should verify their dnsmasq version and upgrade to 2.21 or later immediately. They should also monitor DNS traffic for anomalies and ensure that DNS servers are not exposed to untrusted networks. The absence of EPSS and KEV does not diminish the potential impact; proactive patching and hardening are essential.

Overview

CVE-2005-0877 is a high-severity DNS cache poisoning vulnerability affecting dnsmasq versions prior to 2.21. The issue, classified under CWE-346 (Origin Validation Error), allows remote attackers to inject false DNS records into the cache by sending answers to queries that were never made. This flaw was publicly disclosed in 2005 and affects dnsmasq deployments, particularly on Linux systems such as Debian. With a CVSS base score of 7.5 and an EPSS percentile of 77.8, the vulnerability poses a significant risk to network integrity. Security teams managing DNS infrastructure should prioritize patching to prevent cache poisoning attacks that could redirect users to malicious destinations.

Technical details

The root cause of CVE-2005-0877 is insufficient validation of DNS response sources. dnsmasq fails to verify that incoming DNS answers correspond to outstanding queries, allowing attackers to send spoofed responses that are accepted and cached. This weakness falls under CWE-346, indicating a failure to validate the origin of network data. The vulnerable component is the DNS forwarding and caching logic in dnsmasq versions before 2.21. Attackers can exploit this by sending crafted DNS responses to the dnsmasq server, which then caches the malicious records. The attack requires network access to the dnsmasq service, typically on UDP port 53, and does not require authentication. Trust boundaries are violated because dnsmasq trusts responses without verifying they were solicited, enabling cache poisoning.

Impact

Successful exploitation of CVE-2005-0877 allows an attacker to poison the DNS cache, leading to the redirection of legitimate domain queries to attacker-controlled IP addresses. This can result in confidentiality breaches as users are lured to phishing sites, integrity loss as DNS responses are corrupted, and availability issues if services are disrupted. Downstream abuse scenarios include man-in-the-middle attacks, credential theft, and malware distribution. For defenders, the business exposure includes compromised network trust, potential data breaches, and reputational damage. The high severity and relatively high EPSS percentile indicate that this vulnerability is actively targeted, making immediate mitigation essential.

Exploitation steps

1. Identify a vulnerable dnsmasq instance (version < 2.21) on the network.
2. Determine the DNS queries that clients are likely to make (e.g., common domains).
3. Craft a malicious DNS response containing a forged A record for the target domain.
4. Send the crafted response to the dnsmasq server's UDP port 53, spoofing the source IP of the legitimate DNS server.
5. Ensure the response is accepted and cached by dnsmasq (no validation of query origin).
6. Wait for clients to query the poisoned domain, receiving the attacker's IP address.
7. Redirect users to malicious services, such as phishing pages or malware hosts.

Indicators of compromise

• Unusual DNS responses that do not match any outstanding queries in network traffic logs.
• Multiple identical DNS responses from different source IPs for the same query.
• DNS cache entries that point to IP addresses not associated with the legitimate domain.
• Anomalous outbound connections to IP addresses that were recently resolved via DNS.
• Logs showing DNS queries for domains that were never requested by internal clients.
• Increased DNS traffic to port 53 from unexpected external sources.
• EDR alerts on processes making connections to newly resolved suspicious IPs.
• Correlated network flows showing clients connecting to known malicious IPs after DNS resolution.

Mitigation and workarounds

• Upgrade dnsmasq to version 2.21 or later, which includes a fix for this vulnerability.
• Apply vendor-provided patches for affected Linux distributions, such as Debian security advisories.
• Restrict access to the dnsmasq service using firewall rules to allow only trusted DNS servers.
• Enable DNSSEC validation if supported to prevent spoofed responses.
• Monitor DNS logs for anomalies and implement rate limiting on DNS queries.
• Use network segmentation to limit exposure of DNS infrastructure.
• Consider using a more modern DNS server with built-in protections against cache poisoning.

Community reactions

Upon disclosure, the security community highlighted the importance of validating DNS response origins. Vendors and Linux distributions issued advisories and patches promptly. The vulnerability is often cited in discussions about DNS security best practices, emphasizing the need for source validation. While the issue is old, its inclusion in CVE databases and the high EPSS percentile suggest ongoing relevance for legacy systems. Security researchers have used this case to demonstrate the dangers of insufficient input validation in network services.

Additional resources

• Debian Security Advisory DSA-704-1
• CVE-2005-0877 NVD Entry
• dnsmasq Official Website