from Hacker News

Critical Cache Poisoning Vulnerability in Dnsmasq

by westurner on 8/19/25, 12:56 PM with 114 comments

• by westurner on 8/19/25, 1:02 PM

  Many router firmwares have dnsmasq for DNS but may never be upgraded?

  There are a number of other DNS servers which are not written in C, which support transport-secured DNS like DoH (DNS-over-HTTP), DoT, and DoQ; but do they correctly handle this malformed input?

  From the mailing list disclosure, which doesn't yet have a CVE FWIU? https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/20... :

    Dnsmasq forwards queries with special characters (e.g., ~, !, *, _) to upstream recursive resolvers.
  
    Some upstream recursive resolvers silently discard such malformed queries (no NXDomain/ServFail response).
  
    Dnsmasq does not validate or detect this situation, and waits silently, creating a large attack window.
  
    During this window, attackers can brute-force TxID (16-bit) and source port (16-bit) with a high probability of success (birthday paradox effect).
  
    Security Impact
  
    Attackers can poison any cached domain name in Dnsmasq.
  

  [...]

    We recommend adding:
  
    Detection mechanisms when upstream resolvers remain silent.
  
    Rate limiting and spoof-detection techniques, similar to those in PowerDNS
  

  > PowerDNS Mitigation: https://docs.powerdns.com/recursor/settings.html#spoof-nearm...

    spoof-nearmiss-max

• by dc396 on 8/19/25, 2:00 PM

  I'm confused. There are no "special characters" in domain names -- they're length-tagged 8-bit clean. Hostnames (as opposed to domain names) are limited by convention to a subset of ASCII, but that shouldn't impact resolver logic.

  What resolvers silently discard (or do anything else weird with) requests with QNAMES that have non-hostname queries (which aren't "malformed")?

  The "special character" thing sounds like a red herring: IIUC, dnsmasq isn't dealing with lost responses correctly, creating a window for birthday collision attack?

• by forkerenok on 8/19/25, 1:56 PM

  I thought they have accidentally "responsibly disclosed" the vulnerability directly into a public mailing list, but the attached pdf is dated >3 months ago.

  So assume it's a bit of an inaccurate phrasing.

  EDIT: nope, the email itself seeks disclosure coordination etc. So yeah, oops.

• by 1vuio0pswjnm7 on 8/19/25, 7:17 PM

  Wishful thinking: OpenWRT userland can now replace dnsmasq with two separate programs. The DHCP server, odhcpd, is already included (for DHCP6). They just need to write the DNS software.

  I always disable/remove dnsmasq when I can. Compared to the alternatives, I have never liked it. This is at least the second major dnsmasq coding mistake that has been published in recent memory.^1 Pi-Hole was based on dnsmasq which turned me off that as well.

  1.

  https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq...

  https://www.cisa.gov/news-events/ics-advisories/icsa-21-019-...

  https://www.malwarebytes.com/blog/news/2021/01/dnspooq-the-b...

  https://web.archive.org/web/20210119133618if_/https://www.js...

  https://seclists.org/oss-sec/2021/q1/49

  Anyway, never gonna happen. Just wishful thinking.

• by rwmj on 8/19/25, 3:07 PM

  A bit surprising that the transaction ID is only 16 bits. Presumably the source port doesn't even need to be guessed if someone is on the path between dnsmasq and the upstream DNS server.

• by charcircuit on 8/19/25, 11:11 PM

  How would this even be exploited? What software would try and use such an invalid domain? It would always fail, so such a thing would never be shipped to end users. The only thing I can think of is some kind of social engineering attack, but at that point I feel like you can just use a normal attacker controlled domain instead of trying to do something special.

• by dzogchen on 8/19/25, 1:54 PM

  Oops, accidentally posted to public mailing list?

• by karel-3d on 8/19/25, 4:03 PM

  google's dns resolver 8.8.8.8 correctly resolves the "special character" domains btw; so if you have 8.8.8.8 as your recursive resolver in dnsmasq, this doesn't seem to be an issue.

• by tonymet on 8/19/25, 6:33 PM

  there are easily 300m+ installs of dnsmasq that will never be updated, because they are buried in forked , unmaintained firmwares on consumer routers.

  We truly need a "right to repair" for IOT & consumer networking devices. Any device not receiving monthly security updates should have the firmware keys & source published so the community can take over.

• by teeray on 8/19/25, 2:05 PM

  Would an effective mitigation be to drop inbound DNS queries that match those special characters using DPI?