← Back to Feed CACHED · 2026-09-20 00:29:04 · CACHE_KEY CVE-2026-93741
CVE-2026-93741 · CWE-119 · Disclosed 2026-09-19

A security flaw has been discovered in Totolink A3002MU Hh-B20211125.1046.

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

A kitchen smoke detector screaming at the top of its lungs — in an empty warehouse

CVE-2026-93741 is an unauthenticated stack buffer overflow in the formWlWds function of the Totolink A3002MU's embedded boa web server. An attacker sends an HTTP POST to /boafrm/formWlWds with a submit-url parameter containing ~1,200+ bytes, overflowing a fixed-size stack buffer and crashing the service — with likely potential for full remote code execution on the underlying MIPS Linux. The affected firmware is Hh-B20211125.1046, a build from November 2021. There is no patch, no vendor advisory, and no indication Totolink intends to release one. A public crash PoC is available on GitHub from researcher SunnyYANGyaya, who simultaneously disclosed at least six critical flaws (CVE-2026-93738 through CVE-2026-93742) in the same firmware, all exploiting different boa form handlers with the same class of bug.

The vendor CVSS of 10.0 is mathematically defensible — network-reachable, no auth, no interaction, full CIA impact with scope change. But CVSS does not ask *who actually runs this device*. The Totolink A3002MU is a ~$40 consumer dual-band Wi-Fi router sold primarily through Asian retail channels. It is not enterprise-class infrastructure. In a managed environment of 10,000+ hosts, the probability of finding one in your CMDB rounds to zero. If one surfaces — a forgotten branch closet, a remote worker's home — the answer is not 'patch it' but 'replace it,' because no patch exists or will ever exist. The real threat this CVE represents is botnet conscription: the Beastmode Mirai campaign integrated Totolink exploits within one week of PoC publication, and similar campaigns continued through 2025-2026. That matters to ISPs and internet hygiene — not to your enterprise patching queue.

"CVSS 10 on paper, but this $40 SOHO router has no place in your enterprise fleet."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Locate an exposed Totolink A3002MU

The attacker scans for the Totolink boa web server, identifiable via HTTP response headers (Server: boa) and default login page HTML signatures containing TOTOLINK branding. Shodan, Censys, and FOFA dorks for the boa server string or Totolink-specific HTML markers can enumerate internet-facing instances. The web management interface listens on port 80 by default on the LAN side; WAN-side management is off by default but commonly enabled by users who want remote access.
Conditions required:
  • Target runs Totolink A3002MU firmware Hh-B20211125.1046
  • Web management interface is reachable from the attacker's network (LAN or WAN)
Where this breaks in practice:
  • Enterprise environments do not deploy consumer SOHO routers — this device should not exist in a managed fleet
  • LAN-side-only access requires the attacker to already be on the local network segment, implying post-initial-access
  • WAN-side management is disabled by default; enabling it is an explicit user misconfiguration
Detection/coverage: Shodan query http.title:"TOTOLINK" or server:"boa" identifies exposed instances. runZero/Rumble asset discovery flags unknown consumer devices on managed segments. NAC solutions should quarantine unrecognized device types.
STEP 02

Send crafted POST to /boafrm/formWlWds

The attacker sends an HTTP POST to /boafrm/formWlWds with a submit-url parameter containing approximately 1,200+ bytes of padding. No session cookie, no authentication token, no CSRF check — the endpoint is fully unauthenticated. The oversized input is copied into a fixed-size stack buffer via unsafe string-copy logic in the formWlWds function of the /bin/boa binary, corrupting the stack frame. The public PoC demonstrates a reliable crash (DoS).
Conditions required:
  • HTTP connectivity to the boa web server on port 80
  • No authentication required
Where this breaks in practice:
  • The published PoC achieves DoS (crash) only — weaponizing for reliable RCE on MIPS requires building a ROP chain from gadgets in the boa binary and aligning shellcode, which is non-trivial
  • No public weaponized RCE exploit exists as of disclosure date
Detection/coverage: IDS/IPS signatures matching oversized POST bodies to /boafrm/ endpoints could detect this. However, consumer routers do not sit behind enterprise IDS/IPS.
STEP 03

Achieve root-level code execution

If the attacker develops a working RCE payload — typically MIPS shellcode chained via ROP gadgets extracted from the boa binary — they gain execution as the web server process. On embedded Totolink firmware, boa runs as root. The attacker now has full control of the router's Linux OS, including the ability to modify DNS settings, intercept traffic, install persistent backdoors via nvram writes, or download additional payloads.
Conditions required:
  • Successful RCE exploitation beyond the public DoS PoC
  • Router's embedded Linux permits outbound connections for payload staging
Where this breaks in practice:
  • MIPS RCE exploit development from a stack overflow is well-understood by botnet operators but beyond script-kiddie capability
  • The blast radius is limited to the small SOHO network behind this single router — typically 2-10 devices
  • No ASLR, no stack canaries on this firmware, which actually reduces friction for skilled attackers
Detection/coverage: No EDR, no host-based detection runs on consumer router firmware. Detection relies entirely on network-level anomalies: unexpected outbound connections from the router's IP, DNS resolution changes, or traffic to known C2 infrastructure.
STEP 04

Conscript into botnet or pivot into LAN

The compromised router becomes either a DDoS bot in a Mirai-variant botnet (the overwhelmingly more common outcome based on historical Totolink exploitation) or a pivot point into the LAN behind it. Botnet conscription involves downloading a MIPS Mirai binary from attacker infrastructure and registering with a C2 server. LAN pivoting could expose devices behind NAT but requires further exploitation of those endpoints, which in an enterprise context would have EDR, endpoint firewalls, and VPN tunnel isolation.
Conditions required:
  • Sustained root access on the router
  • Outbound internet connectivity for C2 communication
Where this breaks in practice:
  • Pivoting into a corporate VPN-connected laptop behind this router requires a separate exploit chain against that endpoint
  • The router's limited CPU/RAM (~64-128MB) constrains attacker tooling
  • Enterprise endpoints behind the router connect to corporate resources via VPN tunnels that bypass the router's forwarding plane
Detection/coverage: GreyNoise or threat-intel feeds flagging the router's public IP as a known botnet participant. ISP-level DDoS traffic anomaly detection. Corporate SOC would see no direct indicator unless the router is on a monitored segment.
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNo confirmed exploitation of this specific CVE yet (disclosed 2026-09-19). However, Totolink routers are a proven, recurring target for Mirai-variant botnets. The Beastmode campaign integrated Totolink exploits within one week of PoC publication in 2022. RustoBot and other variants continued targeting Totolink through 2025-2026.
Proof-of-ConceptPublic crash PoC. Researcher SunnyYANGyaya published a DoS PoC on GitHub demonstrating the boa crash via oversized submit-url. No weaponized RCE exploit is publicly available.
EPSS Score0.00644 (0.6%, ~51st percentile) — low near-term exploitation probability per the FIRST EPSS model. Consistent with a niche device and no confirmed wild exploitation.
CISA KEV StatusNot listed. No federal patching mandate. No named threat actor campaigns tied to this specific CVE.
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H = 10.0. Also scored 10.0 on CVSS v4.0. The scope-change (S:C) reflects that compromising the router impacts all devices behind it.
Affected VersionsTotolink A3002MU firmware Hh-B20211125.1046 (built November 25, 2021). No other firmware versions confirmed affected or unaffected. Only this single firmware build has been tested.
Fixed VersionsNone. No patch, no vendor advisory, no updated firmware. The A3002MU appears to be end-of-life with no active vendor support. Distro backports are not applicable — this is proprietary embedded firmware.
Scanning / ExposureTotolink boa web servers are findable via Shodan (http.title:TOTOLINK or server:boa). The A3002MU is a low-volume consumer product — global internet-facing exposure is estimated in the low thousands at most. Enterprise presence is effectively zero.
Disclosure Date2026-09-19. Part of a batch of 6+ CVEs (CVE-2026-93738 through CVE-2026-93742, plus earlier CVE-2026-906xx series) disclosed simultaneously by the same researcher against the same firmware.
ResearcherSunnyYANGyaya (GitHub). Prolific IoT vulnerability researcher responsible for discovering multiple classes of bugs across the entire A3002MU boa web interface.
04 · The Call

Final Verdict
DOWNGRADED to MEDIUM (5.0/10)

Why this verdict

  • Zero enterprise installed base. The Totolink A3002MU is a ~$40 consumer SOHO Wi-Fi router sold primarily through Asian retail channels. It does not appear in enterprise procurement catalogs, is not supported by any enterprise management platform, and has no presence in Gartner/IDC enterprise networking analyses. In a managed fleet of 10,000+ hosts, the probability of this device existing in your CMDB is effectively zero. You cannot prioritize patching a device you do not own.
  • No patch exists — and never will. Totolink has issued no advisory, no firmware update, and no acknowledgment. The firmware build dates to November 2021 on what appears to be an end-of-life product line. This is not a patching decision; it is a procurement decision. The only remediation is physical replacement.
  • Public PoC achieves DoS only, not weaponized RCE. The published exploit crashes the boa web server but does not demonstrate code execution. Weaponizing a MIPS stack overflow for reliable RCE requires ROP chain construction and shellcode alignment — achievable for botnet operators but not a one-click tool. No known weaponized exploit is in public circulation.
  • Role multiplier: SOHO network edge (not enterprise perimeter). 100% of A3002MU deployments serve as the network edge for micro-networks of 2-10 devices. This is categorically different from the enterprise perimeter appliances in the high-value role catalog (FortiGate, PAN-OS, F5 BIG-IP). Compromising an A3002MU gives the attacker DNS hijacking and LAN pivot over a single home or small office — not domain takeover, not fleet compromise, not mass data egress. The worst realistic outcome is botnet conscription (DDoS node) or traffic interception over a handful of consumer devices. The HIGH floor does not apply because the blast radius does not reach domain-scale or fleet-scale impact in any deployment scenario.
  • Botnet history is real but internet-scoped, not enterprise-scoped. Mirai-variant campaigns have integrated Totolink exploits within days historically. This threat is real — but it is an internet-hygiene and ISP-level concern, not an enterprise patch-prioritization concern. Your SOC will never see an alert from a device that is not on your network.

Why not higher?

A HIGH or CRITICAL rating requires either enterprise-deployed infrastructure or a blast radius that reaches domain/fleet scale. The Totolink A3002MU fails both tests. It is a consumer device absent from enterprise networks, and even in its native SOHO deployment, compromising it impacts a micro-LAN of 2-10 devices — not thousands. Corporate endpoints behind a compromised home router connect to enterprise resources via VPN tunnels that bypass the router's forwarding plane entirely, and those endpoints have EDR and host firewalls as independent defensive layers.

Why not lower?

The vulnerability is technically severe: unauthenticated, network-reachable, with a public PoC and a proven pattern of rapid Mirai-variant integration for Totolink flaws (Beastmode weaponized within one week of PoC publication). If an asset scan surfaces an A3002MU on a branch network or an employee's home connection feeding into a split-tunnel VPN, the combination of no-auth exploitation, no available patch, and active botnet interest in the Totolink platform makes it a genuine risk to that segment. Dropping below MEDIUM would understate the urgency of replacing any discovered units.

05 · Compensating Control

What to do — in priority order.

  1. Run asset discovery for Totolink devices across all managed segments — Use runZero/Rumble, Nmap (nmap -sV --script http-title), or your NAC platform to search for devices with boa web server headers or TOTOLINK HTML signatures on all managed network segments including branch offices. If you find zero, close this CVE as not-applicable and document the rationale. No noisgate mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window by running this scan within your next scheduled asset audit.
  2. Replace any discovered A3002MU units with supported enterprise-grade equipment — There is no patch and never will be. The only remediation is physical replacement with a vendor-supported device (e.g., Cisco Meraki MR, Aruba Instant On, FortiAP, Ubiquiti UniFi). Open a procurement ticket, not a patching ticket. Target completion within the noisgate 365-day remediation SLA for MEDIUM severity.
  3. Block WAN-side management on any discovered units immediately — If replacement cannot happen same-day, ensure the router's web management port (TCP/80) is unreachable from the WAN. Apply an ACL on the upstream device (ISP modem, perimeter firewall) to drop inbound HTTP to the Totolink's WAN IP. This eliminates the internet-facing attack surface while you procure a replacement.
  4. Segment the device off managed networks via VLAN isolation — If an A3002MU is found on a managed LAN segment (e.g., plugged into a switch port in a branch office), isolate it immediately to a quarantine VLAN with no route to corporate resources. This contains the blast radius if the device is already compromised or gets compromised before replacement.
What doesn't work
  • Firmware update — no patch exists and the product is effectively EOL. Checking Totolink's download page is a dead end.
  • Changing the admin password — the vulnerable endpoint /boafrm/formWlWds requires no authentication. Stronger credentials do not mitigate this vulnerability.
  • WAF or IPS rules — the Totolink IS the outermost network device in its deployment; there is no upstream security appliance to place rules on unless you control the ISP link or have a managed SD-WAN overlay in front of it.
  • Disabling WDS (Wireless Distribution System) — the buffer overflow is in the HTTP form handler's input parsing logic, not in WDS functionality. The /boafrm/formWlWds endpoint is reachable regardless of whether WDS is operationally configured.
06 · Verification

Crowdsourced verification payload.

Run from an auditor workstation on the same network segment as the suspected Totolink device (or any host with HTTP reach to the target). Usage: chmod +x check_cve_2026_93741.sh && ./check_cve_2026_93741.sh 192.168.0.1. Requires only curl and grep. No elevated privileges needed. This script does not send an exploit payload — it fingerprints the device model and firmware version via the landing page only.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_93741.sh — Totolink A3002MU CVE-2026-93741 presence check
# Usage: ./check_cve_2026_93741.sh <target_ip>
# Exit codes: 0=VULNERABLE, 1=PATCHED/NOT_AFFECTED, 2=UNKNOWN

set -uo pipefail

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 <target_ip_or_hostname>"
  exit 2
fi

TIMEOUT=10
URL="http://${TARGET}/"

echo "[*] Probing $TARGET for Totolink A3002MU (CVE-2026-93741)..."

# Fetch the landing page including HTTP headers
RESPONSE=$(curl -sS -m "$TIMEOUT" -D- "$URL" 2>/dev/null) || true

if [[ -z "$RESPONSE" ]]; then
  echo "[!] No HTTP response from $TARGET — host may be down or not running HTTP."
  echo "UNKNOWN"
  exit 2
fi

# Check for Totolink or boa server signatures
IS_TOTOLINK=0
if echo "$RESPONSE" | grep -qi 'totolink'; then
  IS_TOTOLINK=1
elif echo "$RESPONSE" | grep -qi 'server:.*boa'; then
  IS_TOTOLINK=1
fi

if [[ "$IS_TOTOLINK" -eq 0 ]]; then
  echo "[-] Target does not appear to be a Totolink device (no TOTOLINK or boa signature found)."
  echo "PATCHED"
  exit 1
fi

echo "[+] Totolink/boa device detected at $TARGET."

# Check for A3002MU model string
if ! echo "$RESPONSE" | grep -qi 'A3002MU'; then
  echo "[?] Totolink device found but model is NOT A3002MU. This CVE may not apply."
  echo "UNKNOWN"
  exit 2
fi

echo "[+] Model confirmed: Totolink A3002MU."

# Check for vulnerable firmware version in page content
if echo "$RESPONSE" | grep -qi 'Hh-B20211125'; then
  echo "[!] FIRMWARE MATCH: Hh-B20211125.1046 detected."
  echo "[!] This device is VULNERABLE to CVE-2026-93741 (formWlWds buffer overflow)."
  echo "[!] ACTION: Replace this device immediately — no patch exists."
  echo ""
  echo "VULNERABLE"
  exit 0
fi

# Firmware string not found on landing page — probe the vulnerable endpoint
WDS_CODE=$(curl -sS -m "$TIMEOUT" -o /dev/null -w "%{http_code}" \
  -X POST "http://${TARGET}/boafrm/formWlWds" \
  -d "submit-url=test" 2>/dev/null) || WDS_CODE="000"

if [[ "$WDS_CODE" == "200" || "$WDS_CODE" == "302" ]]; then
  echo "[!] A3002MU with accessible /boafrm/formWlWds endpoint (HTTP $WDS_CODE)."
  echo "[!] Firmware version not confirmed from landing page — but endpoint is live."
  echo "[!] Treat as LIKELY VULNERABLE. Verify firmware version via admin panel."
  echo ""
  echo "VULNERABLE"
  exit 0
else
  echo "[?] A3002MU detected but firmware version unclear; formWlWds returned HTTP $WDS_CODE."
  echo "UNKNOWN"
  exit 2
fi
07 · Sources

Peer Review

What defenders are saying.

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

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.