August 25, 2026

TLS Client-Initiated Renegotiation Denial-of-Service Exposure in Moxa Industrial Ethernet Switches

Security Advisory Brief

On August 19, 2026, Moxa published a security enhancement advisory addressing the long-standing TLS client-initiated renegotiation weakness tracked as CVE-2011-1473 across three of its managed industrial Ethernet switch families. The affected products are the EDS-510A Series, the ICS-G7826A Series, and the SDS Series, which includes the SDS-3006, SDS-3008, SDS-3010, SDS-3016, SDS-G3006, SDS-G3008, SDS-G3010, and SDS-G3016 models. These switches are widely deployed in substation automation, water and wastewater treatment, transportation, and manufacturing networks, where they carry process traffic and provide the web and command-line management interfaces used by engineering and operations staff.

The underlying issue is a protocol behavior rather than a memory-corruption or authentication defect. TLS implementations that permit a client to initiate an unlimited number of renegotiation handshakes within a single established connection allow an unauthenticated remote party to force the device to repeatedly perform the asymmetric cryptographic operations that make up a handshake. Because a handshake costs the server substantially more processing effort than it costs the client, a single low-bandwidth connection can consume a disproportionate share of the switch's constrained CPU budget. The condition affects availability only; it does not permit disclosure or modification of data carried over the TLS session, and it does not provide a path to authenticated access or code execution on the device.

Moxa characterizes the exploitability of this condition as low in deployments that follow a segmented network architecture, and NIST records CVE-2011-1473 as disputed on the grounds that limiting renegotiation may reasonably be considered a server deployment responsibility rather than a defect in the cryptographic library. The National Vulnerability Database has assigned a CVSS v2.0 base score of 5.0 with the vector AV:N/AC:L/Au:N/C:N/I:N/A:P, and has not published a CVSS v3.1 or CVSS v4.0 score. There is no indication of exploitation targeting Moxa devices through this vector, and the CVE is not listed in the CISA Known Exploited Vulnerabilities catalog. The practical significance for asset owners is therefore not the severity rating but the exposure profile: a management plane that is reachable from a broad set of hosts turns a low-risk protocol behavior into a viable path for degrading the availability of a switch that sits in the middle of a control network.

Threats and Vulnerabilities

CVE-2011-1473, with a CVSS v2.0 base score of 5.0 and no published CVSS v3.1 or CVSS v4.0 score, describes the failure of SSL and TLS implementations to properly restrict client-initiated renegotiation, allowing a remote attacker to cause a denial of service through CPU exhaustion by performing many renegotiations within a single connection. On the affected Moxa switches, the condition is reachable through the TLS-protected management services exposed by the device, principally the HTTPS web management interface. An attacker who can open a TCP session to that interface does not require valid credentials, since renegotiation is requested during and after the handshake and before any application-layer authentication takes place. Sustained exploitation can raise processor utilization to the point that the management interface becomes unresponsive, and on resource-constrained embedded hardware it can also delay the control-plane processing that supports spanning tree, ring redundancy, and network management protocols. Moxa has published firmware that removes support for client-initiated renegotiation on the affected platforms: firmware v3.14.4 for the EDS-510A Series, which addresses firmware v3.14 and earlier; firmware v5.13.8 for the ICS-G7826A Series, which addresses firmware v5.13 and earlier; and firmware v3.3 or later for the SDS Series models, which addresses firmware v3.2 and earlier. Moxa notes that because the risk is low in a properly segmented architecture, asset owners may evaluate their own environments to determine whether an update is warranted rather than treating the fix as an emergency change.

Client Impact

For operational technology environments, the primary consequence is the potential loss of management visibility and control at exactly the moment it is most needed. A switch whose CPU is saturated by repeated handshakes may stop responding to the engineering workstation, the network management platform, and the monitoring polls that operations teams rely on to confirm network health, even while packet forwarding in hardware continues normally. That divergence is operationally confusing: the process may appear healthy while the network appears dark to the tools that observe it. On the ICS-G7826A and EDS-510A platforms, which are commonly deployed in ring topologies carrying substation and plant-floor traffic, prolonged control-plane starvation also creates the possibility of delayed redundancy convergence should a link fail during the same window. Because the attack requires no credentials and leaves little in the way of distinctive application-layer logging, it can also serve as low-cost cover activity intended to occupy responders while other actions are taken elsewhere on the network.

From a compliance perspective, the affected switches frequently sit inside regulated electronic security perimeters and are subject to patch management and vulnerability assessment obligations. Under NERC CIP-007-6 R2, entities must evaluate applicable security patches for cyber assets within thirty-five days of availability and either apply them, create a dated mitigation plan, or document why they are not applicable, and a vendor firmware release of this kind starts that clock regardless of the low severity rating. IEC 62443-2-1 and 62443-3-3 place a parallel expectation on asset owners to maintain a documented patch evaluation process and to restrict management access to authorized users and networks. Organizations following NIST SP 800-82 Revision 3 guidance for industrial control systems will find that the recommended mitigations here reinforce existing zone and conduit controls rather than requiring new architecture. Documenting the evaluation decision, including a decision not to update immediately, is as important to an audit outcome as the update itself.

Mitigations

1898 & Co. recommends the following actions, prioritized so that the changes offering the greatest exposure reduction can be made without waiting for a maintenance window in which firmware can be updated.

Inventory all EDS-510A, ICS-G7826A, and SDS Series switches, including the SDS-3006, SDS-3008, SDS-3010, SDS-3016, SDS-G3006, SDS-G3008, SDS-G3010, and SDS-G3016 models, and record the running firmware version for each so that affected devices can be separated from those already at or above the fixed release.
Schedule firmware updates for affected devices through normal change control, moving EDS-510A Series switches to firmware v3.14.4, ICS-G7826A Series switches to firmware v5.13.8, and SDS Series switches to firmware v3.3 or later, and verify the running version after each update completes.
Restrict access to the HTTPS and other TLS-protected management interfaces so that they accept connections only from designated engineering workstations and jump hosts, using switch access control lists, upstream firewall rules, or a dedicated out-of-band management network, and disable any management service that is not operationally required.
Confirm that none of the affected switches are reachable from the internet or from enterprise IT segments without an intervening policy enforcement point, and validate that assumption through an external exposure review rather than relying on documented design intent alone.
Add processor utilization and management-interface responsiveness for these switches to routine monitoring, and configure alerting on sustained high CPU with concurrent TLS session activity so that resource exhaustion is detected as a security event and not only as a performance anomaly.

Where a firmware update cannot be scheduled promptly, restricting reachability to the management plane addresses the practical risk on its own, and the combination of restricted access and monitoring provides a defensible interim position that can be recorded in the patch evaluation documentation required by applicable regulatory programs.

1898 & Co. Response

1898 & Co. maintains a dedicated industrial cybersecurity practice with experience supporting operational technology programs across electric utilities, water and wastewater systems, oil and gas operators, and discrete and process manufacturers. Our consultants have performed OT network architecture reviews, asset inventory build-outs, and vulnerability assessments in environments built on the same classes of managed industrial Ethernet switches described in this advisory, and understand the operational constraints that govern when firmware on a substation or plant-floor switch can realistically be changed.

For organizations working through this advisory, we can assist with identifying affected device populations from existing configuration and passive monitoring data, assessing whether management interfaces are exposed beyond their intended zones, and developing a firmware update sequence that respects redundancy and availability requirements. Where an immediate update is not practical, we help document a defensible mitigation position that aligns with NERC CIP-007-6 R2 patch evaluation obligations and IEC 62443 access control requirements.

Our managed threat detection service monitors OT and IT environments for the behavioral patterns associated with this class of condition, including anomalous TLS session activity directed at control network infrastructure and unexpected management-plane connections from hosts outside the approved administrative population. Detection content is developed and tuned by analysts who work in industrial environments daily, which helps reduce the volume of alerts that reach operations teams while keeping activity of this kind visible.

Sources

Cyberthreat