Abandon Ship: Critical Flaws in EOL PUSR USR-W610 Routers Expose Industrial Networks

In the world of Operational Technology (OT) and Industrial Control Systems (ICS), "if it isn't broke, don't fix it" is a dangerous mantra. This week, CISA released a sobering advisory regarding Jinan USR IOT Technology Limited (PUSR) USR-W610 Wi-Fi routers that turns this philosophy into a critical liability.

The devices, widely deployed in Critical Manufacturing sectors worldwide, suffer from a cluster of severe vulnerabilities (CVE-2026-25715, CVE-2026-24455, CVE-2026-26049, CVE-2026-26048). The most damning detail? The vendor has declared the product End-of-Life (EOL) and stated there are no plans to patch.

With a CVSS score of 9.8, these aren't just bugs; they are open doors for attackers to walk right into your industrial network.

The Vulnerability Breakdown

The USR-W610 is a serial-to-Ethernet/Wi-Fi device often used to bridge legacy industrial equipment. The identified vulnerabilities allow attackers to bypass authentication entirely, steal credentials, or disrupt operations.

1. The "Blank Check" Vulnerability (CVE-2026-25715)

CVSS 9.8 (CRITICAL)

This is the crown jewel of the exploit chain. The web management interface allows the administrator username and password to be set to blank values. Once configured this way, the device accepts authentication with empty credentials via both the web interface and the Telnet service.

Impact: An attacker on the adjacent network can gain full administrative control without a single credential.

2. Cleartext Credential Theft (CVE-2026-24455)

CVSS 7.5 (HIGH)

The device does not support HTTPS/TLS. It relies on HTTP Basic Authentication, which transmits credentials in Base64 encoding—easily reversible to plaintext.

Impact: Anyone passively sniffing the network can harvest administrator credentials.

3. Visual Credential Leakage (CVE-2026-26049)

CVSS 5.7 (MEDIUM)

The web interface renders passwords in plaintext input fields rather than masked asterisks.

Impact: "Shoulder surfing," screen recording malware, or even browser caches can reveal admin passwords to unauthorized observers.

4. Wireless Denial-of-Service (CVE-2026-26048)

CVSS 7.5 (HIGH)

The router lacks Management Frame Protection (802.11w), making it susceptible to de-authentication attacks.

Impact: Attackers can forge management frames to disconnect devices, causing operational downtime.

The EOL Dilemma

The vendor, Jinan USR IOT Technology, has washed their hands of these devices, stating they will not be patched. For security teams, this changes the remediation strategy from "Patch Management" to "Asset Replacement and Isolation."

Detection & Threat Hunting

Since the vendor provides no fix, detection of active compromise or exposure is your immediate priority. Below are methods to identify these devices and detect attack attempts.

1. Identifying the Device (KQL)

Use this query in Microsoft Sentinel or Defender to identify the specific USR-W610 devices on your network by looking for common HTTP request patterns or DHCP fingerprints if available.

DeviceNetworkEvents

| where Timestamp > ago(7d)
| where RemotePort in (80, 23, 443) // Web and Telnet ports
| extend DeviceModel = iff(DeviceName contains "USR" or DeviceName contains "PUSR", "Potential USR Device", "Other")
| where DeviceModel == "Potential USR Device"
| project Timestamp, DeviceName, IPAddress, RemotePort, InitiatingProcessFileName
| summarize count() by DeviceName, IPAddress

2. Detecting Cleartext Auth Usage (KQL)

This query looks for HTTP Basic Auth headers, which indicate the use of the vulnerable cleartext transmission mechanism (CVE-2026-24455).

DeviceNetworkEvents

| where Timestamp > ago(1d)
| where RemotePort == 80
| where NetworkProtocol == "HTTP"
| where AdditionalFields has "Authorization: Basic"
| project Timestamp, SourceDevice, DestinationDevice, DestinationIPAddress, InitiatingProcessFileName

| limit 100

3. Scanning for Blank Auth Vulnerability (Bash)

For internal red teaming or authorized scanning, use curl to test if the target USR-W610 allows authentication with blank credentials.

Note: Only run this on assets you own or have explicit permission to test.

#!/bin/bash
# Target IP address
TARGET="192.168.1.100"

# Test Web Interface for Blank Auth (CVE-2026-25715)
echo "[*] Testing for blank authentication on Web Interface..."
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" --digest -u "" "http://$TARGET/login_check.php") 

# Adjust the endpoint based on specific firmware behavior. 
# A 200 OK usually indicates bypass success on vulnerable devices.
if [ "$HTTP_CODE" -eq 200 ]; then
    echo "[!] VULNERABLE: Device accepted blank credentials via HTTP."
else
    echo "[+] SAFE: Device rejected blank credentials or endpoint changed."
fi

4. Detecting De-Authentication Floods (Python)

While this requires a Wireless Intrusion Detection System (WIDS) environment, the following logic analyzes packet captures (pcap) for a high volume of de-auth frames targeting specific BSSIDs, indicating a potential CVE-2026-26048 attack.

from scapy.all import *


def detect_deauth_flood(pcap_file, threshold=50):

    """
    Analyzes a PCAP file for signs of De-Authentication flood attacks.
    """
    packets = rdpcap(pcap_file)
    deauth_counts = {}
    
    for pkt in packets:
        if pkt.haslayer(Dot11Deauth):
            # Identify the target AP via BSSID
            bssid = pkt.addr1 
            if bssid in deauth_counts:
                deauth_counts[bssid] += 1
            else:
                deauth_counts[bssid] = 1
    
    print("\nDe-Authentication Analysis:")
    for bssid, count in deauth_counts.items():
        if count > threshold:
            print(f"[ALERT] High volume of De-Auth frames ({count}) detected for BSSID: {bssid}")
        else:
            print(f"[INFO] Normal activity ({count} frames) for BSSID: {bssid}")

# Usage: detect_deauth_flood('capture.pcap')

Mitigation Strategy

Since patching is not an option, "Defense in Depth" is your only viable path. CISA recommends the following:

1. Isolate Immediately: Move all USR-W610 devices behind a firewall and strictly segregate them from the business network. They should be in their own VLAN with zero trust policies applied.
2. Disable Internet Access: Ensure these devices cannot route traffic to the public internet. Their function is usually local bridging; they require no outbound WAN access.
3. Replace Hardware: Prioritize the replacement of these devices with modern, supported alternatives that support encryption (TLS/SSH) and secure password enforcement.
4. Monitor for Telnet: If possible, disable the Telnet service (if accessible via console) and block port 23 at the network switch level.

Conclusion

The USR-W610 vulnerabilities serve as a stark reminder of the debt incurred by "run-to-failure" hardware strategies in critical infrastructure. When a vendor declares EOL, that device becomes a ticking time bomb. If you have these devices on your network, the time to isolate or replace them was yesterday.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub