Lantronix EDS5000: how a log-write command injection reaches root

On 23 June 2026, CISA added CVE-2025-67038 to its Known Exploited Vulnerabilities catalog: a code injection flaw in Lantronix EDS5000 serial-to-IP console servers, rated CVSS 9.8, already seeing exploitation in the wild. The mechanism is textbook OS command injection, which makes it a clean teaching case for why concatenating untrusted input into a shell command is one of the oldest and most reliable ways to lose a box.

What the bug class is

OS command injection happens when a program builds a shell command string out of attacker-controlled data and hands the result to a system shell. The shell does not know which bytes the developer intended as data and which it should treat as syntax. Characters such as ;, |, &&, backticks, and $() are command separators and substitution operators. If any of them survive into the string, the attacker is no longer supplying an argument. They are writing the command.

This is distinct from code injection into the application's own language and from SQL injection into a database. The target here is the operating system, and the prize is whatever privilege the calling process holds. On embedded and edge devices, that process is very often running as root.

How CVE-2025-67038 works

According to the disclosure, the EDS5000 HTTP RPC module shells out to write a log entry when an authentication attempt fails. The supplied username is concatenated directly into that command with no escaping or validation. An attacker who sends a crafted username does not need valid credentials, because the vulnerable path runs on the failure branch. The injected commands execute with root privileges. In effect, the act of failing to log in is what triggers code execution.

The dangerous line is not the login check. It is the log writer that trusts a field an unauthenticated client fully controls. recurring pattern in embedded management interfaces

Conceptually, the vulnerable construction looks like the first version below. The fix is the second.

// vulnerable: username flows straight into a shell
snprintf(cmd, sizeof cmd,
         "echo 'failed login: %s' >> /var/log/auth", user);
system(cmd);            // user = "x'; id > /tmp/o #" -> runs id as root

// fixed: no shell, argument passed as data
char *argv[] = { "/usr/bin/logger", "-t", "auth", line, NULL };
execv(argv[0], argv); // shell metacharacters are now inert

Who is affected and the deadline

• Devices: EDS5000, EDS5008, EDS5016, and EDS5032 serial-to-IP console servers.
• Vulnerable firmware: 2.1.0.0R3. Lantronix released a fix in 2.2.0.0R1.
• CISA action: the flaw was added to the KEV catalog and, under Binding Operational Directive 22-01, Federal Civilian Executive Branch agencies were directed to remediate by 26 June 2026.

The flaw was reported by Forescout Research Vedere Labs in April 2026 as part of a cluster of serial-to-IP device issues collectively named BRIDGE:BREAK. The same KEV update also flagged actively exploited command injection in Ubiquiti UniFi OS, which is a useful reminder that this bug class is not specific to one vendor. It tracks a coding habit, not a brand.

How to defend it

The durable fix is to stop using a shell as a string interpreter for untrusted data:

• Avoid the shell entirely. Call the target binary with an argument vector (execve, posix_spawn, or subprocess.run([...], shell=False)) so input lands as a single argument, never as syntax.
• Validate against an allowlist. If a field is a username, constrain it to the characters a username may legally contain and reject the rest. Denylisting individual metacharacters tends to miss one.
• Drop privileges. A log writer does not need root. Least privilege turns a full compromise into a contained one.
• Segment the management plane. Console servers should not be reachable from general or internet-facing networks. Isolation shrinks the attack surface even before a patch lands.
• Patch on the published timeline. Active exploitation plus a fixed firmware build means upgrading to 2.2.0.0R1 is the priority action, not a backlog item.

Reproducing the bug class in a lab

You do not need the affected hardware to understand this. Stand up a small web handler that logs a request field by calling out to a shell, then watch a separator escape the intended command. Keep it on an isolated network and treat it as a learning target only.

Send a benign value first to confirm normal logging, then send a value containing a separator and an observable side effect, such as writing a marker file. If the marker appears, your input crossed from data into command. Now swap the system() call for an argument-vector exec and confirm the same input is written verbatim to the log with no execution. That before-and-after is the entire lesson: the vulnerability was never the username, it was the decision to let a string become a command.