CVE-2025-67038, CVSS 9.8, is a command injection vulnerability in Lantronix EDS5000 device servers, version 2.1.0.0R3. CISA added it to the Known Exploited Vulnerabilities catalogue on 23 June 2026. The mechanism, per NVD, is almost comically direct: the HTTP RPC module executes a shell command to write logs when a user's authentication fails, and the username submitted at login is concatenated directly into that command with no sanitisation.
Why this specific mechanism deserves attention beyond its own device category
A device server is embedded networking hardware — the category of product that bridges serial or industrial equipment onto an IP network, common in operational technology, building automation, and industrial control environments where legacy serial devices need network connectivity without being replaced entirely. This particular bug is worth understanding closely because its mechanism is a nearly ideal teaching example of command injection: a failed-login event triggers a logging action, that logging action shells out to write the log entry, and the attacker-supplied username — precisely the field an unauthenticated attacker controls completely, since they're the one attempting to log in — is inserted into the shell command without sanitisation. An attacker never needs a successful login. The vulnerability triggers on every failed attempt, meaning the exploit is the login attempt itself.
Why embedded device servers are a persistently under-monitored category
Device servers like the EDS5000 are typically deployed once, during an industrial or facilities integration project, and then operate unattended for years — often managed by an operations or facilities team rather than IT security, and frequently invisible to vulnerability scanning tools tuned for conventional IT assets. That combination of long unattended uptime and limited security visibility is exactly the profile that lets a vulnerability this severe, and this mechanically simple to exploit, go unpatched for an extended period even after public disclosure.
A textbook case worth keeping for training purposes
Beyond its own remediation, this specific vulnerability is worth using as a concrete example when explaining command injection to a development team, precisely because the mechanism requires no obscure conditions to understand: a value the application logs, sourced directly from unauthenticated user input, is passed to a shell without sanitisation. Every element of that sentence is a well-known anti-pattern individually — logging attacker-controlled input verbatim, and passing any string to a shell without escaping — and this CVE is what happens when both appear in the same code path at once. Reviewing your own logging and audit-trail code for the same combination, not just this specific device, is a reasonable and low-cost exercise this finding justifies.
What to check this week
Identify every Lantronix EDS5000 device actually deployed, which for many organisations means checking with operational technology or facilities teams directly rather than relying on an IT asset inventory that may not include embedded serial-to-network hardware.
Patch or isolate immediately. With the exploit trigger being nothing more than a login attempt with a malicious username, no authentication bypass or prior access is needed — this is about as low a bar for exploitation as this class of vulnerability gets.
Restrict network reachability to the device's management interface as a compensating control wherever patching isn't immediately possible, particularly for devices integrated into operational technology environments where patch windows are constrained by production uptime requirements.
Why "we don't have any of these" is worth verifying, not assuming
Device servers of this kind are frequently installed by a systems integrator during a facilities or industrial-automation project, with the purchasing and deployment decision made entirely outside any process an IT security team would normally review. The honest starting point for most organisations is not "do we have Lantronix EDS5000 units," but "how would we find out if we did" — and if the answer involves anything less certain than a definitive asset inventory covering operational technology alongside conventional IT, that gap is the actual finding worth acting on here.
How Safeguard helps
Safeguard's continuous inventory extends into embedded and operational-technology-adjacent hardware, precisely the category most likely to be invisible to conventional IT asset management and most likely to run for years without a security review. Identifying devices like the EDS5000 as part of a unified inventory — rather than as a blind spot between IT and OT teams — is what turns "we might have some of these somewhere" into a concrete, checkable answer.
