← Back to Feed CACHED · 2026-10-01 18:51:26 · CACHE_KEY CVE-2026-13313
CVE-2026-13313 · CWE-489 · Disclosed 2026-10-01

An Active Debug Code vulnerability in certain ASUS router models

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Like a master key left under the doormat by the locksmith who forgot to pick it up after installation

Certain ASUS consumer and prosumer routers — running ASUSWRT firmware series 3.0.0.4_386, 3.0.0.4_388, and 3.0.0.6_102 — ship with active debug code (CWE-489) that was never stripped from production builds. An authenticated admin user can send a crafted HTTP request to a hidden CGI endpoint (historically telnetd.cgi or similar internal handlers in ASUSWRT's httpd) that enables the Telnet service with root-level privileges. Affected models span ASUS's popular Wi-Fi 6 lineup including the RT-AX86U/S, RT-AX88U, RT-AX88U Pro, RT-AX86U Pro, RT-AX92U, RT-AC88U, and likely other models on these firmware branches. The vulnerability was disclosed on October 1, 2026 alongside CVE-2026-14157 (CVSS 9.4, format-string RCE via VPN config upload).

The CNA-assigned CVSS 4.0 score of 8.9 is directionally fair but overstates the real-world risk for most enterprise defenders. The vector honestly encodes PR:H (high privileges required) and AC:H (high attack complexity), meaning the attacker already needs valid admin credentials to the router's web management interface — and then must craft a specific request sequence. The "subsequent system" scope (SC:H/SI:H/SA:H) reflects the router's gateway position: a compromised router can intercept traffic, hijack DNS, and pivot to LAN hosts. That scope is real, but the authentication gate significantly narrows the reachable attack surface. In enterprise environments, ASUS routers rarely serve as primary perimeter devices — they appear in home offices, labs, and small branch sites. The combination of high-privilege auth requirement, high attack complexity, zero public PoCs, and zero confirmed in-the-wild exploitation places this firmly at HIGH rather than CRITICAL for most defenders.

"Admin-authed root shell via leftover debug endpoint on ASUS routers — restrict mgmt access now"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Discover target ASUS router

Attacker identifies an ASUS router with an accessible web management interface. On external targets, Shodan/Censys/FOFA queries for ASUSWRT HTTP headers surface ~122,000 routers with exposed HTTP management and ~15,000 with HTTPS. On internal networks, ARP/mDNS scanning or passive traffic analysis reveals the gateway. Tools: Shodan, Censys, FOFA, Nmap.
Conditions required:
  • Network access to the router's management port (TCP 80/443)
  • Target runs ASUSWRT firmware in an affected series
Where this breaks in practice:
  • ASUS routers default to LAN-only management; WAN-side admin must be explicitly enabled by the user
  • Most enterprise perimeters use Cisco/Palo/Fortinet, not ASUS — limits the enterprise-reachable population
Detection/coverage: Shodan/Censys dorks: http.title:"ASUS" http.component:"ASUSWRT". GreyNoise tags for ASUS reconnaissance activity.
STEP 02

Obtain admin credentials

The CVSS vector specifies PR:H — the attacker needs high-privilege (admin) credentials. Attack paths include brute-force against the web login (no account lockout by default on many ASUS models), credential stuffing from prior breaches, or reuse of default credentials (admin/admin on some SKUs). The GreyNoise-documented ViciousTrap campaign (May 2026) demonstrated successful brute-force against ASUS routers at scale, compromising ~9,000 devices. Tools: Hydra, Medusa, credential dumps.
Conditions required:
  • Valid admin username and password for the target router
Where this breaks in practice:
  • Strong, unique admin passwords block this step entirely
  • Enterprise-managed routers should have rotated default credentials
  • Rate limiting or fail2ban (if configured) slows brute-force
Detection/coverage: Failed login attempts visible in router syslog. GreyNoise tags for ASUS brute-force activity.
STEP 03

Send crafted HTTP request to debug endpoint

With admin session cookies, the attacker sends a specially crafted HTTP request to the hidden debug code endpoint left in the production firmware build. Historically, ASUSWRT exposed telnetd.cgi?enable=1 or equivalent internal CGI handlers in the httpd binary that toggle diagnostic services. The CWE-489 classification confirms this is development/maintenance code that was never removed. The AC:H in the CVSS vector suggests the exact request format is not trivial. Tools: curl, custom Python script.
Conditions required:
  • Authenticated admin session (valid session cookie)
  • Knowledge of the debug endpoint URI and required parameters
Where this breaks in practice:
  • No public PoC exists — the exact endpoint and parameter format must be reverse-engineered from the firmware binary
  • The endpoint may vary across firmware builds and model variants
  • AC:H reflects that the trigger conditions are non-obvious
Detection/coverage: HTTP access logs on the router (limited by default). WAF or reverse proxy inspection of management traffic (uncommon for consumer routers).
STEP 04

Telnet service activates with root shell

The debug endpoint enables the Telnet daemon (telnetd) bound to all interfaces, running as root on the underlying BusyBox/Linux OS. The attacker connects via telnet <router_ip> 23 and receives an interactive root shell. No additional authentication is required for the Telnet session once the service is enabled by the debug endpoint. Tools: telnet client, PuTTY.
Conditions required:
  • Network reachability to TCP port 23 on the router
  • Debug endpoint successfully triggered in step 3
Where this breaks in practice:
  • Telnet opening on port 23 is detectable by port scanning and network monitoring
  • An IDS/IPS between the attacker and the router may flag Telnet session initiation
Detection/coverage: Port scan detecting newly opened TCP/23. Nmap service detection. IDS signatures for Telnet session initiation from unexpected sources.
STEP 05

Persistent compromise and lateral movement

With root shell access, the attacker can modify NVRAM to persist across reboots and firmware updates (as demonstrated in ViciousTrap), inject SSH keys for persistent access, disable logging, intercept all network traffic via tcpdump/iptables manipulation, poison DNS responses to redirect clients to attacker infrastructure, or pivot to LAN hosts through the router's trusted gateway position. The blast radius extends to every device routing traffic through this gateway. Tools: BusyBox utilities, iptables, tcpdump, custom implants.
Conditions required:
  • Active root shell from step 4
  • Devices connected behind the compromised router
Where this breaks in practice:
  • Network segmentation behind the router limits lateral movement scope
  • EDR on LAN hosts may detect anomalous traffic patterns from the gateway IP
  • DNS monitoring can catch poisoned responses
Detection/coverage: DNS monitoring for poisoned responses. NetFlow/traffic anomaly detection. Endpoint agents detecting unexpected gateway behavior. NVRAM integrity monitoring (rare).
03 · Compensating Control

1
HIGH 7.5→MEDIUM 5.5
SEVERITY REDUCED
Disable WAN-side remote management immediately — Turn off "Enable Web Access from WAN" in Administration > System on every ASUS router. This eliminates the remote attack vector entirely, limiting exploitation to attackers already on the LAN. Per the noisgate mitigation SLA for HIGH, deploy within 30 days. This is the single highest-impact control — it breaks step 1 of the attack path for all external attackers.
2
HIGH 7.5→MEDIUM 5.0
SEVERITY REDUCED
Rotate all admin credentials to strong, unique passwords — Change every ASUS router admin password to a ≥16-character random string. ASUS defaults (admin/admin) are brute-forced at scale — the ViciousTrap campaign proved this. This breaks the PR:H prerequisite (step 2). Deploy within 30 days per noisgate mitigation SLA. Use a password manager to generate and store credentials.
3
HIGH 7.5→MEDIUM 5.0
SEVERITY REDUCED
Restrict management interface to trusted IPs only — If remote management is operationally required, bind it to a management VLAN or specific IP allowlist via the router's access control settings. This narrows the attack surface to pre-approved hosts only. Deploy within 30 days.
4
HIGH 7.5→HIGH 7.5
Monitor for Telnet port 23 activation on all known ASUS router IPs — Set up automated port scanning (Nmap, Masscan) against known ASUS router IPs on TCP/23. Alert on any newly opened Telnet port as a potential indicator of active exploitation or compromise. This is a detection control, not prevention — it catches step 4 of the attack path after exploitation has occurred. Deploy within 30 days.
5
HIGH 7.5→IGNORE 0.0
SEVERITY REDUCED
Apply vendor firmware patch — Update to the latest firmware from the ASUS Security Advisory. This is the definitive remediation that eliminates the debug code endpoint. Per the noisgate remediation SLA for HIGH, complete patching across all affected routers within 180 days. Check model-specific download pages for post-October-1-2026 builds.
What doesn't work
  • WPA3/Wi-Fi encryption — Protects wireless client traffic, not the router's management HTTP interface. The attack targets the web management plane, not the wireless data path.
  • MAC address filtering — Trivially spoofed and does not restrict access to the web management interface. An attacker with network access bypasses this in seconds.
  • Disabling UPnP — UPnP is a separate attack surface. This CVE targets a debug code endpoint in the management httpd process, not UPnP services.
  • Consumer-grade "firewall" rules on the router itself — The attacker is already authenticated to the management interface with admin privileges. The router's own firewall rules do not restrict authenticated admin actions against its own management plane.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNo confirmed exploitation of CVE-2026-13313 specifically. Not on CISA KEV. However, GreyNoise documented the active ViciousTrap campaign (May 2026) targeting ASUS routers via brute-force + CVE-2023-39780, with ~9,000 confirmed compromises (Censys). The ASUS router ecosystem is under active, sustained threat.
Proof-of-ConceptNone public. Not indexed on pocindex.io. No GitHub repos named CVE-2026-13313. No Nuclei templates, no ExploitDB entries, no Metasploit modules. Checked SecureWithUmer/CVE-2026-PoCs and XZ1r0/cve-2026-poc-collection — neither lists this CVE.
EPSS ScoreNot yet available. FIRST EPSS API returns empty — CVE published October 1, 2026 (1 day ago). Expect initial score within 7–14 days of ingestion.
CISA KEV StatusNot listed. No known due date. Given the authentication requirement and lack of ITW exploitation, KEV listing is unlikely in the near term.
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H — 8.9 HIGH. Network-reachable but requires high-privilege admin auth AND high attack complexity. Subsequent-system impact (all HIGH) reflects the gateway's position controlling traffic for all connected devices. No CVSS 3.1 vector published by NVD or CNA.
Affected VersionsFirmware series 3.0.0.4_386 (older Wi-Fi 5/6 models), 3.0.0.4_388 (RT-AX86U/S, RT-AX88U, RT-AX89X, RT-AX92U, RT-AC88U), 3.0.0.6_102 (Pro models: RT-AX88U Pro, RT-AX86U Pro). Covers ASUS's most popular consumer/prosumer Wi-Fi 6 router lineup.
Fixed VersionsASUS states patches available via Security Advisory. Specific patched build numbers not publicly documented. Latest known builds: 3.0.0.6.102_37485 (RT-AX88U Pro, 2026-09-22), 3.0.0.4.388_24436 (RT-AX86U). Check model-specific download pages for post-October-1 builds.
Internet Exposure~122,000 ASUS routers with exposed HTTP management interface per Shodan. ~15,000 with HTTPS exposed. ~9,000 already compromised in ViciousTrap campaign per Censys (May 2026).
Disclosure Date2026-10-01. CVE reserved 2026-06-25. Disclosed alongside CVE-2026-14157 (CVSS 9.4, format string) and CVE-2026-93495 (CVSS 7.0).
Reporting ResearcherNot publicly credited. ASUS advisory does not name the reporter. No independent write-ups or blog posts from researchers identified.

Sources.

  1. ASUS Security Advisory
  2. CVE-2026-13313 — Strix.ai
  3. CVE-2026-13313 — ThreatInt CVE Record
  4. CVE-2026-13313 — Threat Radar / Offseq
  5. ASUS Security Vulnerabilities — SecurityOnline
  6. GreyNoise: Stealthy Backdoor Campaign Affecting ASUS Routers
  7. Nearly 150,000 ASUS Routers Potentially Exposed — Cybersecurity Dive
  8. CVE-2026-14157 Companion CVE — Strix.ai
05 · The Call

Final Verdict
= UNCHANGED to HIGH (7.5/10)

Why this verdict

  • Network edge appliance floor: ASUS routers are network edge devices by definition — 100% of installs sit at the gateway position. Compromise yields root on the device that routes all LAN traffic, enabling DNS hijacking, traffic interception, and lateral pivot to every connected host. Per the deployment-role blast radius rule, the network-edge role sets a floor of HIGH.
  • PR:H narrows the reachable population: The attacker must already possess valid admin credentials to the router's web interface. This is not an unauthenticated RCE — it's an escalation from "web admin" to "root shell." The delta is meaningful (persistent backdoor, firmware modification, kernel-level traffic interception) but the authentication gate is real and substantial. Adjusting −0.5 from the CNA 8.9 baseline.
  • AC:H with zero public PoCs further constrains exploitation: The specific HTTP request to trigger the debug endpoint is non-trivial, no public PoC exists on GitHub/ExploitDB/Nuclei/Metasploit, and the endpoint may vary across firmware builds. The 1-day-old disclosure means patch-diffing is still in progress. Adjusting −0.5.
  • Zero in-the-wild exploitation confirmed: No CISA KEV listing, no GreyNoise/Censys scanning data specific to this CVE, no threat intel reports. The ViciousTrap campaign targets ASUS routers but uses different CVEs (CVE-2023-39780). Adjusting −0.4.
  • Role multiplier: (a) *Home/lab router:* LOW blast radius — single user or small household behind the gateway. (b) *SOHO/small branch:* MEDIUM — a handful of corporate hosts, limited data exposure. (c) *Network edge appliance (high-value):* Chain succeeds (admin creds → crafted request → root shell); blast radius is network-segment-scale (all traffic routed through gateway). However, ASUS consumer routers are not canonical enterprise perimeter devices — those are Cisco ASA, Palo PAN-OS, FortiGate where ≥10% of installs protect enterprise networks. Estimated <5% of ASUS router installs protect enterprise-grade assets. The floor remains HIGH; it does not reach CRITICAL because ASUS is not a canonical high-value-role edge appliance.
  • Ecosystem threat context provides upward pressure: ~122K exposed management interfaces (Shodan), ~9K confirmed compromised ASUS routers (GreyNoise/Censys), and the ViciousTrap campaign prove this ecosystem is actively hunted. Once a PoC drops, exploitation will accelerate. This prevents any consideration of downgrading below HIGH.

Why not higher?

The PR:H requirement means the attacker has already breached the management plane — they possess admin credentials. The CVE adds root shell access, which is a meaningful escalation, but not an unauthenticated entry point. ASUS consumer/prosumer routers are not canonical enterprise perimeter devices; estimated <5% of the installed base protects high-value enterprise networks per market share data (enterprise edge is dominated by Cisco, Palo Alto, Fortinet). Attack complexity is HIGH with zero public PoCs, and there is zero confirmed in-the-wild exploitation of this specific CVE.

Why not lower?

The network-edge appliance role sets a hard floor at HIGH. A compromised router means root on the gateway — traffic interception, DNS hijacking, and lateral pivot to every device behind it. The blast radius is network-segment-scale, not host-scale. The GreyNoise data proves the ASUS ecosystem is actively targeted at scale, and ~122,000 management interfaces are internet-exposed. Even with the authentication gate, the consequence of successful exploitation is too severe for MEDIUM.

06 · Verification

Crowdsourced verification payload.

Run from an auditor workstation with network access to the ASUS router's management interface (TCP 80 or 443). Requires curl and nc (netcat). No root/sudo needed on the auditor host. Invocation: bash check_cve_2026_13313.sh 192.168.1.1 admin 'MyP@ssw0rd'. If credentials are omitted, only the Telnet port compromise-indicator check runs.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-13313 — ASUS Router Active Debug Code Checker
# Checks: (1) Telnet port 23 status (compromise indicator)
#         (2) Firmware version against affected series
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -uo pipefail

ROUTER_IP="${1:-}"
ADMIN_USER="${2:-admin}"
ADMIN_PASS="${3:-}"

if [[ -z "$ROUTER_IP" ]]; then
    echo "Usage: $0 <router_ip> [admin_user] [admin_password]"
    echo "UNKNOWN - missing router IP"
    exit 2
fi

VULN=0
COOKIE_FILE=$(mktemp /tmp/asus_cookie.XXXXXX)
trap "rm -f $COOKIE_FILE" EXIT

# --- Check 1: Telnet port indicator (compromise detection) ---
echo "[*] Checking Telnet port 23 on $ROUTER_IP ..."
if nc -z -w3 "$ROUTER_IP" 23 2>/dev/null; then
    echo "[!] WARNING: Telnet port 23 is OPEN — debug code may be active or device compromised"
    VULN=1
else
    echo "[+] Telnet port 23 is closed (expected)"
fi

# --- Check 2: Firmware version via ASUSWRT web API ---
if [[ -n "$ADMIN_PASS" ]]; then
    echo "[*] Authenticating to web management on $ROUTER_IP ..."
    AUTH_TOKEN=$(echo -n "${ADMIN_USER}:${ADMIN_PASS}" | base64)
    PROTO="https"

    LOGIN_RESP=$(curl -sk -c "$COOKIE_FILE" \
        "${PROTO}://${ROUTER_IP}/login.cgi" \
        -d "login_authorization=${AUTH_TOKEN}" \
        --connect-timeout 10 --max-time 15 2>/dev/null)

    # Fallback to HTTP if HTTPS fails
    if [[ -z "$LOGIN_RESP" ]]; then
        PROTO="http"
        LOGIN_RESP=$(curl -sk -c "$COOKIE_FILE" \
            "${PROTO}://${ROUTER_IP}/login.cgi" \
            -d "login_authorization=${AUTH_TOKEN}" \
            --connect-timeout 10 --max-time 15 2>/dev/null)
    fi

    if [[ -z "$LOGIN_RESP" ]]; then
        echo "[!] Could not connect to router web interface"
        if [[ $VULN -eq 1 ]]; then
            echo "VULNERABLE - Telnet port open (firmware check inconclusive)"
            exit 1
        fi
        echo "UNKNOWN - could not connect; provide correct IP and credentials"
        exit 2
    fi

    # Query firmware version via appGet API
    FW_RESP=$(curl -sk -b "$COOKIE_FILE" \
        "${PROTO}://${ROUTER_IP}/appGet.cgi" \
        -d 'hook=nvram_get(firmver)%3Bnvram_get(buildno)%3Bnvram_get(extendno)%3Bnvram_get(model)' \
        --connect-timeout 10 --max-time 15 2>/dev/null)

    FIRMVER=$(echo "$FW_RESP" | grep -oP '"firmver"\s*:\s*"\K[^"]+' 2>/dev/null || echo "")
    BUILDNO=$(echo "$FW_RESP" | grep -oP '"buildno"\s*:\s*"\K[^"]+' 2>/dev/null || echo "")
    MODEL=$(echo "$FW_RESP" | grep -oP '"model"\s*:\s*"\K[^"]+' 2>/dev/null || echo "unknown")

    if [[ -n "$FIRMVER" && -n "$BUILDNO" ]]; then
        FULL_VER="${FIRMVER}_${BUILDNO}"
        echo "[*] Model: $MODEL | Firmware: $FULL_VER"

        # Affected series: 3.0.0.4_386*, 3.0.0.4_388*, 3.0.0.6_102*
        if [[ "$FULL_VER" =~ ^3\.0\.0\.4_386 ]] || \
           [[ "$FULL_VER" =~ ^3\.0\.0\.4_388 ]] || \
           [[ "$FULL_VER" =~ ^3\.0\.0\.6_102 ]]; then
            echo "VULNERABLE - firmware $FULL_VER on $MODEL is in affected series (CVE-2026-13313)"
            echo "[!] Update firmware: https://www.asus.com/security-advisory"
            exit 1
        else
            if [[ $VULN -eq 1 ]]; then
                echo "VULNERABLE - Telnet port open despite firmware outside known-affected series (investigate)"
                exit 1
            fi
            echo "PATCHED - firmware $FULL_VER is not in the affected series"
            exit 0
        fi
    else
        echo "[!] Could not parse firmware version from API response"
    fi
else
    echo "[*] No credentials provided — skipping firmware version check"
fi

# Final determination
if [[ $VULN -eq 1 ]]; then
    echo "VULNERABLE - Telnet port 23 is open (possible active exploitation)"
    exit 1
fi

echo "UNKNOWN - provide admin credentials for firmware version check"
exit 2
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously