Loading today’s stories
Product1 distinct publisher3 min readPublished
VulnCheck rooted a Deep Orange LTE router sold by a US supplier and found a WAN-facing backdoor listening on UDP 9992, plus a hard-coded checksum key that names the Chinese OEM behind the firmware.
The Product Desk · Product desk
Compiled by The Product DeskSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
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
build
Honeypots logged a SharePoint JWT bypass hunting for a Business Data Catalog sink1 distinct publisher
build
Your test grid is an RCE surface: SeleniumGreed turns exposed Selenium hubs into miners2 distinct publishers
A router with an English brand name, bought from a US seller and installed in a branch office, gave its owner no reason to look at UDP 9992. That is where DARKLANTERN listens, running as a service called infosrvd, and according to VulnCheck the router's default firewall explicitly accepts inbound packets to that port from anywhere on the internet [10].
The protocol, which the binary internally calls revProto, is unauthenticated and unencrypted, with two packet types [11]. The first is a 19-byte info probe: send it to UDP 9992 and the device answers on UDP 8897 with its model, firmware version, MAC address, uptime and other identifying fields [12]. VulnCheck published one such reply from a device in Ukraine with the model, MAC, SSID and public IP all in the clear [13]. The second is a command packet, type 0x17, whose payload is handed to system("/etc/exec/cmd " + payload), where a semicolon escapes the fixed prefix and there is no length limit and no character filtering [14]. VulnCheck's own summary of that: one packet for a root shell over the internet [22].
Two fields are supposed to gate the command packet. The first is a four-byte checksum, taken as the last four hex characters of md5 over the string "mqonu.com" plus the payload, with the key hard-coded in the backdoor and therefore unchangeable, so anyone who reads the binary can compute a valid token for any payload [15]. Four hex characters is 16 bits, which leaves 65,536 candidate values for someone who never recovered the key at all [19]. The second gate compares a six-byte MAC field against /tmp/mac.txt and drops mismatches, a check that the 19-byte probe undercuts by returning the device's MAC on request [17], and VulnCheck reports a hard-coded bypass in the check as well [18].
The string "mqonu.com" is never contacted. VulnCheck reads it as a reference to MoreQuick, the Chinese OEM that developed the firmware for this ZBT-WE826-T2, which makes the salt a provenance marker rather than a network artifact [16]. Both implants are written in Nim, both communicate over UDP, and both are launched by the same binary, a connectivity watchdog called inetdetect [9]. The launcher wears a plausible utility name. The identity of the firmware author sits inside a hash salt instead of on the label.
Buyers who order network hardware actually check the brand, the seller's location, maybe a spec sheet. Teams tell themselves those things establish custody over the code that ships. Sorting a fleet takes two questions, neither about the badge. Can anyone name the firm that wrote the firmware, and can anyone get a shell on a sample unit and enumerate what it listens on. Both answers yes, and there is something to govern. Knowing the OEM without being able to inspect the unit just means trusting a company the buyer never selected. Being able to inspect the unit without knowing the OEM means each firmware update resets the evidence. Without either, the brand name is carrying the whole assurance argument. Here that amounts to a sticker over someone else's firmware.
Ranked by verification strength, evidence, and original report placement.
VulnCheck stood up a sinkhole for a forgotten domain and implant beacons hit it immediately: hundreds of routers, almost all in China, beaconing home.
VulnCheck found the sinkholed domain obfuscated in the firmware of a router it bought on Amazon from a small company in New York, and now owns the domain and the implants.
VulnCheck's earlier post detailed ENDLESSDOORS, a phone-home implant vulnerable to man-in-the-middle attacks, embedded in ZBT routers.
FCC filings, patent records and archived web pages tied ZBT hardware to brands across the United States, Canada, Australia, the Philippines, Germany and Russia.
VulnCheck bought one router from a US supplier: the Deep Orange 3G/4G/LTE Router, a white-labeled ZBT-WE826-T2.
VulnCheck exploited a vulnerability in the telnet interface to root the device and found its firmware was built in 2019, predating ENDLESSDOORS, so ENDLESSDOORS was not present.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 29, 2026
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.
First-party artifacts, no second look
The technical spine is unusually checkable for a single-source story: the device's own iptables rule opening UDP 9992, the nineteen probe bytes in full, a captured response from a router in Ukraine, and a two-line Python recipe for forging the checksum. An engineer can re-derive most of it without trusting the author. What is absent is anyone outside VulnCheck — no ZBT or MoreQuick reply, no CVE, no second scan, and no confirmation that units still on sale carry this 2019 image.
203 counted, installed base unknown
Deployment here is counted rather than estimated: 203 internet-facing instances in 22 countries over four days, self-reporting sixteen distinct models, plus hundreds of sinkhole beacons concentrated in China. VulnCheck is candid that this is a floor and probably the tail end — the test firmware dates to 2019. The number nobody publishes is the one that matters downstream: how many of these boxes are sitting in Western networks under a Western brand label.
Mechanics exact, framing wider
The engineering lands precisely where it says it does — an open port, an unencrypted protocol, a forgeable token, an intentional MAC bypass, a payload concatenated into system(). The reach is in the vocabulary. "Chinese implants in the supply chain" invites a reading of outward intent, while what is actually documented is an OEM management channel built carelessly, indistinguishable in effect from a deliberate backdoor but not proof of one. The MoreQuick attribution carrying that framing is a nine-character salt.
The scanner is also the product
VulnCheck sells the internet scanner that produced the 203 figure and the vulnerability intelligence this research feeds, and the sinkhole gives it telemetry no competitor holds — "we own the implants" is a finding and a moat in one sentence. None of that makes the packet captures wrong. It does explain why this arrives as the second instalment of a series, with named implants, no advisory and no disclosure timeline attached.
Solid at packet level, thin above it
Two things pull against each other. The artifacts are strong enough that a sceptical engineer could reproduce the forged checksum before lunch, and the exposure count comes with dates and bounds. Yet one vendor blog is the entire record: no ZBT statement, no independent scan, no fleet operator confirming they found these devices. Read the protocol findings as reliable; hold the supply-chain story wrapped around them loosely until someone else checks it.