- What: VulnCheck disclosed ENDLESSDOORS, a factory-shipped backdoor present in all 21 firmware images Zbtlink published across 20+ router models spanning more than two years.
- Impact: The implant runs as root disguised as a kernel worker, beacons out every 35 seconds with no authentication, and will spawn a live interactive root shell for whoever answers, meaning any on-path or DNS-controlling attacker takes the router without needing inbound access.
- Fix / mitigation: No patched firmware exists yet; Zbtlink pulled the affected images from its download page and says validated builds are in progress, so hunt for /usr/sbin/kworker, /usr/lib/librctl.so, /etc/kworker.cfg, and /etc/init.d/skworker and block egress to the four known C2 endpoints now.
- Who's at risk: Anyone running Zbtlink hardware or OEM/ODM devices built on Zbtlink stock firmware, especially the CPE2801, WE-series, WG-series, and Z8102AX-2DSIM models used in industrial, cellular-router, and kiosk deployments.
Every single firmware image Zbtlink published, all 21 of them, ships with a backdoor. Not a debug flag, not a hardcoded credential you have to guess. A userland implant that runs as root at boot, phones home to Chinese infrastructure as often as every 35 seconds, and executes whatever the server on the other end sends back with no handshake, no negotiation, and no authentication of any kind. VulnCheck named it ENDLESSDOORS. It covers at least 20 router models and firmware releases spanning more than two years.
The important detail for defenders is not that the router is backdoored by the vendor. It is that the backdoor is unauthenticated in both directions. Zbtlink's C2 does not prove who it is to the implant, and the implant does not prove who it is to the C2. That turns a vendor maintenance channel into a shared resource. Anyone on the network path, and anyone who can influence DNS resolution for the callback domain, inherits root on the device.
What the implant actually is
ENDLESSDOORS is a lightly customized build of rctl, a remote control tool uploaded to GitHub on January 14, 2015 and never touched again. It is roughly the simplest C2 you can write: the server listens on port 7000, clients connect out, and the server either pushes individual shell commands or tells the client to spawn a reverse shell.
The protocol has effectively two verbs. The implant opens a connection, sends a hello message carrying the device's LAN MAC address as its identifier, and then runs whatever comes back as root. One reserved string, rctlbash, tells the implant to open a second connection to port 7001, allocate a pseudo-terminal, spawn /bin/sh, and bridge it. As VulnCheck's CTO Jacob Baines put it, the vocabulary is run this as root, and give me a root shell.
On the AX3000 that VulnCheck analyzed, the implant presents itself as a process named kworker. Real kworker processes are kernel threads. This one is a userland process running with root privileges, sitting in a process list alongside the legitimate kworker entries where a casual ps sweep slides right past it. The init script that launches it at boot is named skworker, one character away from blending in.
This is not a listening service you can firewall off at the perimeter. The implant initiates the connection outbound, which means CGNAT, a consumer NAT, or a locked-down inbound ACL provides zero protection. The attack surface is the DNS resolution and the network path to the C2, not the router's WAN interface.
The hijack problem
Because there is no authentication or certificate pinning, control of an ENDLESSDOORS implant reduces to control of a name. Whoever owns the resolution of rbdg4nzqadui.wikaba[.]com, or the address it currently resolves to, can command any implant that tries to reach it. That is a domain on a free dynamic DNS-style provider with a random-looking label. Registrar takedown, DNS hijack, sinkhole, upstream ISP interception, or a hostile resolver on the path all lead to the same place: an attacker-controlled root shell on the device, without the attacker ever needing to find the router or scan for it. The routers volunteer.
That is the part IT managers should internalize. Even if you extend Zbtlink every benefit of the doubt about intent, the design means the vendor is not the only party who can use it. The channel is open to anyone who gets in the middle.
Affected models and infrastructure
Every firmware listed on zbtlink.com's download page embedded the rctl implant and started it at boot via the skworker init script. Affected models:
- CPE2801, WE1026-5G-WD, WE1326, WE2007, WE2008-DSIM, WE2416
- WE3326, WE5927, WE5931, WE5931AC, WE826-T3-DSIM
- WG108, WG1602, WG1608-DSIM, WG209, WG2105, WG2107, WG259, WG3526
- Z8102AX-2DSIM
All of them dial the same set of four primary and secondary endpoints: zbtctl.epplink[.]net (47.100.190[.]96), 47.107.224[.]89, online-string[.]com (45.32.81[.]152), and rbdg4nzqadui.wikaba[.]com (43.248.136[.]125). Two hardcoded IPs and two domains gives you a clean, low-false-positive detection surface. Any of these appearing in DNS or NetFlow logs is worth an immediate investigation.
Vendor response
Zbtlink has pulled the affected firmware from its download channels, replacing the page with a notice that it detected firmware security vulnerabilities and that patched, security-validated builds are in development. No timeline and no fixed version number has been published.
A Zbtlink spokesperson told The Hacker News the feature is solely intended for after-sales maintenance, that it is generally retained only on sample units to assist customers with software debugging, and that the company specializes in OEM and ODM customization work where customers deploy their own firmware rather than ZBT defaults. VulnCheck's finding is that the implant appears in 21 of 21 published images, not a sample subset. Take the explanation for what it is; the mitigation posture does not change either way.
The OEM blast radius
Zbtlink's own admission that it is primarily an OEM/ODM shop is the reason this story is larger than a brand name most Western buyers have never heard of. These boards ship inside other companies' products: cellular gateways, industrial routers, kiosk and vending connectivity, digital signage, fleet telematics, and white-label CPE. If a downstream integrator built on the stock Zbtlink image rather than a custom one, that integrator's product carries ENDLESSDOORS under a different logo and a different model number, and it will not appear on VulnCheck's list. Asset inventories keyed on brand will miss those units. Behavioral detection on the four C2 endpoints will not.
What to do now
There is no patch to apply yet, so containment is network-side and filesystem-side. Treat any confirmed device as fully compromised: an interactive root shell has been reachable for the life of the deployment, so credentials, configs, VPN keys, and anything traversing the device should be considered exposed.
- Block egress to 47.100.190[.]96, 47.107.224[.]89, 45.32.81[.]152, and 43.248.136[.]125, plus DNS resolution for zbtctl.epplink[.]net, online-string[.]com, and rbdg4nzqadui.wikaba[.]com.
- Alert on outbound TCP to ports 7000 and 7001 from any network infrastructure segment. Legitimate routers do not initiate those.
- On accessible devices, check for /usr/sbin/kworker, /usr/lib/librctl.so, /etc/kworker.cfg, and /etc/init.d/skworker. A kworker entry with a userland parent, an executable path, or an open socket is the implant, not a kernel thread.
- Hunt historical DNS and NetFlow for the four endpoints going back as far as retention allows. A 35-second beacon interval leaves an unmistakable trail.
- Query procurement and integrator documentation for Zbtlink-sourced boards inside other-branded products, since the model list will not catch rebadged hardware.
- For devices in sensitive segments, move them behind a filtering gateway or replace them outright rather than waiting on patched firmware with no ship date.
The broader lesson is one the industry keeps relearning. Perimeter thinking assumes the threat arrives from outside and tries to get in. A factory-shipped, outbound-initiating implant inverts that entirely: the device you installed to protect the network is the one calling out, on a schedule, offering root to whoever picks up. Egress monitoring on infrastructure devices is not a nice-to-have. On low-cost OEM hardware it is the only control that would have caught this.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us