Anything That Can Reach Your OpenWrt Router's DHCPv6 Server Can Get Root On It. The Proof-of-Concept Is Public. Check Your Firmware Version.
- Patrick Duggan
- 1 hour ago
- 5 min read
There is a version number you should go look up before you do anything else today, and it is on the least interesting box you own.
CVE-2026-53921 is a stack buffer overflow in odhcpd, the DHCPv6, DHCPv4 and router-advertisement daemon that OpenWrt runs by default. It rates 9.8. The vector is the one that matters: network-reachable, low complexity, no privileges, no user interaction. An attacker who can send UDP to port 547 can overwrite a stack buffer in a process that runs as root, on hardware that frequently ships without stack canaries or address space layout randomization. On a desktop those missing mitigations are the difference between a crash and a compromise. On a home router or an embedded gateway, they are usually just missing.
Two independent overflow sites in the same call chain, both in the IA reply handler in dhcpv6-ia.c, both against the same 512-byte stack buffer named pdbuf. The first fails to account for a six-byte status sub-option while checking whether sixteen bytes remain, and a relay-forwarded REQUEST carrying twelve IA_NA options walks it two bytes past the end. The second does an unconditional thirty-six byte write — a four-byte option plus a thirty-two byte authentication record — with no bounds check at all, and an unsigned subtraction that underflows the size variable on the way. Twenty-two failing IA_PD options get you there with eight bytes to spare in the wrong direction.
The advisory ships two self-contained Python proof-of-concept scripts, about a hundred and twenty lines each, that build a minimal configuration, start the daemon, and drive it into AddressSanitizer output. That is public now.
Who can actually reach it
Be honest about the threat model, because it changes what you do about it. A router's DHCPv6 server listens on the inside. This is not, in the default consumer configuration, an attacker in Bulgaria reaching across the internet to your WAN port.
It is anyone already on the network. The guest on your Wi-Fi. The smart TV. The camera with the hardcoded password. The contractor's laptop. The one compromised workstation that phishing got. Every one of those is a device that can currently do nothing more privileged than request an address, and this turns it into root on the box that routes, resolves, and sees all of your traffic. In segmented enterprise and ISP deployments where DHCPv6 relays forward requests across boundaries, the reachable surface is wider than the local subnet — and it is relay-forwarded messages that trigger the first overflow site.
The lesson that generalizes past this CVE: the network service you never think about, running as root on the device you never patch, is the actual perimeter. Not the firewall in front of it.
It is not one bug, it is the whole daemon
CVE-2026-53921 came out of a cluster. The same maintenance work fixed a use-after-free in the DHCPv6 IA handler, stack memory disclosure through a truncated DHCPv6 option, a denial of service via size_t underflow, and a stack buffer overread caused by a DUID length endianness mismatch in a memcmp call. All in odhcpd. All reachable by something that can speak DHCPv6 at you.
The one that deserves its own paragraph is separate from the overflow family: an unauthenticated DHCPv6 client can inject lease-file lines through a crafted FQDN hostname, and those lines land as stored cross-site scripting in the LuCI administration interface. Read that as an attack chain rather than a bug list. A device on the network — no credentials, no interaction — plants a payload by asking for an address. The payload sits in the lease file. It fires when the administrator opens the web UI to see what is on the network. Investigating the intrusion is the trigger. We have written about this shape before under a different name: the thing that fires when the defender looks at it.
The same release cycle also fixed three flaws in uhttpd, the web server — an invalid chunk-length state reset, case-sensitive Transfer-Encoding matching, and a ubus POST body parse-error desync — plus a path traversal in cgi-io that enables arbitrary file read, and a set of LuCI privilege-escalation and XSS issues. This was not a patch. It was a sweep of the default-enabled network services.
The timing is the operational point
The fix has not been a secret. OpenWrt tagged 25.12.5 on July 1 and 24.10.8 on July 26. The advisories and the working proof-of-concept code went public in the last two days.
That gap is the window every defender actually lives in. For four weeks on the current branch, the patch existed and the exploit did not. As of this week, both do. If you were going to get to it eventually, eventually arrived.
And the version you are running is very likely not the version upstream shipped. OpenWrt is upstream for a large amount of commercial customer-premises equipment and consumer router firmware, and vendor builds lag — in one GL.iNet community thread this week, users noted the Flint2 was still on 24.10.4 while upstream had moved to 24.10.8. If you own a device whose firmware is derived from OpenWrt rather than installed from it, upstream being patched does not mean you are, and the vendor's release cadence is now your exposure window.
What to do tonight
Run 24.10.8 or 25.12.5. That is the fix, and on stock OpenWrt it is a firmware upgrade you can do from LuCI or from the shell in the time this takes to read.
If you cannot upgrade — vendor firmware, a device in production, a box you cannot take down — the advisory's own mitigations are the right ones. Restrict UDP 547 at network boundaries if DHCPv6 relay is not something you actually need. Turn off the DHCPv6 server outright if nothing on your network uses it, which for a lot of IPv4-only home and small-office networks is the honest answer. Where the daemon runs in a container or VM, make sure memory protections are enabled. And watch syslog for unexpected odhcpd crashes or stack canary violations, because on hardware without ASLR the first several attempts at this tend to be crashes before one of them is not.
Check your downstream devices too, not just the router you think of as the router. Anything running an OpenWrt-derived build with DHCPv6 enabled is in scope, and the population of those is much larger than the population of people who know they own one.
We hold this at 95 percent. There are no reports of in-the-wild exploitation as of today, which is a statement about what has been observed and reported, not a statement about what is happening. The proof-of-concept is public, the daemon runs as root, and the target class is embedded devices that historically get patched slowly or never. Draw the obvious inference and get ahead of it.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments