SURIQ
The web panel on a router treats the network it manages as the thing it is defending, not as a source of attacker input. That assumption is exactly what breaks in CVE-2026-61876, a stored cross-site scripting flaw rated CVSS 8.8 in LuCI, the control panel that ships as the default web interface on OpenWrt. A device sitting on the network can name itself with a chunk of HTML, and when the administrator opens the page that lists DHCP leases, that HTML runs as script inside their logged-in session.
No password, no click on a malicious link, no foothold on the router itself. The attacker's device just asks for an address the way any laptop or smart plug does, and it supplies a hostname. The payload waits in the lease table until an admin looks at it.
What actually happens
When a client requests an IPv6 address, it can include a hostname through the DHCPv6 Client FQDN option. OpenWrt's address daemon records that name, and LuCI shows it back to the administrator on the Status > Overview page and the Network > DHCP and DNS page. Per the OpenWrt LuCI advisory, the panel writes that hostname straight into the page through an internal helper that sets innerHTML on the table cell without encoding it first. A browser reading innerHTML parses whatever is there as live markup, so a hostname that contains an HTML tag becomes an executing element, not text.
The result is script running in the administrator's LuCI origin. The advisory notes that from there an attacker can read the page, change the router's configuration, or issue other privileged actions on the admin's behalf. On a router, configuration is the whole game: DNS servers, firewall rules, port forwards, and remote-access settings all live behind that same panel. The researcher credited with the report is listed as lujiefsi, and the advisory includes a short proof-of-concept payload, which we are not reproducing here.
It is a two-part failure, and the deeper half scores higher
The CVE covers the LuCI rendering bug, but a companion advisory published on June 29 describes the daemon-side problem that makes it worse. The address daemon writes the client-supplied name verbatim into its lease file. Because a hostname can carry a newline, a client can inject not just markup but an entire extra line into that file, and LuCI's lease parser then reads the forged line back as a real record. That advisory, filed by a researcher listed as puru1761, is scored CVSS 9.6 and was reported unfixed at the time it was published.
| Advisory | Layer | CVE | CVSS 3.1 | Root cause |
|---|---|---|---|---|
| GHSA-686p-p8p9-x6fh | LuCI web UI | CVE-2026-61876 | 8.8 | Lease hostname written to innerHTML unescaped |
| GHSA-hhmc-92hw-535f | odhcpd daemon | not assigned | 9.6 | FQDN written verbatim to the lease file, allowing line injection |
The split matters for how you fix it. Encoding the hostname when LuCI draws the table closes the door that lets the script execute, which is why the LuCI patch is the one to chase. The daemon fix stops the input from ever being malformed in the first place. You want both, but the LuCI change is the one that stops your admin browser from running someone else's code.
"Adjacent network" undersells the exposure
The CVSS vector reads AV:A, adjacent network, which sounds like a high bar. On a router it is not. The adjacent network is the router's reason to exist. Every guest laptop, every phone on the wifi, every IoT bulb and print server that pulls a lease is an untrusted party that can write into a page the administrator implicitly trusts. The attacker does not need to be physically near anything. They need a lease, which is the one thing a router hands out on request.
That inverts the trust boundary a lot of operators carry in their heads. Guest wifi, a segment full of cheap smart devices, a coworking or hotel network, a lab full of gear you did not personally provision: those are the least trustworthy machines on the network, and this bug lets any of them stage code aimed at the most privileged browser session on it. If your OpenWrt box only ever serves a handful of devices you own, your exposure is small. If it hands DHCPv6 leases to anything you do not control, treat this as reachable.
Stored cross-site scripting through a device-supplied string is not a new class. Admin dashboards that echo hostnames, user agents, or device names back without encoding have produced this bug for years, and our own running tally of what actually breaks keeps landing on the same tired categories. The lesson each time is identical: data that originated from an untrusted party stays untrusted no matter how internal the page that displays it feels.
Patch is the fix. Knowing is the harder part.
This attack fires inside the administrator's browser, so it leaves little for a normal log to catch. You cannot easily watch the payload execute. You can, however, audit the data that feeds it. A hostname in your DHCP lease table that contains angle brackets or anything resembling an HTML tag has no legitimate reason to be there. It is a device announcing itself in a language browsers execute, and it is worth treating any such entry as hostile until proven otherwise.
The safer operational habit while you patch: do not open the lease or status pages from an admin session on a network you do not trust. The bug needs an administrator to view the page. Until the fix is in, that view is the trigger.
What to do now
- Update LuCI. The output-encoding fix landed in commits
55379d0on the main branch andec518efon the 25.12 stable branch. Update your LuCI packages to a build that carries it, or move to a snapshot or the next 25.12 point release once it includes the change. - Reduce the input surface where you can. If a segment does not use IPv6, it does not need a DHCPv6 server, and turning that off on that interface removes this particular injection path. Confirm you are not relying on IPv6 there before you change it.
- Audit your lease table. Look at the DHCP and DHCPv6 lease entries for hostnames containing HTML characters. Anything with a tag in it is a signal, not a curiosity.
- Hold off on admin sessions over untrusted networks until you have patched, since viewing the lease page is what sets the payload off.
OpenWrt runs on a long tail of consumer and small-office hardware that rarely gets touched after setup, which is precisely where a bug that waits quietly in a lease table does its best work. The fix is small. The habit it should leave behind is bigger: the panel you use to run the network is downstream of the network, and it has to distrust its own inputs like anything else facing the internet.