What happened
On August 27, 2026, VulnCheck disclosed SPEAKINGSTONE and DARKLANTERN in ZBT router firmware. On August 28, 2026, independent reporting published model and firmware details and noted that no fixed firmware release had been named. Between August 18 and August 21, 2026, VulnCheck identified 203 internet-facing DARKLANTERN instances across 22 countries, self-reporting 16 models. The 203 figure describes devices answering a probe; it is not a count of maliciously compromised organisations.
CVE-2026-74232 tracks SPEAKINGSTONE and CVE-2026-74233 tracks DARKLANTERN. SPEAKINGSTONE runs as yunmgrd, uses UDP port 10000, and contacts www.ac-link.com or www.findmyipaddr.com. The latter was registered and operated as a VulnCheck sinkhole during the research. DARKLANTERN runs as infosrvd and listens on UDP port 9992, which the stock firewall exposes to internet addresses. Both components can lead to root command execution without an authenticated enterprise administrator.
The SHA-256 hash for yunmgrd is b77811db4d218c65670a6c9a5b33c30ff81c6d779e15d658643138771178a818, and the SHA-256 hash for infosrvd is 7e2e036fec2fe7ab4bbd43978d9296563894c92a112f5ac2f39957f12108e245. Explicitly listed examples include Zbtlink WE1326, WE357, WE5926, WE826-T2 and WG3526 on firmware 19.1101, plus MoreQuick MQAC-7620 and MQAP-7628 on firmware 1.0.0.2.000. The cited advisories did not publish a fixed firmware release. Attribution posture: VulnCheck identified embedded implants but did not attribute their operation to a state or threat actor.
Why this matters now
The risk is not limited to an ordinary remotely exploitable service. Both components were present in shipped firmware, run as root and cross the enterprise perimeter in complementary ways. SPEAKINGSTONE calls outward from behind NAT, while DARKLANTERN listens through a firewall rule open to internet addresses. A control model based on blocking only inbound traffic or only suspicious outbound sessions is therefore incomplete.
White-label distribution makes brand-based inventory unreliable. The affected hardware can be sold under reseller names that do not reveal Shenzhen Zhibotong Electronics as the manufacturer. Security teams must join model numbers, firmware, MAC prefixes, procurement records and network behaviour to determine exposure. Sites using inexpensive cellular routers for kiosks, temporary facilities, remote monitoring or failover connectivity are especially prone to decentralised ownership.
No fixed firmware release was named in the cited material. That removes the normal patch-and-close route and shifts the decision towards quarantine, replacement or independently verified alternative firmware where technically and contractually supportable. Continuing to operate a confirmed affected device requires a documented exception and upstream controls that assume the router itself is untrusted.
The decision for security leaders
Order an asset-discovery exercise that does not trust the logo on the enclosure. Use management platforms, switch tables, DHCP records, MAC prefixes, configuration backups and purchasing data to identify ZBT-derived hardware and locate devices outside central network ownership.
Treat a confirmed affected device as an untrusted network boundary. Where replacement cannot occur immediately, place it behind upstream filtering, prevent access to sensitive management networks and monitor both outbound UDP port 10000 and inbound UDP port 9992. Document that these controls reduce reachability but do not remove embedded code.
Change procurement assurance for low-cost routers and cellular gateways. Require the OEM, firmware origin, update mechanism, software bill of materials where available and documented remote-management functions. Exceptions should be time-bound because white-label concentration defeats supplier-name diversification.
Evidence of closure
- The asset register identifies OEM, model and firmware for every managed edge router.
- Network telemetry shows a documented disposition for each published domain or port match.
- Confirmed affected devices are removed or isolated under an approved exception.
- Procurement controls require documented firmware provenance and remote-management functions.
The Security.io assessment
This story warrants inclusion because Friday’s model, firmware and provenance details converted Thursday’s research into an enterprise inventory and replacement decision. It is not another high-score vulnerability item: the components were shipped in firmware, operate as root and lack a published fixed release. That materially changes how CISOs should treat inexpensive edge hardware acquired through resellers.
The evidence supports the presence and mechanical capability of the components, plus live devices answering probes or contacting research infrastructure. It does not establish that every listed model contains both components, that every firmware outside the named builds is safe, or that a state operator used the access. Those uncertainties argue for quarantine and verification, not unsupported attribution.
Blocking the domains alone is inadequate. DARKLANTERN does not depend on the SPEAKINGSTONE command infrastructure, and a capable operator could alter DNS or network paths. Conversely, www.findmyipaddr.com was used as a research sinkhole, so detections involving it require investigation rather than an automatic conclusion about attacker ownership.
Questions for the morning meeting
- Can the asset inventory identify router OEMs beneath reseller or white-label branding?
- Do any managed cellular or edge routers use the published Zbtlink or MoreQuick models and firmware?
- Can network telemetry detect UDP port 9992 listeners and UDP port 10000 beacons?
- What procurement control prevents undocumented remote-management code entering trusted edge networks?