Serial-to-IP Device Servers: Four CISA Advisories in Three Days

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.

Update, August 27, 2026. Two days later CISA published seven more ICS advisories, and two of those are the same device class again: ICSA-26-239-05 for the Ebyte NA111-M (thirteen CVEs, six at 9.8, no confirmed patch) and ICSA-26-239-01 for the Xiiaozet LK100W (three CVEs, two at 9.8, fix available). That makes four advisories against serial-to-IP device servers in three days. See the August 27 section below.

The point is not that these 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.

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

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.

The August 27 release: two more in the same class

Two days after the advisories above, CISA's August 27, 2026 release contained seven ICS advisories, and two of them land on this same page.

ICSA-26-239-05: Ebyte NA111-M

Same vendor as the NE2-D11, same researcher (Jithin Nambiar J), same ending. Thirteen CVEs against firmware 9013-2-17, six of them CVSS v3.1 9.8, and the same remediation text: Ebyte acknowledged receipt, said a patch was under development, then stopped responding to CISA's coordination requests. CISA lists the sector as Information Technology, deployment worldwide, vendor headquartered in China.

Note the overlap with the NE2-D11 list: CVE-2026-73125, CVE-2026-71187, CVE-2026-76179, CVE-2026-73809, CVE-2026-76940, CVE-2026-75814, CVE-2026-75548, and CVE-2026-69658 appear on both advisories. These are not two independent findings. They are one web management stack shared across a product line, disclosed twice. If you own any Ebyte networking product, the practical assumption is that the model you own shares this codebase until the vendor tells you otherwise, and the vendor is not currently answering.

ICSA-26-239-01: Xiiaozet LK100W

Three CVEs in versions below 2.1.240, reported by Byron Guernsey of Okachobi, LLC. Sector listed as Information Technology, worldwide, vendor headquartered in China.

The chain is short and familiar: CVE-2026-78239 lets an unauthenticated remote attacker enable an administrative service that should have been restricted, CVE-2026-76943 bypasses authentication on that service, and CVE-2026-78037 turns the resulting access into OS command execution with elevated privileges.

The useful difference here is the ending. Xiiaozet shipped a fix. The vendor recommends updating to v2.1.240. Two devices, near-identical vulnerability classes, near-identical scores, and completely different practical outcomes depending on whether the vendor answers the phone.

Public product documentation for the LK100W is thin, and we are not going to characterize its function beyond what CISA published. That is itself part of the problem this post is about: a component you cannot easily research is a component nobody assessed.

What four advisories in three days actually tells you

Not that these four vendors are the problem. Four advisories, four vendors, one device class, three days is a sampling artifact of researcher attention, not a sudden change in the devices. Forescout's BRIDGE:BREAK work put twenty-two vulnerabilities across three vendors into this class in April. The devices did not get worse in 2026. They are simply being looked at for the first time.

The planning implication follows from that. If your risk process reacts advisory by advisory, this class will generate work indefinitely and you will always be behind. The class deserves a standing architectural decision rather than a recurring ticket: enumerate every serial-to-IP converter as a networked host, decide once that its management interface is never reachable from the general network, and enforce that decision independently of which vendor gets published next.

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.

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. For the Ebyte NE2-D11 and NA111-M, plan for no patch. Ask the vendor directly, in writing, and set a decision date for replacement or containment rather than waiting. Treat any other Ebyte networking product in the estate as sharing the same management stack until told otherwise: eight of the thirteen NA111-M CVEs are the same CVEs published against the NE2-D11.
7. Update the Xiiaozet LK100W to v2.1.240. A fix exists for this one, which makes it the cheapest item on the list.
8. 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), CISA ICS Advisory ICSA-26-239-05 and ICSA-26-239-01 (both August 27, 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.