# [HIGH] 22 BRIDGE:BREAK Flaws Expose Thousands of Lantronix and Silex Serial-to-IP Converters **Source:** The Hacker News **Published:** 2026-04-21 **Article:** https://thehackernews.com/2026/04/22-bridgebreak-flaws-expose-20000.html **Curated:** Analyst-reviewed 2026-04-28 ## Threat profile Forescout Vedere Labs disclosed **22 vulnerabilities — collectively "BRIDGE:BREAK"** — in **Lantronix and Silex serial-to-Ethernet converters**. They identified **~20,000 such devices Internet-exposed**. Serial-to-IP converters bridge legacy serial-protocol equipment (PLCs, building-automation controllers, medical devices, retail POS terminals, ATMs, weighing scales, voting machines, manufacturing line equipment) onto IP networks. This is **OT/IoT exposure with IT-pivot risk**: - These devices typically sit on the IT network with the serial side facing critical legacy equipment. - Compromise lets the attacker tamper with the legacy data stream (manipulate readings, replay commands) AND use the device as a foothold inside the IT network. - 20,000 directly exposed is the *internet-facing* count — most enterprises have many more on internal networks that are reachable post-foothold. The Forescout disclosure pattern (BRIDGE:BREAK, INFRA:HALT, OT:ICEFALL, etc.) is the canonical "broad family of related bugs in similar devices" — patches will land model-by-model and vendor-by-vendor, often with months of lag, and many devices **will never be patched** because they're orphaned, embedded in larger systems, or running last-supported firmware. We've upgraded severity to **HIGH** on enterprise impact + visibility of the vulnerable population (20K Internet-exposed is real attack surface). ## Indicators of Compromise - 22 CVEs under the BRIDGE:BREAK label — confirm exact CVE list from the Forescout advisory. - Affected vendors / models: **Lantronix** EDS / SLB / SLC / xPico families, **Silex** SX-3000 / SD-330 / DS-510 series — confirm specific affected models from advisory. - Internet exposure shape: TCP **3001** (Lantronix Telnet), **9999** (Lantronix setup), **80/443/30718** (web admin), **9100** (raw TCP serial-tunnel), **161** (SNMP). ## MITRE ATT&CK (analyst-validated) - **T1190** — Exploit Public-Facing Application - **T1133** — External Remote Services (the converter exposed to Internet IS the remote service) - **T1078** — Valid Accounts (default / hardcoded credentials are common across both vendors) - **T1565.002** — Stored Data Manipulation (tampering with the serial data stream) - **T1542** — Pre-OS Boot / firmware persistence (likely for some of the 22 CVEs) - **T1571** — Non-Standard Port (the serial-tunnel TCP/9100 / TCP/3001 traffic patterns) ## Recommended SOC actions (priority-ordered) 1. **Inventory.** Engage facilities, OT, building-automation, and manufacturing teams. Ask: *"do we use Lantronix or Silex serial-to-IP converters anywhere?"* Most SOCs have no asset record of these — they were installed by a vendor 8 years ago and forgotten. 2. **External attack-surface scan.** Search Shodan/Censys for the device banners; cross-reference your owned IP space. If anything you own appears, it should be off the Internet by Friday. 3. **Internal network segmentation review.** These devices should not be reachable from the user VLAN — they should sit in OT segments behind firewall rules. 4. **Detect serial-tunnel traffic on unexpected segments.** Hunt below. 5. **Update default credentials.** Many devices ship with `admin/PASS` or no password — far more likely than firmware patching to actually move the security needle. ## Splunk SPL — outbound to Lantronix / Silex serial-tunnel ports ```spl | tstats `summariesonly` count from datamodel=Network_Traffic.All_Traffic where (All_Traffic.dest_port IN (3001,9999,9100,30718) OR All_Traffic.src_port IN (3001,9999,9100,30718)) by All_Traffic.src, All_Traffic.dest, All_Traffic.dest_port, All_Traffic.src_category, All_Traffic.dest_category | `drop_dm_object_name(All_Traffic)` | stats sum(count) AS sessions, dc(dest) AS unique_dests by src, dest_port | sort - sessions ``` ## Splunk SPL — admin-port web access from non-IT subnets ```spl | tstats `summariesonly` count from datamodel=Web where (Web.url="*setup*" OR Web.url="*config*" OR Web.dest_port IN (80,443,30718)) AND Web.user_agent IN ("*Lantronix*","*Silex*","*Mozilla/4.0 (compatible; MSIE 6.0;*") by Web.src, Web.dest, Web.dest_port, Web.url, Web.user_agent | `drop_dm_object_name(Web)` ``` ## Splunk SPL — exposure scan (vuln data model) ```spl | tstats `summariesonly` count from datamodel=Vulnerabilities where (Vulnerabilities.signature="*Lantronix*" OR Vulnerabilities.signature="*Silex*" OR Vulnerabilities.signature="*BRIDGE:BREAK*") by Vulnerabilities.dest, Vulnerabilities.signature, Vulnerabilities.severity | `drop_dm_object_name(Vulnerabilities)` | sort - severity ``` ## Defender KQL — serial-tunnel port traffic from managed hosts ```kql DeviceNetworkEvents | where Timestamp > ago(30d) | where ActionType == "ConnectionSuccess" | where RemotePort in (3001, 9999, 9100, 30718) or LocalPort in (3001, 9999, 9100, 30718) | project Timestamp, DeviceName, LocalIP, LocalPort, RemoteIP, RemotePort, InitiatingProcessFileName | order by Timestamp desc ``` ## Defender KQL — vuln exposure (if devices are managed) ```kql DeviceTvmSoftwareVulnerabilities | where SoftwareVendor has_any ("lantronix","silex") or CveId has "BRIDGE-BREAK" | join kind=inner DeviceInfo on DeviceId | project DeviceName, OSPlatform, SoftwareVendor, SoftwareName, CveId, VulnerabilitySeverityLevel, RecommendedSecurityUpdate | order by VulnerabilitySeverityLevel desc ``` ## Defender KQL — admin web traffic to suspected devices ```kql DeviceNetworkEvents | where Timestamp > ago(30d) | where RemoteUrl has_any ("/setup.htm","/config.htm","/admin.htm","setup.cgi") and RemotePort in (80, 443, 30718) | project Timestamp, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc ``` ## Why this matters for your SOC Serial-to-IP converters are **a perfect blind spot**: they're not in CMDB, not under EDR, and live on networks that nobody's vuln scanner has authority to scan. The 20,000 figure in the Forescout report is *Internet-exposed*; your real population is much larger across factory floor, building automation, and back-of-house. The single highest-leverage action is **discovery** — you can't defend what you don't know exists. Run the port-based hunts above as a discovery exercise; serial-tunnel ports (3001, 9999, 9100, 30718) on your network indicate these devices regardless of what your asset management says. Once you find them, segmentation matters more than firmware patching — these devices won't get patched, but they don't need to be reachable from user space either.