QWE AI Academy Here’s a detail buried in the announcement that almost nobody is leading with: the maintainer of dnsmasq, Simon Kelley, says the flood of bug reports causing this patch wave is being driven by AI-assisted security research – and he’s already warning a second patch round is coming. In his own words on the mailing list, there has been a revolution in AI-based security research, and the tsunami of AI-generated bug reports shows no signs of stopping. Translation: you’re going to patch this thing, and then probably patch it again in a month. Plan your maintenance accordingly.
The takeaway, before anything else
If you run dnsmasq directly (Linux server, Pi-hole, OpenWrt build, container), update to 2.92rel2 or your distro’s patched package today. If dnsmasq runs on a consumer router you didn’t compile yourself, you’re waiting for the vendor – and there’s a remote check you can run in 10 seconds to know how exposed you are.
That’s the whole post in two sentences. Everything below is the how, plus the parts the rapid news coverage skipped.
What just dropped (the short version)
On 11 May 2026, CERT released a set of six CVEs for serious security vulnerabilities in dnsmasq. These are all long-standing bugs which apply to pretty much all non-ancient versions. The CVE numbers themselves (2291, 4890, 4891, 4892, 4893, 5172) are easy to look up on CERT’s VU#471747, so I won’t recite all six. The shape of the threat matters more than the IDs:
- Cache poisoning / DNS redirect – an attacker steers your DNS lookups to their IP. Affects anyone using dnsmasq as a resolver.
- Info disclosure – memory contents and routing info leak via crafted DNS packets.
- Denial of service – three of the six can crash or hang dnsmasq.
- Local privilege escalation to root – CVE-2026-4892 is a heap-based out-of-bounds write in the DHCPv6 implementation that allows local attackers to execute arbitrary code with root privileges via a crafted DHCPv6 packet. Local only, and DHCPv6-only.
The fix is dnsmasq 2.92rel2, which contains fixes for all the reported vulnerabilities, with a full 2.93 stable release expected shortly after.
Method A vs Method B: how should you actually patch?
There are two realistic paths. They are not equally good, and the right one depends on how dnsmasq got onto your machine.
| Method A: distro package | Method B: build 2.92rel2 from source | |
|---|---|---|
| Effort | One apt/dnf command | ~10 min, requires build tools |
| Speed to fix | Already available on Debian stable and Ubuntu 22.04+ as of May 11 | Available the moment Kelley pushed the tarball |
| Catch | Older Ubuntu LTS needs Ubuntu Pro for ESM packages | You now own the build forever – no auto-updates |
| Best for | Anyone on a current, supported distro | Old LTS without Pro, custom builds, OpenWrt-style setups |
For 95% of readers, Method A wins. The exception is the USN-8268-1 fine print: fixes for Ubuntu 20.04, 18.04, and 16.04 are only available with Ubuntu Pro. If you’re running a free 20.04 box with dnsmasq exposed, you have three choices – pay for Pro, upgrade the OS, or build from source. None of them are zero-effort.
The walkthrough: patching with apt (the winner)
This is the path I’d take on any server I admin. Step by step on a Debian/Ubuntu host:
1. Check what version you’re on
dnsmasq -v | head -n 1
# Dnsmasq version 2.90 Copyright (c) 2000-2024 Simon KelleyAnything below the patched build for your distro is vulnerable. Per Debian’s tracker, 2.91-1+deb13u1 was accepted into stable-security and 2.90-4~deb12u2 into oldstable-security on 2026-05-11.
2. Pull the security update only
sudo apt update
sudo apt install --only-upgrade dnsmasq dnsmasq-baseThe --only-upgrade flag means apt won’t pull in unrelated kernel or library updates. Useful when you want the security fix now and the reboot later.
3. Restart the service and verify
sudo systemctl restart dnsmasq
dnsmasq -v | head -n 1
systemctl status dnsmasq --no-pagerThat’s the whole job. Total time: under two minutes on a warm package cache.
Pro tip: Before restarting, run
dnsmasq --testto validate your config syntax. If a recent edit broke something, you want to know before the service drops, not during the 5 seconds your network has no DNS.
4. Bonus: remote-check any resolver you don’t have shell access to
This is the trick worth bookmarking. Against your own router, your home Pi-hole, or any dnsmasq instance reachable on port 53:
nslookup -type=txt -class=chaos version.bind 192.168.1.1
# version.bind text = "dnsmasq-2.86"The CHAOS-class version.bind query is a quirk dnsmasq inherits from BIND. Using nslookup with type=txt and class=chaos against the router IP returns the dnsmasq version string. If you see a version below your distro’s patched build, you’ve found a gap.
The router problem nobody’s solving for you
Here’s where it gets uncomfortable. If dnsmasq is on your router rather than on a Linux box you control, neither method above helps. Consumer router firmware bakes dnsmasq into the image – you don’t get to apt-install over it.
On GL.iNet hardware, users on the official forum have asked whether they can upgrade dnsmasq independently of firmware updates, tried opkg update and opkg upgrade, and ended up with no updates available even when the upstream repositories show several updates. ASUS users hit the same wall – the dnsmasq version is whatever ASUS shipped.
Your real options:
- Wait for a firmware release from your vendor. The CVE was pre-disclosed to vendors, so some had patches ready for May 11 – but “some” is doing heavy lifting in that sentence.
- Flash OpenWrt or a community firmware that lets you update packages independently. Big jump in effort.
- Run your own resolver (a Pi-hole, a Linux box) behind the router, and configure clients to use it instead. Then you patch dnsmasq on a box you actually control.
For a home network where you don’t run DHCPv6, the local-root CVE is less urgent than the cache-poisoning ones. The remote-attacker-redirects-your-DNS scenarios are what should move you to act.
Edge cases worth knowing
Expect a second patch wave
Kelley was unusually candid about this. He plans to tag dnsmasq-2.93rc1 shortly with the aim of getting a stable 2.93 release done as soon as possible, hopefully out in about a week. Don’t treat your patch today as “done for the year.” Set a calendar reminder for early June 2026 to check the official CVE page.
DNSSEC users were hit hardest
Two of the six bugs (4890 and 4891) sit specifically in DNSSEC validation code, per the CERT advisory. Both can be triggered by remote attackers via crafted DNS packets. If you’re not running DNSSEC validation – most home dnsmasq setups don’t – your exposure to those two specifically is lower. The cache poisoning bug, though, doesn’t care about your DNSSEC config.
The AI angle
A single maintainer is now triaging more bug reports than he can keep up with. Automated AI fuzzers and code-review agents are finding real flaws faster than any one human can patch them. That’s a genuine shift in how open-source security works – and not a comfortable one for unpaid maintainers. For admins, the practical implication is blunter: “patch promptly” stops being a quarterly habit and becomes a continuous one.
Frequently asked questions
Do I need to patch if dnsmasq only listens on localhost?
Yes, but with less urgency. The remote-attacker CVEs need a packet path to dnsmasq – if you’re bound to 127.0.0.1 with no port forwarding, remote attackers can’t reach you. The local-root DHCPv6 bug, though, only needs a local user, and that bar is much lower (any unprivileged account, any container escape, any compromised process on the box).
How do I tell if my home router has been patched?
Run the chaos-class query shown above against your router’s LAN IP. Compare the version string to the latest your vendor has shipped. If your router reports a version below dnsmasq 2.92rel2 and your vendor’s most recent firmware notes don’t mention these CVEs, you’re likely still vulnerable. Vendor coordination was uneven on this one – some shipped on May 11, others will take weeks. Check your manufacturer’s security advisory page directly rather than trusting the auto-update indicator in the router UI; many of those only check for full firmware versions, not embedded library fixes.
Should I just switch to a different DNS server?
Probably not as a reaction to this. Dnsmasq remains a sensible choice for small networks; the alternatives (unbound, Pi-hole-with-unbound, systemd-resolved) have their own bug histories. Patch, monitor, move on.
Your next action
Open a terminal on the machine where dnsmasq actually runs. Run dnsmasq -v. If the version is below your distro’s patched build, run the two apt commands from section 3 above. Then run the chaos-class query against your router. If that returns a vulnerable version, file a support ticket with your vendor today citing CERT VU#471747 – vendor pressure is the only thing that gets router patches shipped quickly.