ENDLESSDOORS Backdoor in Zbtlink Routers: 20 Models to Replace

VulnCheck has found a root-control implant, named ENDLESSDOORS and tracked as CVE-2026-66747, inside firmware for 20 tested Zbtlink router models also sold under the Wiflyer name. The component starts at boot, calls an external command server from inside the network, and can accept shell commands as root. There is no fixed vendor firmware in the disclosure, so owners should identify the exact model, isolate the router, and plan replacement instead of treating a password change or factory reset as a complete fix.

The August 5 research does not show that every router was actively controlled or that every computer behind one is infected. VulnCheck verified the implant in the firmware images it examined and demonstrated control of its own test router. Its estimate of at least 100,000 active affected routers describes possible exposure, not a confirmed victim count.

Why ENDLESSDOORS Bypasses Normal Router Defenses

ENDLESSDOORS is a customized version of the old rctl remote-control tool. On the tested router it appeared as two unbracketed kworker processes running as root. Unlike legitimate Linux kernel worker threads, these processes are ordinary user-space programs with memory footprints.

The implant initiates the connection itself. That matters because an outbound connection can pass through NAT and common firewall rules even when the router has no public management page or listening control port. VulnCheck found no authentication or encrypted trust check in the command channel: a system controlling the destination or network path could send commands or request an interactive root shell.

This is a different decision from a typical exposed admin page. Our guide to the Tenda firmware backdoor focuses on specific vulnerable builds and reducing management exposure. ENDLESSDOORS starts from the affected firmware itself and calls outward, so closing remote administration is not enough.

Confirmed Zbtlink and Wiflyer Models

VulnCheck found the implant in every firmware image available on the Zbtlink download page at the time of testing. Match the model number printed on the device or its administration page, not only the logo: Zbtlink offers OEM and ODM manufacturing, and the same hardware may appear under Wiflyer or another reseller label.

The list is evidence-bounded. It confirms the 20 examined models; it does not prove every device from every reseller is affected or safe. A similar case name is not a substitute for the exact model number.

How to Check Without Losing Evidence

1. Photograph the label. Record the brand, exact model, hardware revision, serial number, and current firmware version before changing settings.
2. Check the inventory. Include travel routers, cellular gateways, vehicle or RV routers, hotel back-office equipment, branch-office links, and unbranded devices supplied by contractors.
3. For managed devices, review the process list. Two unbracketed kworker entries with nonzero memory use are the behavior VulnCheck documented. Do not confuse them with legitimate bracketed kernel threads.
4. Review network telemetry. Unexpected outbound TCP connections on ports 7000 or 7001 from a router or gateway are high-value signals. Preserve DNS, firewall, and DHCP logs before replacing the device.
5. Check the disclosed files if you already have authorized shell access. The reported artifacts include /usr/sbin/kworker, /usr/lib/librctl.so, /etc/kworker.cfg, and /etc/init.d/skworker. Do not expose management or enable remote shell access merely to perform this check.

Defenders can also alert on the defanged destinations zbtctl[.]epplink[.]net, online-string[.]com, and rbdg4nzqadui[.]wikaba[.]com. Blocking them limits the observed command path, but it does not make the rest of the firmware trustworthy.

What Owners Should Do Now

1. Disconnect or isolate the router. For a home or travel setup, move essential devices to a known-supported replacement gateway. For a business, place the affected unit behind strict egress controls and treat its LAN as untrusted until replacement.
2. Do not rely on a reboot, reset, or password change. Those actions can restore settings, but the disclosed component starts from the vendor firmware at boot.
3. Replace it with a supported model from a vendor that publishes security updates. Configure the replacement manually rather than importing an old backup that may restore unsafe DNS, forwarding, or administration settings.
4. Set new router and Wi-Fi credentials after the replacement is in control. Also review DNS resolvers, port forwards, UPnP mappings, VPN profiles, and unknown administrator accounts.
5. Review important accounts and endpoints separately. Look for unexplained DNS changes, certificate warnings, redirects, suspicious downloads, or unusual sign-ins. An affected router creates an attack path; it does not prove that every connected device was compromised.

If DNS or administrator settings changed, use our router compromise checklist to separate gateway changes from local-device symptoms. If a Windows computer downloaded or ran a suspicious file while using the router, isolate and scan that computer as a separate incident; replacing the router cannot remove malware already present on an endpoint.

References

1. Jacob Baines. “ENDLESSDOORS Is Phoning Home. Pick Up.” VulnCheck, August 5, 2026. https://www.vulncheck.com/blog/zbt-endlessdoors
2. CVE Program. “CVE-2026-66747.” CVE Record, accessed August 5, 2026. https://www.cve.org/CVERecord?id=CVE-2026-66747