The OpenWrt project has released version 24.10.8, which fixes the critical vulnerability CVE-2026-53921 (CVSS 3.1: 9.8) — a stack buffer overflow in the odhcpd daemon that processes DHCPv6 requests. An unauthenticated attacker with network access to UDP port 547 can send a specially crafted DHCPv6 REQUEST packet and overwrite the stack buffer, which on typical embedded hardware is highly likely to lead to arbitrary code execution with root privileges. Public Python exploit code is already available. Users of the 24.10 branch need to upgrade to 24.10.8, and users of the 25.12 branch to 25.12.5.
Technical anatomy of CVE-2026-53921
According to the official advisory, the vulnerability affects two independent overflow points in the DHCPv6 request processing path. In both cases, specially crafted IA options fill a fixed 512-byte stack buffer, after which the code appends response data without checking the remaining space.
The first exploitation path requires pre-creating five IA_NA bindings via a SOLICIT packet; the second is triggered by a single crafted REQUEST. Both are documented with working Python PoC scripts.
The severity is compounded by the fact that odhcpd runs with root privileges, and the embedded hardware on which OpenWrt is typically deployed generally lacks protection mechanisms such as stack canaries and ASLR. This makes the transition from a buffer overflow to full code execution a realistic scenario rather than a theoretical possibility.
All versions of odhcpd up to and including commit e432dd6 that contain the functions dhcpv6_ia_handle_IAs() and build_ia() are affected. The fix is implemented by checking the remaining capacity of the response buffer before adding data.
Notable detail: there is a discrepancy in classification between the advisory and the release notes. The advisory groups both overflow paths under CVE-2026-53921, whereas the 24.10.8 release notes single out the RECONF_ACCEPT overflow as a separate high-severity issue without its own CVE. Similarly, the release notes describe the attack vector as “network-adjacent” (Adjacent), whereas the CVSS vector in the advisory uses AV:N (Network). Neither source explains this discrepancy.
Additional vulnerabilities in the 24.10.8 release
In addition to the main vulnerability, the release fixes a whole range of issues in services enabled by default:
- odhcpd: out-of-bounds write, use-after-free, memory leak, denial of service, out-of-bounds stack read, spoofing via Neighbor Discovery proxy
- uhttpd: three HTTP request smuggling vulnerabilities
- CVE-2026-62948: hostname injection via DHCPv6, leading to stored XSS when viewing the leases page in LuCI
- CVE-2026-62947: path traversal in cgi-io, allowing reading of arbitrary files accessible to root. Requires an authenticated session with upload permission and an appropriate file-access pattern — this is not anonymous file reading
LuCI vulnerabilities: patches not yet merged
In parallel with the release, Hacker House published the results of an audit of LuCI and uhttpd using AI-assisted fuzzing. They identified command injection, path traversal, and XSS in optional LuCI components. During the process of preparing fixes, OpenWrt discovered an additional stored XSS vulnerability and the lack of CSRF protection.
Key findings, according to pull request #8878:
- luci-app-commands: the pipe character bypassed the allowlist of permitted arguments, allowing commands to be executed as root. OpenWrt determined that this path works without a session cookie and CSRF token if the administrator has configured a command as both public and parameterized at the same time
- luci-app-ddns: command injection via the ddns_dateformat setting and path traversal via service_name
- luci-proto-openvpn: command injection via the keytype parameter and path traversal via key-directory
- luci-app-olsr: a malicious mesh network node can advertise a hostname containing a script that will run in the administrator’s browser when viewing the OLSR neighbors page
It is important to keep the context in mind: these vulnerabilities are not universal unauthenticated RCEs affecting every OpenWrt router. The unauthenticated path via luci-app-commands requires the optional application to be installed and the administrator to have deliberately configured a command as both public (public=1) and parameterized (param=1). The other command-execution paths require authenticated access to LuCI. As of 28 July, both pull requests (#8878 and ddns-scripts) remained open and had not been merged into the main branch.
AI in detection and remediation
This case is notable for the large-scale use of AI on both sides of the process. Hacker House describes a four-stage “inference fuzzing” methodology: the Qwen 3.6 35B Heretic model generates a broad pool of potential vulnerabilities, then a higher-accuracy model (according to the researchers, Anthropic Claude Opus 4.6 for open projects) filters out false positives. Final verification is done manually. On the OpenWrt side, several commits in the pull request are tagged “Assisted-by: Claude:claude-opus-5”, and the automated review indicates the use of Claude Code.
Recommendations
- Immediately update your firmware to OpenWrt 24.10.8 or 25.12.5 via the OpenWrt Firmware Selector
- Update separately installed packages — they are not updated automatically together with the firmware
- Check the luci-app-commands configuration: make sure no command is configured as both public (public=1) and parameterized (param=1)
- Remove unused optional LuCI applications, especially luci-app-bmx7, luci-app-olsr, luci-app-commands
- Review delegated LuCI permissions, limiting access to cgi-io
- Plan migration to the 25.12 branch by September 2026 — the end of security support for the 24.10 branch
As of 28 July, neither CVE-2026-53921 nor the other vulnerabilities described had been added to the CISA KEV catalog, and official OpenWrt materials did not report exploitation in the wild. However, the availability of public PoC code for a critical vulnerability in a service running as root on hardware without ASLR makes the window before active exploitation begins very small. Firmware should be updated within hours, not days.
