Lantronix EDS5000 Command Injection — CVE-2025-67038

CVE-2025-67038 is a CVSS 9.8 OS command-injection flaw in the Lantronix EDS5000 family of serial-to-Ethernet converters (EDS5008 / EDS5016 / EDS5032, firmware 2.1.0.0R3). These devices run an OpenWRT-based LuCI web stack. When HTTP authentication fails, the LuCI JSON-RPC module shells out to write a log entry and concatenates the supplied username directly into that shell command with no sanitization. An attacker sends a crafted failed-login request to /cgi-bin/luci/rpc/auth with shell metacharacters in the username field, and the injected commands run as root on the appliance.

The attacker objective is a foothold on an OT/ICS choke point: these converters bridge legacy serial automation gear to IP networks, so root on the device gives an adversary a pivot toward downstream physical/automation processes and a quiet vantage point inside the OT segment. Public disclosure came via the "BRIDGE:BREAK" research in April 2026; honeypot exploitation was observed 2026-04-05 through 2026-06-03, alongside a parallel LuCI credential brute-force campaign (~4,100+ attempts) from 2026-01-28 to 2026-06-06. CISA added the CVE to the KEV catalog on 2026-06-23. Roughly 31,850 internet-exposed OpenWRT LuCI devices were observed during the research.

Defensive reality (read this first): the EDS5000 is an embedded OT appliance — Falcon EDR does not run on it. There is no process/file/registry telemetry from the device itself. This hunt is therefore framed around the telemetry you do have: (1) network/proxy/firewall logs for inbound exploitation to /cgi-bin/luci/rpc/auth and connections involving the IOC IPs, (2) post-exploitation pivots landing on Falcon-covered Windows/Linux hosts that manage or talk to these devices, and (3) anomalous outbound traffic originating from the OT segment. Treat the appliance as an unmonitored root-capable box adjacent to your crown-jewel OT processes.

Defender priority: The device is patched only in EDS5000 2.2.0.0R1 (released 2026-02-20). Until every EDS5000 is upgraded and pulled off any internet-reachable path, assume the appliance can be rooted unauthenticated. Hunt the blast radius — the managed/engineering workstations and the OT segment egress — because that is where Falcon can actually see the adversary.

All facts and indicators in this pack trace to the five cited sources below. No IOC or claim was synthesized beyond what these sources state.

Web-hunter note: Atomic indicators are limited to two exploitation-source IPs and one threat-actor handle. There are no published file hashes or C2 domains for the appliance-side activity (expected — the implant lives on an embedded device with no public sample). The CSV import block in §10 therefore ships the two IPs as real values and uses REPLACE_WITH_… placeholders for any host-side artifacts you confirm during your own hunt.

Hunt hypotheses (ordered by fidelity)

Attack chain

No file hashes or C2 domains were published for the appliance-side implant — do not fabricate any. The two IPs and the endpoint/behavior signatures above are the complete atomic IOC set from the cited intel.

⚠ Tenant validation: Whether the EDS5000 sits behind a Falcon-monitored network sensor, and whether perimeter/OT-firewall HTTP logs are ingested into Falcon NGSIEM, is environment-specific. Confirm which of these feeds actually land in your repo before relying on §8 queries that assume web-log telemetry.

Because the appliance is EDR-blind, these non-Falcon checks carry the front-line detection weight. Run them against the telemetry where the EDS5000's exploitation actually shows up.

Web / proxy / WAF / OT-firewall logs

• Exploitation endpoint: any HTTP request to /cgi-bin/luci/rpc/auth destined for an EDS5000 / OT-segment device. Treat inbound from the public internet as a finding.
• Injection signature: requests to that path whose username JSON field contains shell metacharacters — ;, |, &&, backtick, $(, >, newline-encoded payloads.
• Brute-force precursor: bursts of failed LuCI logins — small username set (≈4) against a large password set (200+), totalling thousands of attempts over the 2026-01-28 → 2026-06-06 window.
• IOC source IPs: any request (success or fail) sourced from 38.207.136.2 or 218.13.42.36.

Appliance / device syslog (if forwarded)

• LuCI auth-failure log lines that contain unexpected shell output or command echoes — a side effect of the injected command running during the "log the failure" routine.
• Unexpected new processes, outbound connections, or config changes on the device in the exploitation window (2026-04-05 → 2026-06-03) — only visible if device logging is centralized.

Inventory / vulnerability management

• Enumerate every EDS5008/EDS5016/EDS5032 and confirm firmware. Any unit still on 2.1.0.0R3 (or anything below 2.2.0.0R1) is vulnerable and in scope.

Scope note: Falcon cannot see the appliance. Q1/Q3/Q4/Q6 hunt Falcon-host network telemetry (the pivot & egress blast radius); Q2/Q5 assume web/proxy logs have been ingested into NGSIEM and use snake_case parser fields — adjust the field names to your parser. Anything you must validate in-tenant is marked ⚠.

// HUNT: EDS5000 exploitation-IP touch on a Falcon host
// MITRE: T1190, T1078
// CONF: high  FP: low  COST: low | REQUIRES: NetworkConnectIP4
// FALSE POSITIVES: none expected — these IPs have no legitimate business use
#event_simpleName=/NetworkConnectIP4/
| in(RemoteAddressIP4, values=["38.207.136.2", "218.13.42.36"])
| table([ComputerName, aid, RemoteAddressIP4, RemotePort, LocalPort, ConnectionDirection, ContextBaseFileName], limit=200)

// HUNT: Command injection against LuCI /cgi-bin/luci/rpc/auth
// MITRE: T1190, T1059
// CONF: high  FP: medium  COST: low | REQUIRES: ingested web/proxy/WAF logs (NGSIEM)
// FALSE POSITIVES: normal LuCI logins on the same path; security scanners
// TUNING: exclude known OT-admin/jump-box source IPs; alert only when shell tokens present
url=/\/cgi-bin\/luci\/rpc\/auth/i
| request_body=/(?:[;`|]|\$\(|&&|%3B|%60|%7C)/
| table([@timestamp, src_ip, dst_ip, method, status, url, http_user_agent], limit=200)

// HUNT: Managed host beaconing to EDS5000 exploitation infra
// MITRE: T1078, T1071
// CONF: high  FP: low  COST: low | REQUIRES: NetworkConnectIP4
// FALSE POSITIVES: none expected for these specific IPs
#event_simpleName=/NetworkConnectIP4/
| ConnectionDirection=/0/
| in(RemoteAddressIP4, values=["38.207.136.2", "218.13.42.36"])
| groupBy([ComputerName, aid, RemoteAddressIP4], function=([count(as=hits), collect([RemotePort, ContextBaseFileName])]))
| table([ComputerName, aid, RemoteAddressIP4, RemotePort, hits, ContextBaseFileName], limit=200)

// HUNT: Unexpected internet egress from the OT/management segment
// MITRE: T1572, T1041
// CONF: medium  FP: medium  COST: medium | REQUIRES: NetworkConnectIP4 + OT-subnet definition
// FALSE POSITIVES: vendor update servers, NTP, DNS, monitoring callbacks
// TUNING: exclude approved OT egress destinations; replace 10.50.0.0/16 with your OT CIDR
#event_simpleName=/NetworkConnectIP4/
| ConnectionDirection=/0/
| LocalAddressIP4=/^10\.50\./
| RemoteAddressIP4!=/^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)/
| groupBy([ComputerName, RemoteAddressIP4, RemotePort], function=count(as=conns))
| conns >= 1
| sort(conns, order=desc)
| table([ComputerName, RemoteAddressIP4, RemotePort, conns], limit=200)

// HUNT: LuCI credential brute-force against OT web admin
// MITRE: T1110
// CONF: medium  FP: medium  COST: medium | REQUIRES: ingested web/proxy auth logs (NGSIEM)
// FALSE POSITIVES: monitoring probes, locked-out admins, scanners
// TUNING: raise the fail threshold to your environment baseline; exclude known probe IPs
url=/\/cgi-bin\/luci/i
| status=/40[13]/
| groupBy([src_ip, dst_ip], function=([count(as=fails), count(url, distinct=true, as=paths)]))
| fails >= 50
| sort(fails, order=desc)
| table([src_ip, dst_ip, fails, paths], limit=200)

// HUNT: Beacon-like egress from EDS5000 management hosts
// MITRE: T1071, T1572
// CONF: medium  FP: medium  COST: medium | REQUIRES: NetworkConnectIP4
// FALSE POSITIVES: update pollers, telemetry agents, CDNs
// TUNING: restrict ComputerName to mgmt/jump hosts; exclude approved beaconing endpoints
#event_simpleName=/NetworkConnectIP4/
| ConnectionDirection=/0/
| ComputerName=/^(MGMT|JUMP|ENG)-/i
| RemoteAddressIP4!=/^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)/
| groupBy([ComputerName, RemoteAddressIP4], function=([count(as=conns), count(RemotePort, distinct=true, as=ports)]))
| conns >= 12
| sort(conns, order=desc)
| table([ComputerName, RemoteAddressIP4, conns, ports], limit=200)

The appliance itself can't carry an IOA (no agent). The IOA opportunity is on the managed/Falcon-covered hosts in the blast radius. Promote sparingly — most queries here stay Investigate-only because the device-side execution is invisible.

Recommended IOC-Management entry: add both IPs as prevent on your managed-host policy and detect at the network layer. This is the one place Falcon can hard-stop blast-radius activity even though it can't see the device.

Quick-copy blocks for bulk ingestion and field hunts. The two exploitation IPs are real, published values; host-side artifacts use REPLACE_WITH_… placeholders to be filled from your own findings — no fabricated indicators.

type,value,action,severity,expiration,description,tags
ipv4,38.207.136.2,prevent,critical,2026-12-27,EDS5000 CVE-2025-67038 exploitation source,campaign:Lantronix-EDS5000
ipv4,218.13.42.36,prevent,critical,2026-12-27,EDS5000 CVE-2025-67038 exploitation source,campaign:Lantronix-EDS5000
domain,REPLACE_WITH_C2_IF_FOUND,detect,high,2026-09-27,EDS5000 pivot C2 (confirm in hunt),campaign:Lantronix-EDS5000
sha256,REPLACE_WITH_HOST_ARTIFACT,detect,high,2026-12-27,host-side artifact from pivot host,campaign:Lantronix-EDS5000

Endpoint    : /cgi-bin/luci/rpc/auth   (LuCI JSON-RPC auth)
Vector      : shell metacharacters in JSON "username" on FAILED auth
Tokens      : ;  |  &&  `  $(  >  newline-encoded payloads
Precursor   : LuCI brute-force — 4 usernames / 200+ passwords / ~4100+ tries
Actor handle: Chaya_006
Window      : exploit 2026-04-05..2026-06-03 ; brute 2026-01-28..2026-06-06

vendor   : Lantronix
product  : EDS5000 series (EDS5008, EDS5016, EDS5032)
vulnerable_firmware : 2.1.0.0R3
patched_firmware    : 2.2.0.0R1   (released 2026-02-20)
cve      : CVE-2025-67038   cvss: 9.8   kev_added: 2026-06-23
action   : inventory all units; flag any build < 2.2.0.0R1 as IN-SCOPE

[ ] EDS5000 LuCI UI reachable from internet?  -> remove exposure
[ ] firewall blocks 38.207.136.2 / 218.13.42.36 inbound + outbound
[ ] OT segment denied egress to internet by default
[ ] LuCI web admin behind VPN / mgmt VLAN only
[ ] failed-auth + brute-force alerting on OT web logs
[ ] all EDS5000 upgraded to 2.2.0.0R1

1 · Perimeter / OT-firewall block (vendor-neutral CLI pattern)

# Block both exploitation IPs inbound AND outbound on the OT boundary.
# Adapt to your firewall syntax (example shown for an iptables-style relay host).

# Inbound — drop anything from the exploitation IPs hitting the OT segment
iptables -I FORWARD -s 38.207.136.2 -j DROP
iptables -I FORWARD -s 218.13.42.36 -j DROP

# Outbound — stop a rooted device / pivot host from reaching them
iptables -I FORWARD -d 38.207.136.2 -j DROP
iptables -I FORWARD -d 218.13.42.36 -j DROP

# Default-deny internet egress from the OT segment (replace CIDR with your range)
iptables -A FORWARD -s 10.50.0.0/16 ! -d 10.0.0.0/8 -j DROP

2 · Falcon IOC Management — bulk prevent (PowerShell, FalconPy / API)

# Push both exploitation IPs to Falcon IOC Management as prevent.
# Requires an API client with IOC Management:write scope.

$iocs = @(
  @{ type='ipv4'; value='38.207.136.2'; action='prevent'; severity='critical';
     description='EDS5000 CVE-2025-67038 exploitation source'; platforms=@('windows','linux') },
  @{ type='ipv4'; value='218.13.42.36'; action='prevent'; severity='critical';
     description='EDS5000 CVE-2025-67038 exploitation source'; platforms=@('windows','linux') }
)
# POST each $ioc to /iocs/entities/indicators/v1 with your bearer token.
# (Use your standard Falcon API wrapper to submit $iocs.)

3 · EDS5000 firmware remediation (operator runbook)

# OT change-controlled upgrade — schedule in a maintenance window.
1. Inventory: list every EDS5008/EDS5016/EDS5032 and current firmware.
2. Flag any unit on 2.1.0.0R3 (or any build < 2.2.0.0R1) as IN-SCOPE.
3. Snapshot/export device config before upgrade.
4. Apply Lantronix EDS5000 firmware 2.2.0.0R1 (released 2026-02-20).
5. Verify firmware = 2.2.0.0R1 post-upgrade; restore validated config.
6. Confirm LuCI UI is NOT internet-reachable; admin only via mgmt VLAN/VPN.
7. Re-run the §10 exposure/egress audit checklist.

Defensive content only. This pack contains no exploit/injection payloads. The "shell token" references in the hunts are detection signatures, not working exploit strings.

Known gaps: On-device execution (T1059) is the central gap — Falcon has no agent on the EDS5000, so step 4 of the attack chain is invisible. It is mitigated, not detected: patch to 2.2.0.0R1, remove exposure, and lean on web-log signatures (Q2/Q5) plus blast-radius network hunts (Q1/Q3/Q4/Q6). Web-log-dependent coverage (Q2/Q5) is ⚠ Partial until you confirm OT/proxy HTTP logs are ingested into NGSIEM. Validation gates in §11 gate promotion of Q4/Q6 until a clean baseline exists.

Generated 2026-06-27 · HuntPack v0.1 · CVE-2025-67038 · All indicators traced to the five cited sources above; no IOC fabricated.