BRIDGE:BREAK — one request to root on an internet-exposed OT device
CVE-2025-67038 is an unauthenticated, root-level command injection in Lantronix EDS5000 serial-to-IP converters — KEV-listed, exploited in the wild, and a pivot into OT.
Some bugs are dangerous because they're clever. CVE-2025-67038 is dangerous because it's simple, it's on a device that should never have been on the internet, and it lands you at the doorway to an operational-technology (OT) network. It's part of Forescout Vedere Labs' "BRIDGE:BREAK" research — 22 flaws across Lantronix and Silex serial-to-IP converters, roughly 20,000 of which are exposed online.
The Lantronix EDS5000 family (EDS5008 / 5016 / 5032) are serial-to-Ethernet device servers — they bridge legacy serial equipment (PLCs, RTUs, sensors, medical and POS devices) onto IP networks. That bridging role is exactly why a remote root compromise is so serious: the box is a pivot into the serial gear behind it.
How one request becomes root
The device runs OpenWRT, and its LuCI web stack logs failed logins by building a log line that concatenates the submitted username and passes it to the system shell via os.execute — with no sanitization, and as root. Because the logging fires on the failed-auth path, an attacker needs no valid account: a single login attempt whose username contains shell metacharacters, POSTed to /cgi-bin/luci/rpc/auth, runs attacker commands.
Every metric in the CVSS 9.8 score is justified: network-reachable (AV:N), low complexity (AC:L), no privileges (PR:N), no user interaction (UI:N), full impact. Unlike a client-side parser bug, there's no asterisk — it's unauthenticated remote root in one request.
The attack chain
One unauthenticated request to root — then an OT pivot
- Find an exposed EDS5000 — Internet-reachable Lantronix serial-to-IP converter with its LuCI web interface (`/cgi-bin/luci`) answering.
- Unauth POST to rpc/auth — A single login request to `/cgi-bin/luci/rpc/auth` with shell metacharacters in the **username** — no valid account needed.
- Runs as root — The failed-login log path passes the username to `os.execute` **as root** — code execution with one request.
- Outbound staging — The injected command pulls a payload from C2 (`wget`/`curl`). A serial converter has **no legitimate reason** to egress — a high-fidelity tripwire.
- Pivot into the OT network — Root on the bridge = a foothold into the serial-attached OT gear it fronts. Mitigation: take it off the internet, segment, and patch.
Exploited before most people heard of it
Lantronix shipped a fix around 2026-02-20, and the CISA ICS advisory (ICSA-26-069-02) followed in March. But Forescout's honeypots saw in-the-wild exploitation from 2026-04-05 — after the patch, before the public write-up — meaning attackers reverse-engineered the patch rather than waiting for a PoC. CISA added it to KEV on 2026-06-23 with a federal deadline of 2026-06-26 that has now passed.
The observed activity (a cluster Forescout tracks as "Chaya_006") was targeted, not a botnet — Lantronix-specific fingerprinting, capability-test downloaders, but no malware or ransomware retrieved. There's no public proof-of-concept yet (the one GitHub repo bearing the CVE id is an empty placeholder). But make no mistake: an unauthenticated-root-on-embedded-Linux bug is exactly the profile that commodity botnets adopt the moment a PoC drops.
Find it, then detect attempts
These are often unmanaged OT assets missing from IT inventories. Find the devices (Lantronix Discovery on UDP/30718, config on TCP/9999, or the LuCI web title), and confirm whether the /cgi-bin/luci interface is reachable from anywhere untrusted. Because this is a network-listening service, you can also sign the request on the wire — a defensive Suricata starting point:
# Detection (defensive) — POST to the LuCI auth RPC carrying shell metacharacters
alert http any any -> $HOME_NET any ( \
msg:"CVE-2025-67038 Lantronix EDS5000 LuCI rpc/auth cmd-injection attempt"; \
flow:to_server,established; http.method; content:"POST"; \
http.uri; content:"/cgi-bin/luci/rpc/auth"; \
http.request_body; content:"|22|params|22|"; \
pcre:"/\x22params\x22\s*:\s*\[\s*\x22[^\x22]*(?:\$\(|`|wget|curl|busybox)/i"; \
classtype:attempted-admin; sid:1900670381; rev:1; )The single highest-fidelity signal needs no signature at all: a serial-to-IP converter making an outbound connection. These devices have no legitimate reason to initiate egress — alarm on it. And because exploitation predates the KEV add, patching is not all-clear: hunt for failed-auth log entries with metacharacter usernames and for the campaign's lntxe1…lntxea markers.
Fix it
- Take it off the internet. These are OT/serial servers that should never be internet-facing — removing public reachability is both the strongest mitigation and just correct architecture.
- Upgrade the firmware to EDS5000 2.2.0.0R1 (companion EDS3000PS 3.2.0.0R2). Confirm the exact build against Lantronix's advisory. In OT, isolation and flashing aren't free — plan a change window, back up the config, get asset-owner sign-off.
- Segment & restrict the management interface — firewall it off the business network, source-IP allowlist
/cgi-bin/luci, VPN-only remote access. - Hunt for prior compromise — exploitation began months before the KEV listing, so "we patched" is not "we weren't hit."