← Back to Feed CACHED · 2026-10-08 01:38:00 · CACHE_KEY CVE-2026-74232
CVE-2026-74232 · CWE-300 · Disclosed 2026-08-27

Zbtlink MQWrt yunmgrd (SPEAKINGSTONE) Factory-Installed Cloud C2 Implant

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

Like buying a cheap padlock that mails a copy of your key to the locksmith in Shenzhen every 35 seconds

CVE-2026-74232, codenamed SPEAKINGSTONE by VulnCheck, is a factory-installed command-and-control implant embedded in the firmware of budget routers manufactured by Shenzhen Zhibotong Electronics (trading as Zbtlink, ZBT, ZBTWiFi, and Wiflyer). The implant runs as a service called yunmgrd and beacons outbound every ~35 seconds on UDP port 10000 to a hardcoded C2 domain (ac-link[.]com, hosted on Alibaba Cloud in Shenzhen). The unauthenticated, cleartext protocol supports root command execution (msgType 0x2507), PPPoE credential exfiltration (0x2502), DNS hijack list writes (0x230b), and reverse SSH tunnel creation (0x2405). Affected firmware spans at least 15 models including Zbtlink L3_V2_8 (3.0.0.4.528), WE826-T2 (19.1101), ZBT-7628 (1.0.0.2.007), ZBT-ZBT7621 (1.0.0.3.001), and multiple MoreQuick MQAC/MQAP variants (1.0.0.2.000). The underlying rctl source code was uploaded to GitHub in January 2015, meaning the implant has been shipping for over a decade.

The vendor's CVSS 3.1 score of 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) significantly overstates the real-world exploitability of *this specific CVE*. SPEAKINGSTONE is an outbound-only beacon — it never accepts inbound connections. An attacker cannot simply fire packets at the router; they must either sit on the network path between the device and the C2 server (ISP-level MITM — nation-state territory), compromise/register the C2 domain infrastructure, or perform DNS or BGP hijacking of the C2 destination. VulnCheck demonstrated the domain-registration attack vector by sinkholing a forgotten backup domain (findmyipaddr[.]com), which captured 392 beacons — 390 from China Mobile carrier CPE deployments. This is emphatically not the same threat model as a listening socket on the WAN. The companion CVE-2026-74233 (DARKLANTERN) — which *does* listen inbound on UDP 9992 — is the genuinely critical remote exploit. For enterprise teams managing 10,000+ hosts, the probability of having Zbtlink hardware in the fleet approaches zero, and the attack chain for CVE-2026-74232 is dramatically harder than the CVSS vector suggests.

"Factory C2 implant in budget Chinese routers — terrifying if you own one, irrelevant to most enterprises"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Target runs affected Zbtlink firmware

The router must be one of the 15+ affected models shipping yunmgrd. The implant is baked into every firmware image Zbtlink published; there is no configuration that disables it. VulnCheck confirmed its presence in all 21 firmware images available from the vendor at disclosure. The router is already beaconing to ac-link[.]com on UDP 10000 as soon as it boots.
Conditions required:
  • Victim network includes a Zbtlink, ZBT, ZBTWiFi, Wiflyer, or MoreQuick router with stock firmware
Where this breaks in practice:
  • These are budget Chinese OEM routers sold on Amazon/Alibaba — near-zero Western enterprise deployment
  • Sinkhole data showed 363/392 devices were China Mobile carrier CPE (model L3_V2_8)
  • Enterprise procurement controls and approved hardware lists would exclude these devices
  • OEM/ODM white-labeling creates a small tail risk of unrecognized rebranded devices
Detection/coverage: Suricata rule available from VulnCheck: alert on DNS queries for www.ac-link.com or www.findmyipaddr.com. YARA rule matches yunmgrd binary strings (zbtProtocol.c, yunclient.conf, dnshack). Egress firewall logs showing UDP 10000 to 47.107.224.89 are a definitive indicator.
STEP 02

Attacker gains network-path position

Because SPEAKINGSTONE only beacons *outbound*, the attacker cannot send commands directly to the router. They must position themselves on the network path between the router and the C2 server — either via ISP-level traffic interception (nation-state capability), by compromising or taking over the C2 domain/IP, by registering an expired backup domain, or by DNS/BGP hijacking the C2 destination. VulnCheck demonstrated the backup-domain vector by registering findmyipaddr[.]com, but this domain is now sinkholed. The primary C2 (ac-link[.]com) remains active under vendor control.
Conditions required:
  • Network-path positioning between target router and C2 (ISP MITM, domain takeover, DNS hijack, or BGP hijack)
Where this breaks in practice:
  • ISP-level MITM requires nation-state resources
  • Primary C2 domain is active on Alibaba Cloud — not expired or lapsed
  • VulnCheck already sinkholed the known backup domain
  • BGP hijacking of a specific Alibaba Cloud IP is not a commodity attack
  • LAN-based interception requires the attacker to already be inside the network (post-initial-access)
Detection/coverage: NetFlow or DNS monitoring for resolution of ac-link.com or findmyipaddr.com to unexpected IPs. BGP route anomaly detection for prefix 47.107.224.0/24.
STEP 03

Craft and inject C2 commands over cleartext UDP

Once on-path, the attacker crafts UDP packets matching SPEAKINGSTONE's message format. Inbound commands are entirely unauthenticated and unencrypted — no session token, no challenge-response, no integrity check. The attacker sends msgType 0x2507 (cmdRun) with an arbitrary shell command payload, which the router executes as root. No special tooling required beyond packet crafting with scapy or netcat. VulnCheck's advisory documents the full message type table.
Conditions required:
  • Knowledge of the SPEAKINGSTONE protocol (publicly documented by VulnCheck)
  • Active network-path position from Step 2
Where this breaks in practice:
  • None — once positioned, exploitation is trivial
Detection/coverage: IDS/IPS inspection of UDP port 10000 traffic for SPEAKINGSTONE message types. Deep packet inspection for XOR-obfuscated beacons (key 0x1f).
STEP 04

Root-level compromise of the router

The attacker now has an interactive root shell on the router. Documented capabilities include: arbitrary command execution, WAN PPPoE credential exfiltration (ISP username/password via msgType 0x2502), DNS hijack list manipulation (redirect any domain via msgType 0x230b triggering /usr/sbin/dns.sh), and reverse SSH tunnel creation (msgType 0x2405) for persistent C2 independent of the original implant channel. A compromised router can MitM all LAN traffic, pivot into the internal network, and tamper with DNS resolution for all connected clients.
Conditions required:
  • Successful command injection from Step 3
Where this breaks in practice:
  • Impact is limited to the single compromised router and its directly-connected LAN clients
  • Lateral movement from a budget SOHO router into an enterprise domain is not straightforward
Detection/coverage: Host-based detection is impractical on embedded devices. Network-side detection: watch for unexpected reverse SSH tunnels originating from the router's WAN IP, DNS responses from the router that differ from expected authoritative answers.
03 · Compensating Control

1
MEDIUM 5.5→IGNORE 0.0
SEVERITY REDUCED
Inventory and remove all Zbtlink/ZBT/MoreQuick hardware — Search asset inventory, DHCP logs, and switch MAC tables for OUIs associated with Shenzhen Zhibotong Electronics (OUI prefixes include 44:D1:FA, E4:95:6E, and others — check IEEE OUI database for 'Zhibotong'). Any discovered device should be treated as compromised and removed from the network immediately. Replace with enterprise-grade equipment from an approved vendor. Per the noisgate remediation SLA for MEDIUM, complete within 365 days — but given CWE-506, prioritize removal within 30 days for any device found.
2
MEDIUM 5.5→LOW 3.0
SEVERITY REDUCED
Block outbound UDP 10000 to ac-link.com (47.107.224.89) and findmyipaddr.com at the perimeter firewall — If you cannot immediately remove the device, blocking the C2 egress channel prevents the implant from receiving commands and from exfiltrating device fingerprints. Add DNS sinkhole rules for ac-link.com and findmyipaddr.com. This breaks the command channel but does NOT remove the implant — the device still has embedded malicious code and could beacon via alternative paths if firmware is updated. No mitigation SLA applies for MEDIUM severity — go straight to the 365-day remediation window.
3
MEDIUM 5.5→MEDIUM 5.5
Deploy Suricata/Snort detection rules for SPEAKINGSTONE beacons — VulnCheck published Suricata rules detecting DNS queries for the C2 domains and YARA rules matching the yunmgrd binary. Deploy these to your IDS/IPS to detect any unknown instances beaconing from your network. This is detection, not prevention — it finds devices you didn't know about. Alert on any hit and treat as a compromised host.
4
MEDIUM 5.5→MEDIUM 4.5
Audit OEM/ODM supply chain for white-labeled ZBT hardware — Zbtlink sells OEM/ODM services and will build and rebrand hardware for any buyer. Check with your network equipment vendors — especially any low-cost 4G/LTE gateways, IoT gateways, or branch-office routers purchased from lesser-known brands — to confirm they do not use Zbtlink/MQWrt firmware. Request firmware SBOMs or binary hashes for comparison against VulnCheck's published indicators.
What doesn't work
  • Firmware patching — No patch exists, and VulnCheck argues that patching an intentionally-shipped implant is not meaningful remediation. Even if Zbtlink releases 'secured' firmware, trust in the vendor is fundamentally broken.
  • WAF or IPS on the LAN side — The C2 channel is outbound UDP from the router itself, not traffic passing through the router. LAN-side security tools cannot intercept or block the router's own management-plane traffic.
  • VPN tunneling all traffic — A VPN on client devices protects client traffic from DNS hijacking by the router, but does not prevent the router from beaconing to C2 or executing attacker commands. The implant operates at the router OS level, independent of forwarded traffic.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNo confirmed exploitation in the wild. VulnCheck demonstrated the backup-domain takeover as a proof-of-concept sinkhole operation. The primary C2 channel (ac-link[.]com) is operated by the vendor — the question is whether you consider the vendor's own access to be hostile. Not listed in CISA KEV.
Proof-of-conceptAvailable — partial. VulnCheck published the full SPEAKINGSTONE protocol specification including message types, XOR key, and C2 domain details. Their sinkhole of findmyipaddr[.]com is a demonstrated PoC for the domain-takeover vector. No standalone exploit script published on GitHub or ExploitDB as of this assessment. Suricata detection rules and YARA signature published by VulnCheck. Researcher: Jacob Baines (VulnCheck).
EPSS0.00814 (0.81%), 55.2nd percentile — below the exploitation-likely threshold. Consistent with a niche embedded device CVE that lacks a simple remote trigger.
KEV statusNot listed. The companion CVE-2026-74233 (DARKLANTERN) was flagged by VulnCheck's own KEV catalog but CISA has not added either CVE.
CVSS vector interpretationCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — This vector is misleading for SPEAKINGSTONE. AV:N/AC:L implies any network attacker can trivially exploit it. In reality, the outbound-only beacon design requires network-path positioning (functionally AC:H). The companion DARKLANTERN (CVE-2026-74233) genuinely matches this vector since it listens inbound.
Affected version rangesZbtlink L3_V2_8 fw 3.0.0.4.528, WE826-T2 fw 19.1101, ZBT-7628 fw 1.0.0.2.007, ZBT-ZBT7621 fw 1.0.0.3.001, MoreQuick MQAC-7620/MQAC-7620A/MQAP-7620 fw 1.0.0.2.000, plus AP522, HC5661A, MAP-N10, and others. Present in all 21 firmware images tested by VulnCheck, dating back to 2019.
Fixed versionsNone. No patched firmware exists. Zbtlink paused firmware downloads and claims to be developing "secured patched firmware" but has released nothing. VulnCheck's position is that patching a deliberately-shipped implant is not meaningful remediation — device replacement is recommended.
Internet exposureVulnCheck sinkholed the backup C2 domain and observed 392 unique devices beaconing between Aug 18-21, 2026 — 390 in China (83% on China Mobile). 363 were identical L3_V2_8 carrier CPE units. For DARKLANTERN (companion CVE), Censys/Shodan probes found 203 devices on UDP 9992 across 22 countries. Total global installed base is estimated in the low thousands at most.
Disclosure date2026-08-06 (VulnCheck blog), CVE published 2026-08-27. VulnCheck did not coordinate with the vendor, stating "There is no patch to coordinate" for an intentionally-shipped implant.
Reporting researcherJacob Baines, VulnCheck. Research published under VulnCheck's Initial Access Intelligence program. VulnCheck named the implants SPEAKINGSTONE and DARKLANTERN.

Sources.

  1. VulnCheck — Chinese Implants in the Supply Chain (SPEAKINGSTONE & DARKLANTERN research)
  2. VulnCheck Advisory — Zbtlink MQWrt yunmgrd Cloud C2 Implant
  3. The Hacker News — China-Made ZBT Routers Ship With Two Implants
  4. The Register — Chinese router vendor denies firmware backdoors
  5. SecurityOnline — ZBT Router Backdoor: VulnCheck Sinkholes Implants
  6. Strix AI — CVE-2026-74232 Details
  7. PK Sharma — ZBT router implants: what the research actually found
  8. Startup Fortune — Zbtlink Routers on Amazon Hide a Backdoor That Phones China Every 35 Seconds
05 · The Call

Final Verdict
↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

  • CVSS vector mismatch: The 9.8 score assumes AV:N/AC:L — a trivially-reachable network attack. SPEAKINGSTONE is outbound-only; the attacker must be on the network path between the router and the C2 server in Shenzhen. This is functionally AC:H at minimum, more accurately requiring a privileged network position (ISP MITM, domain takeover, BGP hijack). The companion DARKLANTERN (CVE-2026-74233) is the CVE that matches AV:N/AC:L.
  • Negligible enterprise installed base: Zbtlink is a budget Chinese OEM selling on Amazon and Alibaba. Sinkhole data showed 390/392 devices in China on carrier networks. The probability of finding Zbtlink hardware in a Western enterprise managing 10,000 hosts is effectively zero. Shadow-IT tail risk from white-labeled OEM/ODM devices exists but is unquantified.
  • Role multiplier — network edge: Routers are in the high-value-role catalog under 'Network edge appliances.' However, Zbtlink routers are consumer/SOHO/carrier-CPE devices, not enterprise perimeter gear (F5, Palo Alto, FortiGate class). Sinkhole data confirms 363/392 devices were China Mobile CPE (L3_V2_8 model). Enterprise high-value-role share is well below 1% of the installed base, so the HIGH floor does not apply. If an enterprise *did* have one at its perimeter, the blast radius would be network-edge-level (DNS hijack of all LAN clients, credential theft, pivot point) — but this deployment scenario is not documented in the data.
  • Attack-path friction compounds: Step 1 (having the hardware) eliminates >99.9% of enterprise fleets. Step 2 (network-path positioning) requires nation-state MITM or domain/BGP hijacking. These are independent, compounding friction factors that dramatically reduce the real-world exploitability below CRITICAL.
  • Supply-chain implant nature preserves floor: Despite all friction, CWE-506 (Embedded Malicious Code) means any device running this firmware is *already compromised by design* — the vendor has root access via the C2 channel. This is not a hypothetical exploit; it is an active surveillance capability shipping in production hardware. This inherent compromise prevents downgrading below MEDIUM.

Why not higher?

The HIGH floor for network edge appliances requires ≥1% of the installed base serving in enterprise high-value roles. Sinkhole data (390/392 in China, 363/392 carrier CPE) and the product's market position (budget Amazon/Alibaba routers) demonstrate that enterprise high-value-role deployment is well below 1%. The MITM-equivalent attack requirement for SPEAKINGSTONE specifically (unlike DARKLANTERN which listens inbound) further constrains real-world exploitation to nation-state-level adversaries, making HIGH unjustifiable for the general enterprise defender.

Why not lower?

This is CWE-506 — deliberately embedded malicious code, not an accidental bug. Every affected device is actively beaconing device fingerprints (model, MAC, SSID, LAN IP, GPS coordinates, uptime) to a server in Shenzhen. The OEM/ODM white-labeling model means unknown devices may carry this firmware under different brand names, creating a tail risk that cannot be fully inventoried. The protocol documentation is now public, lowering the bar for future exploitation if the C2 domain changes hands. LOW would understate the inherent danger to any organization that discovers one of these devices on their network.

06 · Verification

Crowdsourced verification payload.

Run this script on any Linux/macOS workstation with network access to your internal DNS server and firewall logs. It checks for DNS queries to known SPEAKINGSTONE C2 domains and scans for devices with Zbtlink-associated MAC OUI prefixes on your local network segments. Requires nmap and dig. Invoke: sudo bash check_speakingstone.sh 192.168.1.0/24

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_speakingstone.sh — Detect SPEAKINGSTONE (CVE-2026-74232) indicators
# Usage: sudo bash check_speakingstone.sh <CIDR>
# Requires: nmap, dig, arp (standard on Linux/macOS)
# Exit codes: 1=VULNERABLE (indicators found), 0=PATCHED (no indicators), 2=UNKNOWN

set -euo pipefail

SUBNET="${1:-}"
if [ -z "$SUBNET" ]; then
  echo "Usage: $0 <CIDR subnet to scan, e.g. 192.168.1.0/24>"
  exit 2
fi

VULN=0

# Known SPEAKINGSTONE C2 domains
C2_DOMAINS=("ac-link.com" "www.ac-link.com" "findmyipaddr.com" "www.findmyipaddr.com")
C2_IP="47.107.224.89"

echo "=== CVE-2026-74232 SPEAKINGSTONE Detection ==="
echo "[*] Checking DNS resolution of known C2 domains..."
for domain in "${C2_DOMAINS[@]}"; do
  resolved=$(dig +short "$domain" 2>/dev/null | head -1)
  if [ -n "$resolved" ]; then
    echo "[!] $domain resolves to $resolved"
    if [ "$resolved" = "$C2_IP" ]; then
      echo "    WARNING: Resolves to known ZBT C2 IP ($C2_IP)"
    fi
  fi
done

# Known Shenzhen Zhibotong OUI prefixes (partial list)
# Check IEEE OUI database for complete list
ZBT_OUIS=("44:d1:fa" "44:D1:FA" "e4:95:6e" "E4:95:6E")

echo ""
echo "[*] Scanning $SUBNET for devices with Zbtlink-associated MAC prefixes..."
nmap -sn "$SUBNET" -oG - 2>/dev/null | grep "Host:" | awk '{print $2}' | while read -r ip; do
  mac=$(arp -n "$ip" 2>/dev/null | grep -oE '([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}' | head -1)
  if [ -n "$mac" ]; then
    mac_prefix=$(echo "$mac" | cut -d: -f1-3 | tr '[:upper:]' '[:lower:]')
    for oui in "${ZBT_OUIS[@]}"; do
      oui_lower=$(echo "$oui" | tr '[:upper:]' '[:lower:]')
      if [ "$mac_prefix" = "$oui_lower" ]; then
        echo "[!!!] VULNERABLE: Device at $ip has Zbtlink OUI ($mac)"
        VULN=1
      fi
    done
  fi
done

echo ""
echo "[*] Checking for outbound UDP/10000 traffic to C2 IP (requires iptables/conntrack)..."
if command -v conntrack &>/dev/null; then
  hits=$(conntrack -L 2>/dev/null | grep "dst=$C2_IP" | grep "dport=10000" | wc -l)
  if [ "$hits" -gt 0 ]; then
    echo "[!!!] VULNERABLE: $hits active connections to C2 IP $C2_IP on UDP/10000"
    VULN=1
  else
    echo "[OK] No active conntrack entries to C2 IP on UDP/10000"
  fi
else
  echo "[SKIP] conntrack not available — check firewall logs manually for UDP/10000 to $C2_IP"
fi

echo ""
if [ "$VULN" -eq 1 ]; then
  echo "RESULT: VULNERABLE — SPEAKINGSTONE indicators detected. Remove affected devices immediately."
  exit 1
else
  echo "RESULT: PATCHED — No SPEAKINGSTONE indicators found on scanned subnet."
  echo "NOTE: Run against all network segments. Check for white-labeled OEM devices manually."
  exit 0
fi