SURIQ
This is the third backdoor found baked into one router maker's firmware, and the two new ones are the reason the last round's advice no longer covers you. When VulnCheck disclosed an earlier ZBT implant that phoned home, the reliable defense was to watch the device call out to a stranger. One of the two implants VulnCheck disclosed this week still works that way. The other does the opposite: it sits quietly and waits for the internet to knock. A defender who only watched the outbound call-out is now half covered.
The routers are built by Shenzhen Zhibotong Electronics, sold as ZBT and rebranded under several white-label names. VulnCheck, which acts as a CVE issuing authority, named the two implants SPEAKINGSTONE and DARKLANTERN and assigned them CVE-2026-74232 and CVE-2026-74233. Both are rated 9.3 on the newer CVSS 4.0 severity scale. Both are written in the Nim programming language, both talk over UDP, and neither needs a password. They join ENDLESSDOORS, the implant we covered from the same vendor, which makes this a pattern rather than a single bad build.
Two implants pointed in opposite directions
The design split is the whole story. SPEAKINGSTONE runs as a service called yunmgrd and calls outward over UDP port 10000 to a hardcoded control server. Because it dials out, it works from behind home-router network address translation and straight through ordinary outbound filtering, the same way any browser reaches the web. Its primary control domain, ac-link[.]com, resolves to an Alibaba Cloud address in Shenzhen and, per VulnCheck, is still live. When researchers stood up a sinkhole for a backup domain, 392 devices checked in, almost all of them in China.
DARKLANTERN is the inverse. It runs as infosrvd, listens on UDP port 9992, and the router's default firewall is configured to allow inbound connections to that port from anywhere on the internet. VulnCheck reports that its authentication is a forgeable checksum paired with a hardcoded bypass, so in practice there is no effective access control at all. Between August 18 and 21, VulnCheck counted 203 of these listeners exposed to the open internet across 22 countries, with responding devices self-reporting 16 different models.
| Trait | SPEAKINGSTONE | DARKLANTERN |
|---|---|---|
| Identifier | CVE-2026-74232 | CVE-2026-74233 |
| Direction | Dials out (calls home) | Listens for inbound internet packets |
| Channel | Service yunmgrd, UDP port 10000 | Service infosrvd, UDP port 9992, firewall open by default |
| Access control | None on the wire, no key exchange | Forgeable checksum plus a hardcoded bypass |
| Reach | 392 devices seen at a sinkhole, mostly in China | 203 exposed to the open internet, 22 countries |
Put the two together and they defeat the two halves of a normal perimeter separately. "We block inbound connections" does nothing about SPEAKINGSTONE, which never accepts one. "We sit behind NAT" does nothing about DARKLANTERN, because the firmware itself opens the door from the outside. Neither of the two reassuring sentences most teams tell themselves about a small router holds here.
DARKLANTERN turns a backdoor into a public front door
The difference matters more than a shared severity score suggests. A phone-home implant like ENDLESSDOORS or SPEAKINGSTONE is reachable by whoever runs the control servers. That is bad, but it is a bounded set of people. DARKLANTERN removes even that limit. Because it listens on an open port and its checksum can be forged, the party who can run commands as root is not the implant's author but anyone on the internet who can reach UDP port 9992 on the device. VulnCheck describes the effect as an unauthenticated root shell reachable from the public internet.
That is a categorical change in the threat model, not a bigger version of the same problem. The 203 exposed listeners are not waiting for a specific operator to notice them. They are open to opportunistic scanning, and scanning the whole internet for a single UDP port is a matter of minutes for anyone who cares to. This is the same shape as a decade-old router flaw with no fix: the exposure is not theoretical because the device is small, it is worse because nobody is watching the device at all.
What SPEAKINGSTONE can take that a new router will not give back
SPEAKINGSTONE is not a simple remote shell. According to VulnCheck's breakdown, reported alongside The Hacker News, its command set can run code as root, steal the router's WAN login (the PPPoE username and password your device uses to authenticate to the internet provider), read and write a DNS redirect list, and open a reverse SSH tunnel back into the network behind the router.
Two of those outlive the box. Stolen provider credentials keep working after you unplug the router, because they are your account, not the hardware's. A DNS redirect list means every device behind that router could have been sent to attacker-chosen addresses for as long as the implant was active, and swapping the router does not tell you where your traffic went in the meantime. So the honest scope of a SPEAKINGSTONE compromise is larger than one device: rotate the internet-provider password, and treat anything that resolved a hostname through that router during the exposure window as suspect.
Detection now has to look both ways
The earlier ZBT round left a good heuristic: an edge device that reaches a fixed foreign host on a steady, machine-regular interval is doing something a small router has no business doing. That still catches SPEAKINGSTONE, whose UDP port 10000 call-out is exactly that kind of dumb, periodic signal. It is worth building into behavioral threat hunting as a general rule, because plenty of unrelated implants call out the same way.
DARKLANTERN produces no such call-out. It makes no outbound connection to flag, so egress monitoring is blind to it by design. Its tell is the opposite: an edge device that is listening on UDP port 9992 and accepting packets from the outside. You find that by scanning your own external attack surface, from the internet in, not by reading your outbound logs. If you run any small ZBT or white-label travel router, the fastest answer today is to check whether UDP port 9992 answers from outside your network, and block inbound UDP to it at any upstream firewall you control. These same devices are the ones that keep getting pulled into botnets for exactly this reason: they are internet-facing, unmonitored, and rarely on anyone's patch list.
Treat these routers as compromised hardware, not a patch queue
There is no fixed firmware for either implant. VulnCheck reports that when it raised the earlier ENDLESSDOORS implant, the vendor characterized that code as an after-sales support tool used only with customer authorization. VulnCheck says it found no mechanism by which a customer could request or authorize such access, and that none of these implants use secure communication, so anyone on the network path can hijack them. The vendor has not issued a public statement about SPEAKINGSTONE or DARKLANTERN at the time of writing.
Whatever the intent, the practical position for a defender is the same, and it is not a vulnerability-management problem. You cannot patch your way out of three implants across a vendor's firmware generations. The sound response is to stop deploying the hardware, isolate any units already in service, replace them, and treat everything that transited one of these routers as observed: credentials rotated, sessions ended, DNS answers no longer trusted. A router is supposed to be the boring box in the corner. When the boring box ships with a standing root shell three times over, the box is the incident.