Loading today’s stories
Build1 distinct publisher3 min readPublished
VulnCheck's ENDLESSDOORS ships enabled on more than 20 Zbtlink models and runs as root from boot, and because it opens no port at all, the check that would have caught it has to happen on the firmware image.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Testing a unit for this means becoming the thing it calls. Put the router on a bench network, answer for the hardcoded destination, and watch whether root commands land. That is precisely the position VulnCheck's exploit takes, alongside the PCAP, Nuclei template, ASM queries and Snort, Suricata and YARA rules in the coverage package [5]. It is a procedure involving a cable and a socket, not a query you run against an asset inventory.
Which makes the missing list the operational problem. The bulletin gives a count, more than 20 models, and not an enumeration of them [1][9]. Until models and firmware builds are named, an operator with a mixed fleet has no filter to apply, and no scan that would supply one.
Notice what the same bulletin can count. VulnCheck's Target Intelligence puts 7,100-plus exposed vulnerable Ruby on Rails instances on the board [6] and roughly 1,115 internet-exposed vCenter servers [7]. For the Zbtlink fleet there is no exposure figure at all [8]. That follows from the mechanism rather than from any gap in the tooling: both of those numbers come from finding things that listen, and this implant originates the connection instead [3].
The rest of the week's list is inbound work by comparison. The Rails Active Storage bug is an unauthenticated file read to RCE [10]. One vCenter flaw lets an attacker with network access sign in as full administrator [11]; the other lets an unauthenticated attacker plant a file that runs as root [12]. The SMB escalation needs any valid user credential [13]. So four of the five require no credentials [14], and three of those four are reached by connecting to the target. The fourth is reached by answering when the target calls you.
That is why the acceptance test has to read the image, and reading is not the same as checking a signature. A signature tells you the firmware is the vendor's build; here the default-on root process is in the vendor's build [1][2]. The check that catches it is extraction and inspection: enumerate what init starts, note what runs as root, then boot the image on an isolated network and record what it dials [2][3]. Slow, and it needs someone who can read a squashfs.
In my context that is still the cheaper half of the problem, because I can put a gate in procurement and I cannot put a sensor on the transit path between a branch router and an address in somebody else's netblock. If your leverage runs the other way, invert the priority. The thing not to do is treat a clean port scan as evidence, because on this device a clean port scan is the expected result [3].
Ranked by verification strength, evidence, and original report placement.
VulnCheck disclosed ENDLESSDOORS, a remote-control implant in the firmware of 20+ Zbtlink router models, tracked as CVE-2026-66747, Zbtlink Router ENDLESSDOORS Implant Unauthenticated Root Code Execution.
The ENDLESSDOORS implant is enabled by default, starts at boot, and runs as root.
Unlike a conventional remote vulnerability, ENDLESSDOORS opens no listening port; it is a fully outbound phone-home implant that dials a hardcoded C2 server over cleartext TCP with no authentication and no transport encryption.
Because the channel is unauthenticated and cleartext, control is not limited to whoever planted the implant: anyone who answers at the C2 address, or who can occupy the network path between the router and that address, obtains root command execution on the device.
VulnCheck created an exploit that takes the C2 / adversary-in-the-middle position; coverage also includes a PCAP, a Nuclei template for non-intrusive scanning, ASM queries, and Snort, Suricata and YARA rules.
VulnCheck Target Intelligence identifies 7,100+ exposed vulnerable instances of Ruby on Rails in connection with CVE-2026-66066.
Distinct publishers with included, body-backed reporting in this cluster.
Follow any of these and your For You feed starts watching them — no settings page required.
security
A vCenter bug patched on July 29 is already a ransomware chain, not a ticket1 distinct publisher
build
An all-zero MAC address bypasses the root command check in ZBT-derived white-label routers2 distinct publishers
security
ZBT router firmware ships two factory implants that beacon out on UDP/100001 distinct publisher
product
Two Nim implants shipped inside a US-branded router VulnCheck bought on Amazon1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Deep detail, one witness
The technical account is the kind you can act on: no listening port, cleartext outbound TCP to a fixed address, root from boot, and a working exploit that proves the intercept position. It also comes entirely from the company that found it, with no second telling and no model list to check it against. Specificity is doing the work here that corroboration normally would.
Breadth asserted, reach uncounted
Twenty-plus models with the implant on by default is real breadth, but breadth of models is not a count of devices, and this bulletin never gives one. The striking part is that it gives counts for everything else — 7,100-plus Rails instances, about 1,115 vCenter servers — which shows the measurement capability exists and simply was not pointed at the routers.
Mechanism holds, scale floats
Nothing about the failure is exaggerated — an unauthenticated cleartext channel really does hand root to whoever answers, and VulnCheck resists the temptation to claim in-the-wild abuse. The stretch is in the reach. '20+ models' does the rhetorical work of a scale number while telling you neither which models nor how many devices, and no one outside the vendor has weighed in.
The bulletin is the product
This is a subscriber deliverables post: the finding, the exploit, the detection rules and the exposure statistics are all things VulnCheck sells or sells access to. That does not make any of it wrong, and the restraint about unexploited flaws reads as honest. But the counts that establish urgency are generated by the same commercial telemetry the post exists to advertise, and Zbtlink — the party with the opposite interest — is absent.
Believable, unchecked, slightly stale
Internally the account is consistent and technically legible, and the pattern across the week — four of the five flaws needing no credentials, exploits paired with detections — is coherent. Confidence is held down by there being one voice, no vendor response, and a three-week lag between the bulletin's 7 August date and its arrival in our coverage, during which nobody appears to have added anything.