Zbtlink router firmware ships an embedded remote-control implant

CVE-2026-66747 is not a software bug — it is a CWE-506 embedded malicious code finding. Every published firmware build across 20+ Zbtlink and Wiflyer router models (CPE2801, WE1026-5G-WD, WE1326, WE2007, WE2008-DSIM, WE2416, WE3326, WE5927, WE5931, WE5931AC, WE826-T3-DSIM, WG108, WG1602, WG1608-DSIM, WG209, WG2105, WG2107, WG259, WG3526, Z8102AX-2DSIM) ships with the ENDLESSDOORS implant baked in. The implant beacons outbound to a Chinese-registered domain and a hardcoded IP every 35 seconds. Whoever controls that infrastructure gets full remote control of the router and can pivot to every device on the LAN. VulnCheck estimates ~100,000 units deployed worldwide in homes, small businesses, and offices.

The vendor CVSS of 9.8 CRITICAL is entirely justified — arguably understated given the supply-chain nature of this finding. A traditional CVE implies a fixable flaw; here there is no legitimate firmware to patch *to* because the implant is present in every known build. Zbtlink has not responded to disclosure. The only remediation is physical replacement of the device. For any enterprise with even one of these routers in a branch, home-office, or OT edge deployment, the network behind it should be considered fully compromised from the moment it was powered on.

Why this verdict

• Supply-chain implant, not a bug. CWE-506 means the malicious code is intentional. There is no 'vulnerable version' vs. 'fixed version' — every unit ever sold is compromised. This eliminates the normal 'patch it' remediation path entirely.
• Network-edge role = perimeter is the blast radius. Zbtlink routers are deployed as the network edge device. The affected component IS the perimeter firewall/gateway. Compromise of this device means the attacker owns the network boundary and can intercept, modify, or redirect all traffic traversing it.
• Outbound beacon bypasses NAT and most perimeter controls. The 35-second outbound C2 beacon means the implant works even when the router is behind another NAT device or in a double-NAT SOHO configuration. The attacker doesn't need to reach the device — the device reaches the attacker.
• Role multiplier: The affected component is a network edge appliance. While Zbtlink is SOHO-grade (not enterprise Palo/Fortinet class), it occupies the identical architectural role: it IS the firewall, the NAT gateway, the DNS forwarder. In deployments where it serves as the sole perimeter device — branch offices, remote worker homes, OT/ICS edge sites — the blast radius is full network compromise of that site. For OT deployments using cheap LTE routers (a common pattern), this extends to operational/safety impact. The network-edge role is the canonical deployment for 100% of these devices, making the verdict floor CRITICAL.
• No vendor response, no remediation path. Zbtlink has not acknowledged the disclosure. There is no clean firmware to update to. The only option is hardware replacement, which raises the operational urgency significantly.

Why not higher?

CVSS 9.8 is already near-ceiling. The Scope metric is Unchanged (S:U) rather than Changed (S:C) which would push to 10.0, but in practice the LAN pivot capability means downstream impact extends beyond the vulnerable component. The score could arguably be 10.0 but the formal vector as published is accurate.

Why not lower?

Downgrading would require evidence that the implant is inert, that the C2 infrastructure is defunct, or that the enterprise installed base is negligible. None of these conditions are met: the beacon is active by design in every unit, the C2 domains are registered and presumably operational, and VulnCheck estimates 100,000 deployed devices. Even a single unit in a branch office or remote worker's home network creates a persistent, undetectable (without DNS monitoring) entry point into the enterprise. The CWE-506 classification (deliberate malicious code) also categorically resists downgrade — this is not an accidental bug with mitigating factors, it is an intentional implant.

1. Inventory all Zbtlink and Wiflyer hardware immediately — You cannot mitigate what you cannot find. Query asset inventories, DHCP logs, and MAC OUI tables for Zbtlink OUIs (manufacturer: Shenzhen Zhibotong Electronics). Check procurement records for any of the 20 affected model numbers. Per noisgate mitigation SLA for CRITICAL: complete within 3 days.
2. Physically disconnect and replace affected routers — There is no firmware fix. The only remediation is hardware replacement with a non-Zbtlink device. For branch offices, ship replacement routers overnight. For remote workers, provide a replacement unit and instructions. Per noisgate mitigation SLA for CRITICAL: begin replacements within 3 days.
3. DNS-sinkhole the known C2 domain at your recursive resolver — Block outbound resolution of the C2 domain used by ENDLESSDOORS at your enterprise DNS layer (Umbrella, Infoblox, Pi-hole, etc.). This disrupts the beacon but does NOT eliminate the implant — the hardcoded IP fallback may still work. Deploy within 24 hours as a stopgap.
4. Block the hardcoded C2 IP at your egress firewall — If VulnCheck or your own analysis identifies the C2 IP, add it to your egress deny list. This plus DNS sinkholing together sever both beacon paths. Deploy within 24 hours.
5. Segment networks behind affected routers — If immediate replacement is impossible, ensure the LAN behind the Zbtlink device is treated as an untrusted zone. Route traffic through a VPN concentrator and apply zero-trust network access policies. Do not allow direct LAN access to sensitive resources.
6. Monitor for lateral movement from gateway subnets — Configure EDR and SIEM alerts for anomalous traffic originating from the default gateway IP of any network segment using a Zbtlink router. Look for ARP spoofing, DNS hijacking, and unexpected routing changes.

Run this script from any Linux/macOS host on the same network as the suspected Zbtlink router, or from a management workstation with access to your DHCP/ARP tables. No special privileges required unless using arp-scan (which needs root). Example: sudo bash check_zbtlink.sh 192.168.1.1

#!/usr/bin/env bash
# check_zbtlink.sh — Detect Zbtlink/Wiflyer routers via OUI and HTTP fingerprint
# Usage: sudo bash check_zbtlink.sh [GATEWAY_IP]
# Exit codes: 0 = VULNERABLE (Zbtlink device detected)
#             1 = PATCHED (not applicable — means NOT DETECTED)
#             2 = UNKNOWN (insufficient data)

set -euo pipefail

GATEWAY="${1:-$(ip route show default 2>/dev/null | awk '/default/ {print $3}' | head -1)}"

if [ -z "$GATEWAY" ]; then
  echo "UNKNOWN — could not determine default gateway. Provide IP as argument."
  exit 2
fi

echo "[*] Checking gateway: $GATEWAY"

# Known Zbtlink/Wiflyer OUI prefixes (Shenzhen Zhibotong Electronics)
# These are commonly associated OUIs; verify against current IEEE database
ZBT_OUIS="00:0C:43|44:D1:FA|E4:95:6E|7C:A1:77"

# Step 1: Check MAC address via ARP
MAC=$(arp -n "$GATEWAY" 2>/dev/null | grep -oE '([0-9A-Fa-f]{2}:){5}[0-9A-Fa-f]{2}' | head -1)
if [ -z "$MAC" ]; then
  # Try ip neigh
  MAC=$(ip neigh show "$GATEWAY" 2>/dev/null | grep -oE '([0-9A-Fa-f]{2}:){5}[0-9A-Fa-f]{2}' | head -1)
fi

OUI_MATCH=false
if [ -n "$MAC" ]; then
  echo "[*] Gateway MAC: $MAC"
  if echo "$MAC" | grep -qiE "$ZBT_OUIS"; then
    OUI_MATCH=true
    echo "[!] MAC OUI matches known Zbtlink/Wiflyer manufacturer"
  fi
else
  echo "[?] Could not resolve MAC for $GATEWAY"
fi

# Step 2: HTTP fingerprint — Zbtlink routers typically serve a login page with identifiable strings
HTTP_MATCH=false
if command -v curl &>/dev/null; then
  BODY=$(curl -sk --connect-timeout 5 --max-time 10 "http://$GATEWAY/" 2>/dev/null || true)
  if echo "$BODY" | grep -qiE 'zbtlink|wiflyer|zbt_|Zhibotong'; then
    HTTP_MATCH=true
    echo "[!] HTTP response contains Zbtlink/Wiflyer branding"
  fi
fi

# Step 3: Check for known model strings in HTTP response
MODEL_MATCH=false
MODELS="CPE2801|WE1026|WE1326|WE2007|WE2008|WE2416|WE3326|WE5927|WE5931|WE826|WG108|WG1602|WG1608|WG209|WG2105|WG2107|WG259|WG3526|Z8102AX"
if [ -n "${BODY:-}" ]; then
  if echo "$BODY" | grep -qiE "$MODELS"; then
    MODEL_MATCH=true
    DETECTED_MODEL=$(echo "$BODY" | grep -oiE "$MODELS" | head -1)
    echo "[!] Detected affected model: $DETECTED_MODEL"
  fi
fi

# Verdict
if $OUI_MATCH || $HTTP_MATCH || $MODEL_MATCH; then
  echo ""
  echo "VULNERABLE — Zbtlink/Wiflyer router detected at $GATEWAY."
  echo "ALL firmware builds contain the ENDLESSDOORS implant (CVE-2026-66747)."
  echo "ACTION: Replace this device immediately. There is no firmware fix."
  exit 0
else
  echo ""
  echo "PATCHED — No Zbtlink/Wiflyer indicators found at $GATEWAY."
  echo "Note: This does not rule out Zbtlink devices elsewhere on the network."
  echo "Run a full OUI scan: arp-scan -l | grep -iE 'zbt|zhibotong|wiflyer'"
  exit 1
fi

Sources

1. Cybernews — Chinese-made Zbtlink routers have a backdoor
2. Reuters via Yahoo — Chinese-made Zbtlink routers have backdoor
3. The Epoch Times — Researcher Finds Backdoor in Chinese-Made Routers Sold Worldwide
4. SRN News — Chinese-made Zbtlink routers have backdoor
5. VulnCheck Blog
6. MITRE CWE-506: Embedded Malicious Code
7. Zbtlink Official Site