Answering one hardcoded address gives you root on 20+ Zbtlink router models

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][14]. 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 ^[13]. 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 ^[8]. One vCenter flaw lets an attacker with network access sign in as full administrator ^[9]; the other lets an unauthenticated attacker plant a file that runs as root ^[10]. The SMB escalation needs any valid user credential ^[11]. So four of the five require no credentials ^[15], 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].