The short version
CISA's August 25, 2026 ICS advisory release contained seven new advisories, ICSA-26-237-01 through ICSA-26-237-07, alongside updates to previously published ones. Two of the items in that release cover the same narrow device class: serial-to-IP device servers.
The first is ICSA-26-237-06 for the Ebyte NE2-D11, an RS485-to-Ethernet serial server. Eleven CVEs, four of them CVSS v3.1 9.8, and, per CISA, no confirmed patch: the vendor acknowledged the reports, said a fix was in development, then stopped responding. The second is Update A to ICSA-26-069-02 for Lantronix EDS3000PS and EDS5000. That update is material, not administrative: CISA's revision history records it as "Additional affected products and mitigations added," extending the affected list from two product lines to six.
The point is not that these two products are unusually bad. It is that a serial-to-IP device server is the least-inventoried networked component in most OT estates. It gets bought as a cable replacement, installed by whoever needed a serial link reachable, and then never recorded as a host with an IP address, an OS, and a login page. It sits exactly where an unauthenticated serial protocol becomes routable, which is the one seam in the architecture that deserves the most scrutiny and reliably gets the least.
What CISA actually published
ICSA-26-069-02, Update A: Lantronix EDS3000PS and EDS5000
Originally published March 10, 2026, revised August 25, 2026. Eight CVEs, reported to CISA by Francesco La Spina and Stanislav Dashevskyi of Forescout Technologies, as part of the research Forescout Vedere Labs published in April 2026 under the name BRIDGE:BREAK.
| CVE | Class (CWE) | CVSS v3.1 | CVSS v4.0 |
|---|---|---|---|
| CVE-2025-67038 | OS command injection, unauthenticated, in the HTTP RPC failed-login path (CWE-78) | 9.8 | 9.3 |
| CVE-2025-67039 | Authentication bypass via alternate path (CWE-288) | 9.8 | 9.3 |
| CVE-2025-67034 | OS command injection, SSL credential delete (CWE-78) | 7.2 | 8.6 |
| CVE-2025-67035 | OS command injection, SSH client/server pages (CWE-78) | 7.2 | 8.6 |
| CVE-2025-67036 | OS command injection, Log Info filename (CWE-78) | 7.2 | 8.6 |
| CVE-2025-67037 | OS command injection, tunnel parameter (CWE-78) | 7.2 | 8.6 |
| CVE-2025-67041 | OS command injection, TFTP host parameter (CWE-78) | 7.2 | 8.6 |
| CVE-2025-70082 | Unverified password change (CWE-620) | 2.7 | 5.1 |
What Update A changed. The March publication listed EDS5000 series at or below 2.1.0.0R3 and EDS3000PS series at or below 3.1.0.0R2. The August 25 revision adds four more Lantronix lines to the affected list, with their own fixed versions: G520 series below 2.6.0.4R6, X300 series below 2.6.0.4R6, E210 series below 3.21.0.0R1, and E220 series below 3.21.0.0R1. Fixed firmware for the two original lines is EDS5000 2.2.0.0R1 or later and EDS3000PS 3.2.0.0R2 or later.
That matters most for CVE-2025-67038, the unauthenticated one. It is now listed against all six product lines. If you patched an EDS5000 in June and considered the finding closed, the gateway and cellular router lines in the same estate were not in scope of that decision.
One inconsistency worth naming. The advisory carries CISA's standard closing line: "No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time." That is not consistent with CISA's own Known Exploited Vulnerabilities catalog, which lists CVE-2025-67038 as added on June 23, 2026 on evidence of active exploitation, with a federal remediation deadline of June 26, 2026 under BOD 26-04. Trust the KEV entry. Boilerplate at the bottom of an advisory is not a threat assessment.
ICSA-26-237-06: Ebyte NE2-D11
Published August 25, 2026, reported by Jithin Nambiar. The affected product is the Ebyte NE2-D11 on firmware FW-9167-0-11. Per the vendor's own product documentation, the NE2-D11 is a single-port RS485-to-Ethernet serial server with Modbus gateway and MQTT/HTTP client modes, DIN-rail mounted, sold as a component. CISA lists the sectors as Critical Manufacturing and Energy, deployment worldwide, vendor headquartered in China.
Eleven CVEs. The four rated 9.8 / 9.3 are the ones that define the risk:
- CVE-2026-73125 (CWE-306): the web management interface does not consistently enforce authentication before granting access to administrative functionality.
- CVE-2026-71187 (CWE-603): authentication logic runs client-side and can be reproduced by an unauthenticated user to generate valid requests.
- CVE-2026-76179 (CWE-598): session tokens insufficiently protected during client-side handling, allowing capture and reuse.
- CVE-2026-69658 (CWE-319): MQTT credentials and control traffic transmitted in cleartext.
The rest run through the same theme: cleartext web management (CVE-2026-73809, 7.5), missing server-side authorization on configuration endpoints (CVE-2026-75813, 7.5), replayable client-managed tokens (CVE-2026-76945, 7.5), no rate limiting or lockout (CVE-2026-76940, 7.5), CSRF (CVE-2026-75814, 8.8), clickjacking (CVE-2026-75548, 5.4), and plaintext admin credentials visible in the management interface (CVE-2026-73839, 4.6).
Read together, that is not a bug list. It is a device whose web interface was built as if it would only ever be reached by a trusted operator on a trusted wire.
Side by side
| Lantronix EDS3000PS / EDS5000 | Ebyte NE2-D11 | |
|---|---|---|
| Advisory | ICSA-26-069-02, Update A (Aug 25, 2026) | ICSA-26-237-06 (Aug 25, 2026) |
| Function | Serial device server / console server | RS485-to-Ethernet serial server, Modbus + MQTT gateway |
| CVE count | 8 | 11 |
| Highest CVSS v3.1 | 9.8 | 9.8 |
| Dominant class | OS command injection to root (CWE-78) | Missing / client-side authentication (CWE-306, CWE-603) |
| Known exploited | Yes, CVE-2025-67038 in KEV since June 23, 2026 | No known exploitation reported to CISA |
| Vendor fix | Available across six product lines | Not confirmed. Vendor stopped responding to CISA |
| Sectors listed | Communications, IT, Critical Manufacturing | Critical Manufacturing, Energy |
| Practical action | Patch, then verify coverage of the four newly listed lines | Compensating controls only |
The contrast in the last three rows is the useful part. One vendor produced fixes and kept the coordination going for five months. The other went quiet. If your risk register only has a "patch available yes/no" column, it cannot tell you which of these two devices is the harder problem this quarter.
Why this device class goes missing
A serial-to-IP device server gets procured as an accessory. The requisition says "we need the flow computer readable from the SCADA server," and an 80 mm DIN-rail box solves that for a small sum. Nobody files it as a networked asset because, in the mental model of the person installing it, it is a cable.
Except it is not. It is a routable host with an embedded operating system, a web management interface, credentials, firmware, and, in the Lantronix case, a shell running as root. Forescout's VP of Research Daniel dos Santos put the structural problem plainly in the BRIDGE:BREAK announcement: "Serial-to-IP converters sit directly in the path between operators and physical processes, yet they often fall outside traditional security monitoring."
The exposure question follows from that. Forescout's BRIDGE:BREAK research reported finding "tens of thousands of serial-to-IP converters from major vendors exposed online", with the honest caveat Forescout itself attaches: internet exposure is often unintended and does not by itself indicate vulnerability to the newly disclosed issues. Press coverage of the research, including The Hacker News, put the figure at nearly 20,000. We have not independently reproduced either number, so treat them as an order of magnitude rather than a count.
The BRIDGE:BREAK set was 22 vulnerabilities: eight in the two Lantronix lines and fourteen in the Silex SD330-AC. Three vendors, one device class, five months, and now two entries in a single day's CISA release. That is a pattern in the data, not a coincidence in the news cycle.
How the attack path works
The mechanism is short, which is what makes it dangerous. The device server is reachable on IP. Its management interface accepts a request that should have required authentication and does not. Command execution or configuration change follows. On the far side of that device sits an RS-485 multidrop with a controller on it that has no authentication of any kind, because the protocol never had any, and this is precisely the argument we make in Securing DNP3: putting a serial link on IP hands it every exposure IP carries, and the converter almost never gets the scrutiny the endpoint would.
Mapped to MITRE ATT&CK for ICS. Note that MITRE has renumbered several ICS techniques, so legacy IDs are given in parentheses where they changed.
| Tactic | Technique (ID) | What it looks like here |
|---|---|---|
| Initial Access | Internet Accessible Device (T0883) | Device servers reachable from the public internet, per Forescout's exposure research. Supported by CISA's first recommended mitigation on both advisories. |
| Initial Access | Exploit Public-Facing Application (T0819) | CVE-2025-67038, unauthenticated OS command injection in the Lantronix HTTP RPC failed-login handler, executing as root. In KEV. |
| Initial Access | External Remote Services (T0822) | The device server is itself the remote service that reaches the serial segment. Compromising it grants that reach directly. |
| Discovery | Remote System Discovery (T0846) | Device servers advertise themselves on well-known management ports and identify their model in banners, which is what makes internet-wide enumeration cheap. |
| Credential Access | Network Sniffing (T0842) | Ebyte CVE-2026-73809 (cleartext web management) and CVE-2026-69658 (cleartext MQTT credentials and control traffic). |
| Lateral Movement | Valid Accounts (T0859) | Lantronix CVE-2025-67039 (authentication bypass) chained with CVE-2025-70082 (password change without the current password) yields a legitimate admin account. |
| Lateral Movement | Commonly Used Port (T0885) | The serial tunnel is carried on ordinary TCP, so traffic through the converter looks like normal traffic to a boundary device that is not protocol-aware. |
| Impact | Unauthorized Message: Command Message (T1692.001, formerly T0855) | Consequence, not observed in these advisories: root on the converter means arbitrary bytes onto the serial line, and the outstation has no way to reject them. |
| Impact | Modify Firmware: System Firmware (T1693.001, formerly T0857) | Consequence, not observed here. Forescout's BRIDGE:BREAK report notes firmware tampering as a possible outcome, and cites the 2015 Ukraine grid attack in which serial-to-Ethernet converter firmware was deliberately corrupted. |
The last two rows are labeled as consequences deliberately. Neither advisory reports them. They are what the access is worth, which is the number that should drive the priority.
The architectural problem: an undesigned conduit
In IEC 62443 terms, a serial device server is a conduit that nobody designed. Zones get drawn, conduits get documented, and then a converter appears between two of them because a project needed data out of a serial meter. The zone model on the wall is still correct. The network is not.
The same holds for the Purdue model. A device server is a path that bypasses the hierarchy: a Level 1 device becomes directly addressable from wherever the converter is reachable, without traversing any of the Level 2 and Level 3 systems the model assumes will be in the way. If the converter also carries MQTT out to a broker, as the NE2-D11 does, the path can leave the site entirely.
This is also where the gap between SL-T and SL-A shows up honestly. You can target Security Level 2 for a zone and genuinely achieve it for the PLCs, the HMI, and the engineering workstation, and still be at SL 0 on the conduit, because the conduit is a device nobody assessed. An assessment that never enumerated the converter cannot have rated it.
What to do this week
- Find them. Search procurement records and cabinet photos for "device server", "terminal server", "serial server", and "serial-to-Ethernet", and sweep the network for the management ports these devices listen on. Passive discovery will find them faster than asking around will.
- Add the class to the inventory as networked hosts, with model, firmware version, IP, and the serial device on the far side. If a converter has no owner recorded, assign one.
- Patch the Lantronix estate, and check the four product lines Update A added, not only the EDS5000 and EDS3000PS you already handled. CVE-2025-67038 is in KEV, which makes it a priority regardless of your internal scoring.
- Confirm none of them is internet-reachable. This is the single control both advisories lead with, and it is the one that closes the exploited path.
- Take management traffic off the general network. No converter should accept a connection to its web interface from an arbitrary host on the plant LAN.
- For the Ebyte NE2-D11, plan for no patch. Ask the vendor directly, in writing, and set a decision date for replacement or containment rather than waiting.
- Write the converter into the zone and conduit diagram. If it is not on the diagram, the diagram is describing a different network than the one you run.
Where Access Gate fits, and where it does not
Access Gate does not fix any of these CVEs. A network control cannot sanitize a shell command inside someone else's firmware, and it cannot make client-side authentication server-side. Patch the Lantronix devices on the vendor's fixed versions. That is the primary recommendation and nothing here replaces it.
What Access Gate addresses is the part of the problem that has no vendor fix: the Ebyte-shaped case, where the vulnerability is real, the exposure is real, and there is no firmware to install. In that situation the only lever left is reachability, and that is a network problem rather than a device problem.
Access Gate connects to the network the site already has rather than cutting into it, so day one is low impact. From there you steer the flows you want protected through it, one asset at a time. For a device server, that means the management interface stops being reachable from the general network, and any session that does reach it is authenticated against a real identity with a second factor, scoped to the one protocol and destination it needs, and recorded. The command injection is still in the firmware. There is simply no unauthenticated path to the parameter that carries it.
It is worth being precise about the limits. This does nothing about a converter that is already compromised, it does not inspect the serial side, and it does not remove the obligation to replace an unsupported device eventually. What it buys is time to plan that replacement without leaving the path open in the meantime. See OT network security for the segmentation model and what an industrial proxy is for how the enforcement point works.
Sources: CISA ICS Advisory ICSA-26-069-02, Update A (revised August 25, 2026), CISA ICS Advisory ICSA-26-237-06 (August 25, 2026), the CISA Known Exploited Vulnerabilities catalog entry for CVE-2025-67038, and Forescout Vedere Labs BRIDGE:BREAK (April 2026). Verify affected and fixed versions against the vendor advisories before scheduling work.