VulnCheck published two new implants in Zbtlink router firmware on August 27, 2026 — one of them a listening service that runs commands as root with no authentication — and its own numbers are far smaller than the coverage suggests.
What happened
On August 27, 2026, VulnCheck published research documenting two previously undescribed implants in firmware shipping on routers from the Chinese manufacturer Zbtlink, commonly branded ZBT. The firm named them DARKLANTERN and SPEAKINGSTONE. They join ENDLESSDOORS, a phone-home implant in the same product line that was documented earlier in August. Two days on, the vendor has issued a statement disputing the characterization, and no CVE identifier has been assigned to either finding.
DARKLANTERN is the one that matters operationally. It is a service listening on UDP port 9992 that accepts commands and runs them as root, and it requires no authentication to do so. VulnCheck documents an information probe consisting of a single 19-byte packet — 0c 16 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 — that elicits a response from the device. Command packets are validated against a hardcoded MD5 key derived from the static string mqonu.com, which is present in the firmware itself and therefore is not a secret. A MAC address filter that appears intended to restrict who may issue commands is bypassed by sending an all-zeros MAC address.
SPEAKINGSTONE is the quieter of the two: an outbound beacon. Devices carrying it call home over plaintext UDP port 10000 to ac-link[.]com, which VulnCheck resolved to 47.107.224.89, an Alibaba Cloud address in Shenzhen. The implant also carries a backup domain, www.findmyipaddr[.]com, which was never registered by whoever built it. VulnCheck registered it and stood up a sinkhole.
That sinkhole is where the numbers come from, and the numbers are the part worth reading carefully. Between August 18 and August 21, 2026, VulnCheck counted 203 internet-facing DARKLANTERN instances across 22 countries, spread over 16 distinct model names. The SPEAKINGSTONE sinkhole collected beacons from 392 unique devices, of which 390 were in China and roughly 83 percent sat on the China Mobile network. A single model, the L3_V2_8, accounted for 363 of those 392. Other affected models named in the research include the WE826-T2, the ZBT-7628, and variants sold under the MoreQuick label. The longest-running beacon VulnCheck observed had been calling home for nearly two years.
Zbtlink’s response, quoted by VulnCheck, is that the implant was “intended to assist customers with device troubleshooting and configuration only upon their explicit request and authorization,” and that “this component has never been used for unauthorized access.” VulnCheck’s rebuttal is direct: “We found no mechanism for a customer to explicitly request or authorize access.” The firm summarizes its own evidentiary position as “We have the beacons. We have the scans. We have root.”
Why it matters
Start with the scale, because most of the coverage does not. Headlines have described implants in Chinese-made routers “sold worldwide.” The primary source’s own measured population is 203 internet-facing devices answering DARKLANTERN probes and 392 devices beaconing to a sinkholed backup domain. Those are small numbers. They are also floors, not censuses — an internet-wide scan sees only devices with a routable address and an unfiltered port, and a sinkhole on a backup domain sees only the devices that reached the backup rather than the primary, which remained under its original registration throughout. The honest statement is that VulnCheck proved the mechanism conclusively and measured a lower bound on the population. Neither the true installed base nor the number of devices behind carrier NAT is known from this research, and VulnCheck does not claim otherwise.
The more consequential detail is the one that sounds like a technicality: there is no CVE. These are not bugs. Nobody wrote a bounds check wrong. A service was compiled into shipping firmware that listens on a port and executes commands as root, and a second service was compiled in that reports the device’s existence to a host in Shenzhen. That distinction determines everything downstream. A CVE enters the National Vulnerability Database, becomes eligible for the CISA Known Exploited Vulnerabilities catalog, shows up in scanners, and gets a row in somebody’s remediation queue with a due date attached. A designed-in feature the vendor defends as a support tool enters none of those systems. It will not appear in a vulnerability scan report. It will not trigger a federal remediation clock. It has no patch, because from the manufacturer’s stated position there is nothing to patch.
This is a recurring gap in how the industry tracks risk, and it is worth naming plainly. The vulnerability management apparatus most organizations run is built to consume CVEs. Findings that do not fit that shape — undocumented management channels, factory credentials, telemetry to unexpected destinations — fall through it, no matter how severe. An unauthenticated root command channel is about as severe as a network finding gets, and in this case it will be invisible to every tool that keys on a CVE identifier.
The vendor’s defense deserves engagement rather than dismissal, because remote support channels in consumer and small-business networking gear are genuinely common and not inherently sinister. The problem is not that the channel exists. It is the construction. A support mechanism gated by a key hardcoded into the firmware, with an access filter defeated by an all-zeros value, is not gated at all. Zbtlink’s claim that access occurs only “upon their explicit request and authorization” describes a policy, not a control, and VulnCheck’s point stands: the research found no technical mechanism by which a customer grants or withholds that access. Those two statements are not actually in conflict about the facts. They are in conflict about whether an ungated channel counts as authorized use.
Note also what the geography says. Of 392 sinkholed devices, 390 were in China, most on one carrier. Whatever DARKLANTERN and SPEAKINGSTONE were built for, the measured population is overwhelmingly domestic to the manufacturer’s own market. That is consistent with a support tool for the vendor’s largest customer base. It is also consistent with other readings. The research does not resolve intent, and neither will this page.
What to do
If you have Zbtlink or ZBT hardware, or white-label routers built on the same platforms, treat this as a configuration and network-segmentation problem rather than a patching one, because there is no patch to apply.
- Inventory for the named platforms: L3_V2_8, WE826-T2, ZBT-7628, and MoreQuick-branded variants. The L3_V2_8 dominated the sinkhole data. Note that 16 distinct models responded to DARKLANTERN probes, so the named list is not exhaustive.
- Test for DARKLANTERN directly. Send the documented 19-byte probe to UDP port 9992 on the device’s WAN and LAN interfaces and see whether it answers. This is a reachability check you can run yourself against your own equipment, which is the advantage of research that publishes its artifacts.
- Block inbound UDP 9992 at any upstream boundary you control, and block outbound UDP 10000 to
ac-link[.]comandwww.findmyipaddr[.]com. Check historical firewall and DNS logs for both destinations — the longest observed beacon ran nearly two years, so absence today is not absence historically. - Do not place this hardware where an unauthenticated root shell would matter. That is the durable mitigation. Segment it away from management networks and anything holding data.
- Ask your supplier, in writing, whether the platform carries a remote support channel, how it is authenticated, and how a customer disables it. The answer is useful regardless of vendor.
Sourcing note
This story is built on VulnCheck’s own research post, published August 27, 2026, which is the primary and only source for the DARKLANTERN and SPEAKINGSTONE findings and for the device counts, the protocol details, the model list, and the quoted Zbtlink statement. This is single-vendor research. VulnCheck publishes inspectable artifacts — the probe packet bytes, the port numbers, the hardcoded key string, and the C2 domains — which is why the checks above can be run independently, but no second party has confirmed the counts. The measured population is 203 internet-facing DARKLANTERN instances across 22 countries and 392 devices in the SPEAKINGSTONE sinkhole, observed between August 18 and August 21, 2026; those figures are what the research states and should not be read as an installed base.
We did not reach Zbtlink independently; the vendor statement quoted here is as VulnCheck reproduced it. We could not verify the ENDLESSDOORS timeline against its original publication. No CVE identifier has been assigned to either implant, and neither appears in the CISA Known Exploited Vulnerabilities catalog — cisa.gov returns 403 to automated fetching, so the catalog was checked through NVD’s republication of CISA’s fields rather than directly. Unresolved: whether the primary command-and-control domain remains operational, how many affected devices sit behind carrier NAT and were therefore invisible to both the scan and the sinkhole, and whether any national regulator has opened an inquiry.