What Are DNSmasq Vulnerabilities and Which CVEs Impact Them?
DNSmasq vulnerabilities include 7 CVEs (CVE-2020-25681 to CVE-2020-25687) affecting DNS resolution in self-hosted environments. Buffer overflows in DNSSEC processing cause crashes. Weak response validation enables poisoning. OpenWrt 19.07.0-19.07.5 versions suffer primary impacts. Fixes appear in 19.07.6.
Check whether you run the dnsmasq-full package, because it decides how many of the seven apply. CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, CVE-2020-25685 and CVE-2020-25687 affect only dnsmasq-full. CVE-2020-25684 and CVE-2020-25686 affect dnsmasq, dnsmasq-dhcpv6 and dnsmasq-full, so every variant is exposed to those two.
CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 and CVE-2020-25687 are buffer overflows in DNSSEC handling. CVE-2020-25685 is weak response hashing, CVE-2020-25684 is weak matching of replies to queries, and CVE-2020-25686 lets a second request for the same name be forwarded while one is pending. Incorrect or unavailable DNS answers can interrupt access for everyone using the affected resolver.
OpenWrt Security Advisory 2021-01-19-1 documents these CVEs. It lists OpenWrt 19.07.0 to 19.07.5 as affected and fixed in 19.07.6. The older 18.06, 15.05 and LEDE 17.01 releases are end of life and will not get a fix.
How Do DNSmasq Vulnerabilities Cause Website Downtime?
DNSmasq vulnerabilities trigger downtime by crashing the DNS resolver through heap buffer overflows during DNSSEC validation. Cache poisoning attacks serve incorrect records. These actions block domain resolution for self-hosted sites. A buffer overflow can crash the affected dnsmasq process and interrupt DNS queries until the service restarts.
CVE-2020-25685 concerns weak CRC32 hashing of the query name, which dnsmasq uses to match a reply to a forwarded query when it is built without DNSSEC. Collisions make a forged reply easier to land, and a successful poisoning attack serves incorrect DNS answers from the cache.
CVE-2020-25686 means dnsmasq forwards a second query for the same name while one is already pending. That lets an attacker race many forged replies against the real one.
Which DNSmasq Versions Are Vulnerable to These CVEs?
OpenWrt 19.07.0 to 19.07.5 is vulnerable to all seven CVEs if it runs dnsmasq-full, and to CVE-2020-25684 and CVE-2020-25686 on any dnsmasq variant. Five of the seven affect only the dnsmasq-full package, and two affect every variant. OpenWrt 19.07.0 to 19.07.5 shipped dnsmasq 2.80 builds. Upstream, every dnsmasq before 2.83 is affected, so 2.81 and 2.82 are vulnerable too. Fixed releases are dnsmasq 2.80-16.2 (in OpenWrt 19.07.6) and 2.83-1 for snapshots. The OpenWrt advisory names 2.83-1 as the snapshot fix.
To upgrade, run:
opkg update; opkg upgrade $(opkg list-installed dnsmasq* | cut -d' ' -f1)
Then verify with opkg list-installed dnsmasq*. It should show 2.80-16.2 on 19.07 or 2.83-1 on snapshots.
What DNSSEC Buffer Overflows Occur in DNSmasq Vulnerabilities?
DNSmasq DNSSEC vulnerabilities feature heap-based buffer overflows: CVE-2020-25681 in RRSets sorting, CVE-2020-25682 in name extraction from packets, CVE-2020-25683 in get_rdata subroutine, and CVE-2020-25687 in sort_rrset before validation. These flaws crash resolvers that process malformed DNSSEC data.
CVE-2020-25681 concerns a heap overflow during resource-record-set sorting before DNSSEC validation. Malformed responses can interrupt the resolver.
CVE-2020-25682 concerns a buffer overflow while extracting names from DNS packets, before DNSSEC validation. It only affects dnsmasq-full.
CVE-2020-25683 concerns a heap overflow in get_rdata with DNSSEC enabled before validation. A crafted response can crash the vulnerable resolver.
CVE-2020-25687 concerns a heap overflow in sort_rrset before DNSSEC validation. It only affects dnsmasq-full.
How Does Weak DNS Response Validation Contribute to DNSmasq Issues?
In CVE-2020-25684, dnsmasq does not use the reply's address and port to find the exact forwarded query it answers. That reduces the number of attempts needed to forge a reply. CVE-2020-25685 uses an insecure CRC32 hash of the query name when built without DNSSEC. CVE-2020-25686 forwards a new request even when one is pending. Together these flaws make cache poisoning easier.
Weak response validation can permit incorrect answers to enter a resolver cache.
Spoofed replies that a vulnerable resolver accepts send users to the wrong address or break resolution for them.
The OpenWrt advisory describes configuration mitigations for when upgrading is not possible. Disabling caching or DNSSEC changes resolver behavior and has side effects, so treat these settings as temporary.
What Mitigation Commands Fix DNSmasq Vulnerabilities in OpenWrt?
Upgrade the package first. If you cannot, the OpenWrt advisory gives three UCI settings that reduce the risk. Each one targets a different problem:
cachesize='0'disables caching, against cache poisoning.dnssec='0'disables DNSSEC, against the DNSSEC buffer overflows.dnsforwardmax='50'lowers the forwarded-query limit from the default 150.
uci set dhcp.@dnsmasq[0].cachesize='0'
uci set dhcp.@dnsmasq[0].dnssec='0'
uci set dhcp.@dnsmasq[0].dnsforwardmax='50'
uci commit dhcp
/etc/init.d/dnsmasq restart
The advisory warns that these settings only mitigate some of the issues and may have unintended side effects. They are a stopgap, not a fix.
The package upgrade is the real remediation:
opkg update; opkg upgrade $(opkg list-installed dnsmasq* | cut -d' ' -f1)
opkg list-installed dnsmasq*
The second command should show 2.80-16.2 on OpenWrt 19.07 or 2.83-1 on snapshots. LuCI shows the same dnsmasq settings in a web interface. After upgrading, restore the caching and DNSSEC settings you turned off.
How Can DNS Monitoring Tools Detect DNSmasq Vulnerability Effects?
DNS checks catch resolution failures and unexpected answers, but they cannot tell you the cause by themselves. Visual Sentinel checks your DNS records on a schedule, and the DNS propagation guide covers what to watch for. It sees your public records, not a dnsmasq resolver on your LAN.
Investigate NXDOMAIN and unexpected IP answers alongside resolver logs and configuration. An unexpected answer is a reason to look, not proof of a poisoned cache.
DNS Checker looks up a record on demand. Compare its answer with what your own resolver returns, and check the resolver logs.
How Does Visual Sentinel Prevent Downtime from DNSmasq CVEs?
Visual Sentinel checks your website's DNS records on a schedule and alerts you when your site stops responding. It does not diagnose DNSmasq CVEs or scan resolver code, so patching stays your job.
Uptime Monitoring checks your site's availability, so you can compare it with the DNS results. Visual Sentinel also compares screenshots and checks expected page text.
What Configurations Reduce DNSmasq Vulnerability Risks?
Three settings reduce the risk until you can upgrade. cachesize=0 disables caching, which defends against cache poisoning. dnssec=0 disables DNSSEC, which defends against the DNSSEC overflows. dnsforwardmax=50 lowers the forwarded-query limit from 150. They are temporary and have side effects, so the package upgrade stays the fix.
After remediation, restore the resolver settings you changed. Website Checker runs a manual check of your site and Speed Test tests its page speed. A passing check does not show the package is patched, so confirm the version with opkg list-installed dnsmasq*.
How Do DNS Monitoring Tools Compare for DNSmasq Issue Detection?
Website monitoring tools check DNS and availability. None of them is a DNSmasq CVE scanner. Visual Sentinel covers uptime, SSL, DNS, performance, visual and content checks.
Visual Sentinel checks DNS records on a schedule. Plans start at $15/month (Solo, 10 monitors). Compare website features at Visual Sentinel vs Pingdom and Visual Sentinel vs UptimeRobot.
| Entity | Pricing Tier | Global Locations | Key Differentiator |
|---|---|---|---|
| Visual Sentinel | from $15/month (Solo, 10 monitors) | Europe and the US | Uptime, SSL, DNS, performance and visual checks (content monitoring starts on Starter) |
| Pingdom (SolarWinds) | From $16.50/month billed annually (10 uptime checks) | 100+ | Uptime, page speed and transaction checks |
| UptimeRobot | Free for 50 monitors | 4 regions (North America, Europe, Asia, Australia) | 5-minute checks on the free plan |
UptimeRobot offers 50 free monitors with email alerts.
What Should You Do Next?
- Upgrade the package: run
opkg update; opkg upgrade $(opkg list-installed dnsmasq* | cut -d' ' -f1), or flash OpenWrt 19.07.6 or later. - Verify with
opkg list-installed dnsmasq*. You want 2.80-16.2 or 2.83-1. - If you cannot upgrade yet, apply the three UCI settings above and plan the upgrade.
- Add DNS Monitoring and Uptime Monitoring so a resolver or record problem shows up as an alert.
Ready to try it on the site you run? Start with checks for your own site and the alerts they send.
Check your site while you read
Run a free check for regional reachability, response time, redirect handling, TLS evidence, and DNS resolution. No account is required.
Check a site freeCommon questions
What Are DNSmasq Vulnerabilities and Which CVEs Impact Them?
DNSmasq vulnerabilities include 7 CVEs (CVE-2020-25681 to CVE-2020-25687) affecting DNS resolution in self-hosted environments, with buffer overflows in DNSSEC processing and weak response validation leading to crashes or poisoning. OpenWrt 19.07.0-19.07.5 versions are primarily impacted, fixed in 19.07.6. Five of the seven (CVE-2020-25681, 25682, 25683, 25685, 25687) affect only dnsmasq-full; CVE-2020-25684 and CVE-2020-25686 affect all variants.
How Do DNSmasq Vulnerabilities Cause Website Downtime?
DNSmasq vulnerabilities trigger downtime by crashing the DNS resolver through heap buffer overflows during DNSSEC validation or enabling cache poisoning attacks that serve incorrect records, blocking domain resolution for self-hosted sites. This disrupts access for everyone using that resolver.
Which DNSmasq Versions Are Vulnerable to These CVEs?
OpenWrt versions 19.07.0 to 19.07.5 are vulnerable to CVEs 2020-25681 through 2020-25687 (five of them only on the dnsmasq-full package). Upstream, every dnsmasq before 2.83 is affected. Fixed releases are dnsmasq 2.80-16.2 for 19.07 stable and 2.83-1 for snapshots. The OpenWrt advisory names 2.83-1 as the snapshot fix. Verify with opkg list-installed dnsmasq*.
What DNSSEC Buffer Overflows Occur in DNSmasq Vulnerabilities?
DNSmasq DNSSEC vulnerabilities feature heap-based buffer overflows: CVE-2020-25681 in RRSets sorting, CVE-2020-25682 in name extraction from packets, CVE-2020-25683 in get_rdata subroutine, and CVE-2020-25687 in sort_rrset before validation. These crash resolvers when processing malformed DNSSEC data in self-hosted networks.
How Does Weak DNS Response Validation Contribute to DNSmasq Issues?
In CVE-2020-25684, dnsmasq does not use the reply's address and port to find the exact forwarded query, which reduces the attempts needed to forge a reply. CVE-2020-25685 uses an insecure CRC32 hash of the query name when built without DNSSEC. CVE-2020-25686 forwards a new request even when one is pending. Together these make cache poisoning easier.
What Mitigation Commands Fix DNSmasq Vulnerabilities in OpenWrt?
The OpenWrt advisory describes temporary mitigations if upgrading is unavailable: uci set dhcp.@dnsmasq[0].cachesize='0', uci set dhcp.@dnsmasq[0].dnssec='0', and uci set dhcp.@dnsmasq[0].dnsforwardmax='50'. Commit and restart with uci commit dhcp && /etc/init.d/dnsmasq restart. These settings have side effects and do not fix every vulnerability, so install the fixed package (2.80-16.2 or 2.83-1).
