Look, the physical issue here is not “data theft” — it is compromise of Purdue Level 3 / 3.5 infrastructure that can sit on the path to controllers, engineering workstations, historians, and remote access choke points. For Lantronix EDS5000, the evidence I found ties CVE-2025-67038 to EDS5000 firmware 2.1.0.0R3 and describes it as root-privilege command execution; that makes these devices serious pivot points in OT networks, especially where they bridge serial/field gear into Ethernet segments. For Siemens, CISA’s OpenSSL advisory covers a broad set of industrial products using OpenSSL, including SCALANCE and other industrial networking / automation families, and the flaw is described as a stack-based buffer overflow that can lead to DoS and potentially RCE.
Are these likely in critical environments? Yes, especially the Siemens side. The advisory inventory includes industrial networking, automation, and plant software families that are common in critical infrastructure. Lantronix EDS devices are less ubiquitous than Siemens gear, but EDS-class serial-to-Ethernet edge devices are exactly the kind of thing I expect to find in plants where legacy PLCs, meters, drives, or serial maintenance ports need network reach. In practice, both are exposed at the OT edge: directly reachable from Level 3/3.5, reachable via maintenance networks, or reachable through vendor/service paths. If either device is internet-exposed or reachable from IT without tight filtering, the blast radius is ugly.
On patch gaps: the Siemens advisory explicitly says some products have updated versions, while others require mitigations until fixes are available. I do not have enough evidence in-hand to say which specific Siemens sub-families in your environment are fully patched versus constrained by maintenance windows, so I’d treat this as “assume patch lag exists until proven otherwise.” For Lantronix, I only have evidence that EDS5000 2.1.0.0R3 is affected; I do not have a vendor remediation note visible here, so immediate upgrade feasibility is unknown. Operationally, if firmware upgrades are not possible, apply compensating controls now: isolate these devices in a dedicated OT management zone, restrict management access to jump hosts only, block direct IT and internet reachability, enforce ACLs so only required protocol peers can talk to them, disable unused services and remote admin paths, and monitor for unexpected reboots, config changes, or outbound sessions.
Hunt signals I’d use: inventory for EDS5000 / EDS5008 / Siemens SCALANCE and related OpenSSL-using Siemens assets; look for management-plane access from non-OT subnets; alert on configuration changes, firmware version changes, admin logins outside maintenance windows, and unusual child processes or shell execution on Lantronix edge devices. For Siemens gear, watch for repeated service crashes, watchdog resets, and anomalous TLS/management traffic to devices that normally only handle deterministic OT protocols. If you want, I can turn this into a plant-facing triage list by device class and Purdue zone.