CVE-2020-25685 is a DNS cache-poisoning vulnerability in dnsmasq before version 2.83. In forward.c:reply_query(), dnsmasq matches replies to forwarded queries using only a weak hash of the query name instead of fully validating the query name as part of reply matching. The implementation uses CRC32 when dnsmasq is compiled without DNSSEC and SHA-1 when compiled with DNSSEC. Because different domain names can be crafted to produce the same hash, an off-path attacker can substantially reduce the search space needed to forge a DNS reply that dnsmasq will accept as matching an outstanding query. This behavior is inconsistent with RFC 5452 guidance for DNS response matching and enables cache poisoning by allowing spoofed responses to be accepted under collision conditions. The issue affects dnsmasq deployments with caching enabled and can be combined with related DNSpooq weaknesses, particularly CVE-2020-25684, to further reduce attack complexity.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a proof-of-concept (PoC) exploit for DNS cache poisoning vulnerabilities in dnsmasq (CVE-2020-25686, CVE-2020-25684, CVE-2020-25685), collectively known as DNSpooq. The exploit is implemented in Python (attacker/exploit.py) and is designed to run in a Dockerized environment with three containers: attacker, forwarder (dnsmasq), and cache. The exploit script sends a large number of spoofed DNS responses to the forwarder, attempting to brute-force the correct transaction ID and source port to poison the DNS cache. If successful, queries for a target domain (e.g., google.com) will resolve to an attacker-controlled IP (e.g., 169.254.169.254). The repository includes Dockerfiles for each component, a docker-compose.yml for orchestration, and a simple DNS sniffer (cache/sniff.py) to monitor DNS queries. The exploit demonstrates the practical impact of weak randomization in DNS transaction IDs and source ports in vulnerable dnsmasq versions.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
4 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A DNS cache-poisoning vulnerability in the DNSpooq set that affects ASUS routers according to this advisory.
A DNSpooq cache poisoning-related vulnerability in dnsmasq that contributes to DNS cache poisoning when chained with the related flaws.
Dnsmasq uses a weak hashing algorithm (CRC32) for DNS response validation when compiled without DNSSEC, making it susceptible to DNS cache poisoning.
A DNS-related vulnerability where weak hashing (CRC32/SHA-1) of query names enables hash-collision-based response forgery, potentially leading to spoofing/poisoning-like impacts depending on deployment.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.