Executive summary A stored Cross site scripting (XSS) vulnerability in the Mercury MR816v2 (081C3114 4.8.7 Build 110427 Rel 36550n) router allows a remote attacker on the LAN to inject JavaScript into the router's management UI by submitting a malicious hostname. The injected script is stored and later executed in the context of an administrator's browser (for example after DHCP release/renew triggers the interface to display the stored hostname). Because the management interface uses weak/basic authentication and does not properly protect or isolate session material, the XSS can be used to exfiltrate the admin session and perform administrative actions.
Context
The vulnerability exists in how the router processes and displays hostnames received through DHCP updates.
According to RFC 2131, DHCP servers must handle hostname values but are not required to sanitize them for HTML output; therefore, the responsibility lies in the management interface.
In this product, the DHCP client-supplied hostname is:
- Received by the DHCP service.
- Stored in the device’s internal host table.
- Displayed in the web admin panel under the network devices / DHCP leases section.
- Rendered without HTML escaping, enabling persistent script injection.
Because the web UI automatically refreshes when new DHCP events occur, stored payloads can trigger without the administrator manually navigating to the page.
Vulnerability Details
The router’s firmware stores the hostname exactly as received from the DHCP request. When that hostname is later displayed inside the administrator’s browser, it is inserted directly into the DOM with no encoding or validation.
As a result:
- Any JavaScript payload injected via the hostname field will persist in the router configuration.
- The payload executes automatically when the admin interface displays the hostname list.
- The vulnerability is reachable from any device on the local network, including guest devices or compromised hosts.
Proof of Concept (PoC)
A LAN client can supply a malicious hostname through a DHCP request.
By configuring a DHCP client with a crafted hostname containing an HTML/JS injection payload and forcing DHCP renewal, the router stores and later reflects the value in the admin interface.
Example workflow (conceptual demonstration):
- Change the client hostname to include an embedded script.
- Force a DHCP DISCOVER/REQUEST cycle (e.g., via dhclient renewal).
- The router records the hostname and displays it in the admin device list.
- When the admin UI loads the list, the payload executes in the admin’s browser.
Illustration of the DHCP interaction and payload injection:
Figure 1 :
Once the hostname is stored, opening the admin panel triggers the script:
Figure 2 :
Because the router does not protect its cookies and relies on Basic Auth–style credentials, the executed script can capture sensitive session or credential information, enabling full administrative takeover.
Risk and Impact
- Stored XSS (persistent): payload remains active across reboots or DHCP events.
- Unauthenticated LAN attacker: any device on the network can trigger the flaw.
- Admin account compromise: theft of credentials or session with simple JavaScript exfiltration.
- Full router takeover : once authenticated control is obtained.
- Chaining potential with other weaknesses (e.g., weak auth, default credentials).
- Network‑wide consequences: DNS changes, traffic redirection, firmware tampering, or persistence.
Acknowledgements
This vulnerability was discovered by Yassine Damiri. The research helps improve awareness around the security risks posed by weak input validation and serves as a basis for further security improvements.
Disclaimer
This repository is intended for educational and ethical hacking purposes only. Unauthorized access to devices or systems is illegal. Always obtain proper authorization before conducting security testing.
Author
Yassine Damiri
