CISA Alert: Lantronix EDS5000 (CVE-2025-67038) Under Active Attack
Just saw the CISA drop on CVE-2025-67038 regarding the Lantronix EDS5000 series. It's rare to see a CVSS 9.8 on these types of console servers, but this code injection flaw allows for unauthenticated RCE. Since these devices frequently sit on the management plane for critical infrastructure, the blast radius here is massive.
The FCEB deadline is June 26, 2026, but if you have these exposed to the internet—even with VPNs—I'd treat this as an emergency. The bug is in the web management interface, so standard bastion host usage might not save you if the internal network is compromised.
I'm currently scanning our subnets to ensure we have a full inventory. Here is a quick Python snippet to help identify the devices via their HTTP headers:
import requests
from urllib3.exceptions import InsecureRequestWarning
requests.packages.urllib3.disable_warnings(category=InsecureRequestWarning)
def check_lantronix(ip):
try:
r = requests.get(f"https://{ip}/", timeout=3, verify=False)
if "Lantronix" in r.headers.get('Server', ''):
print(f"[+] Found Lantronix device at: {ip}")
except Exception:
pass
# Example: Sweep a specific range
for i in range(1, 254):
check_lantronix(f"10.0.0.{i}")
For those in OT environments, are you seeing any weird traffic patterns on port 443 or 22 from these units? Also, how painful is the firmware update process for you?
Good catch on the inventory script. We found three units we thought were decommissioned still sitting on a legacy VLAN. Patching is going to be a nightmare since two of them are in remote RTU cabinets. We're trying to push the update via their central manager, but if the web interface is the attack vector, I'm wary of touching it until we isolate the VLAN. Anyone else successfully pushed the patch remotely without bricking them?
We started detecting anomalous POST requests to /port_1 on our Lantronix units yesterday morning. It looks like the exploit is attempting to inject shell commands into the CGI scripts.
If you have SIEM coverage, I recommend hunting for this:
DeviceProduct == "Lantronix"
| where Uri contains "cgi-bin" and RequestMethod == "POST"
| where RequestBody has_content ";" or RequestBody has_content "&&"
The requests usually have a suspiciously high Content-Length for standard configuration pages.
The timing is awful—we are right in the middle of our PQC migration inventory per EO 14409 and now have to deal with active exploitation on legacy OT gear. The vendor advisory was light on details, but implying it's a code injection suggests input validation failure on the web forms. I'm advising my team to block internet access to these management interfaces entirely and use jump hosts with strict allow-listing until we can patch.
Validating Steve's findings, we're observing similar scans targeting /port_1. To help with immediate detection while patching is underway, you can use this Snort/Suricata rule to catch the injection attempts on the wire:
alert tcp any any -> any 80 (msg:"Lantronix EDS5000 Exploit Attempt"; flow:to_server,established; content:"POST"; http_uri; content:"/port_1"; nocase; sid:1000001; rev:1;)
Given the difficulty of patching remote RTUs, network segmentation remains your best defense against lateral movement.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access