22 Bugs in the Box Between Your Serial Cable and the Internet
Walk into any older industrial site, or any hospital that still runs equipment from before 2015, and you will find a small grey box bolted to a rack. One end has a 9-pin serial port, sometimes a couple of them, going into a PLC or a medical device or a building management controller. The other end has an Ethernet jack going into the IP network. The label on the front says Lantronix or Silex. Nobody on the IT team owns it. Nobody on the OT team owns it. It is the seam between two operational kingdoms, and seams are where you find blood.
Forescout published BRIDGE:BREAK on Monday, April 21. Twenty-two vulnerabilities across the Lantronix EDS3000PS, EDS5000, and the Silex SD330-AC. Nine of those are remote code execution: CVE-2026-32955, CVE-2026-32956, CVE-2026-32961, and CVE-2025-67034 through 67038 plus 67041. The rest cover authentication bypass, denial of service, firmware tampering, configuration tampering, and information disclosure. Forescout ran an internet exposure sweep at disclosure time and counted nearly 20,000 of these devices reachable from the public internet, with the heaviest density in healthcare and OT.
Why This Matters More Than Another OT Bug
I want to be specific about what a serial-to-IP converter actually does, because the threat model of "compromise this device" is meaningfully different from "compromise this server".
The converter is the protocol bridge. The PLC or the medical device speaks something old: Modbus over RS-485, BACnet over MS/TP, sometimes a vendor proprietary serial protocol that has not been documented since the early 2000s. The converter terminates that serial line and republishes the same data as a TCP stream that the SCADA system, the historian, or the EHR can talk to.
If you control the converter, you can lie in both directions. You can tell the SCADA system that the pump is running normally while the pump is actually off. You can tell the pump to run while the SCADA system thinks you sent a stop. You can replay yesterday's vital signs to the EHR while the patient monitor is showing something else entirely. None of the endpoint protections on either side will catch you because, from their perspective, the data is coming from the device they trust.
The nine RCE bugs are the loud finding. The boring information disclosure bugs are arguably worse, because they leak the credentials and config that let an attacker stage the lying campaign without ever needing the loud exploit.
The Patch Reality
Lantronix and Silex have shipped fixes. That is the good news. The bad news is that this device class has terrible patch hygiene historically. Six months after a notable converter advisory, internet-exposed instance counts typically come down by 15 to 20 percent. The other 80 percent never patch, because nobody owns the box, the maintenance window is annual, and the OT team will not approve any change that requires rebooting the converter during plant operations. Hospitals are even worse, because the device sits inside a clinical workflow that has compliance signoff and the bioengineering department cannot touch it without a change request.
Patching is the right answer. It is not the realistic answer for most of the affected fleet.
What to Actually Do This Week
Three things, in order.
One, find the boxes. If you have an OT segment, your IT-side asset inventory does not have these. Do a passive scan or pull the ARP tables from the switch ports facing the OT VLAN. Look for the Lantronix and Silex MAC OUI prefixes. Count what you find. That count is your real exposure number, and it will not match what your CMDB says.
Two, kill the public internet exposure if you have any. There is no version of "this device should be reachable from the internet" that is correct in 2026. If your remote engineering team needs serial-over-IP access from outside the plant, route them through a jump host with MFA. The vendor instructions from 2014 that say "just port-forward the converter" are wrong now and were arguably wrong then.
Three, segment the converter. The single highest-impact mitigation that does not require patching is to put the converter on its own VLAN, allow only the SCADA host or the historian to talk to it, and block everything else. If you cannot patch and you cannot replace the device, you can at least make sure that compromising it does not give the attacker a free ride into the rest of the OT environment.
The recurring lesson with serial-to-IP converter bugs is that the device is invisible to whoever owns the network and load-bearing for whoever owns the process. BRIDGE:BREAK is going to be exploited. The question is whether you will see it happen on your fleet, and the answer to that question depends entirely on whether you bothered to find the boxes before someone else did.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you'd rather know about your weak spots from a friendly face.