CVE-2024-12297: Moxa switch authorization bypass

1. Summary

The web-based management interface of Moxa’s EDS-508A and PT-series industrial Ethernet switches contains a flawed authorization mechanism that relies on security through obscurity and weak MD5-based verification split across client-side and back-end logic [1][2]. A network-reachable attacker with no prior credentials can defeat this mechanism by brute-forcing credentials or by forging an authorization hash through an MD5 collision [1]. Successful exploitation yields full administrative access to device configuration on switches that commonly sit inside operational-technology (OT) and critical-infrastructure networks [7].

2. Affected products & versions

Fixed firmware is not consistently enumerated in public sources; Moxa directs EDS-508A users to Technical Support for a patch, while some other series receive published firmware upgrades [2][4]. PT-series fixed versions are not documented in any source reviewed.

3. The vulnerability in detail

The defect lives in the authorization mechanism of the web-based management interface of Moxa’s managed industrial Ethernet switches — the logic that is supposed to decide whether a requesting client is entitled to administrative access to device configuration [1][2]. Moxa’s own advisory names this the “Frontend Authorization Logic Disclosure” vulnerability, which captures the essence of the problem: authorization decisions that should be enforced authoritatively on the server are instead partly exposed and partly dependent on client-side logic, with a back-end verification step that is cryptographically weak [2]. The exact vulnerable file, binary, or HTTP endpoint has not been publicly disclosed by the vendor or researcher, so the description here is grounded in the mechanism as characterized in the advisories rather than in a specific code path [1][2].

The root cause is classified as CWE-656, Reliance on Security Through Obscurity [1][5]. The switch’s authorization scheme assumes that an attacker will not understand or reconstruct how the access check works — the secrecy of the mechanism itself is doing security work that should be done by a strong, secret-key-based cryptographic control. That assumption is the actual defect. Once an attacker understands the shape of the verification, the protection collapses. Two properties make the collapse practical. First, the verification is split between client-side and back-end components, meaning a determined attacker can observe and manipulate the parts of the exchange that are exposed to the client [2]. Second, the back-end verification depends on MD5, a hash function that has been considered cryptographically broken for collision resistance for many years [1]. Because MD5 is vulnerable to collision attacks, an attacker can, in principle, forge an authorization hash that the switch will accept as valid without possessing the legitimate secret that should have produced it.

The mechanism of exploitation follows two documented techniques [1][6]. The first is straightforward credential brute-forcing: the attacker repeatedly guesses credentials against the network-reachable management interface until the weak authorization check accepts them. The second, more interesting technique is MD5-collision hash forgery: rather than guessing a secret, the attacker constructs an input that produces a hash colliding with a value the back-end will treat as authorized, thereby bypassing the check outright [1]. The precise construction of the collision against Moxa’s specific authorization protocol is not detailed in any public source and remains an inference from the CWE and the vendor’s framing [1]. The preconditions are modest: network reachability to the management interface and a device running vulnerable firmware [1]. No prior authentication and no user interaction are required (PR:N/UI:N), which is what makes the flaw severe despite needing effort to execute [1].

The step-by-step exploitation chain is: (1) reach the switch’s web management interface over the network against vulnerable firmware; (2) target the flawed authorization mechanism; (3) either brute-force credentials or forge an authorization hash via MD5 collision; (4) bypass the authorization check to obtain administrative configuration access; and (5) act on that access — reconfigure the switch, enable port mirroring to eavesdrop on control-network traffic, or disrupt OT communications [1][2][7]. The final-stage consequences of port mirroring and traffic disruption are inferred from the device’s role in the network and are not explicitly confirmed in the CVE record itself [7].

The EPSS estimate is approximately 0.83% (roughly the 54th percentile), consistent with a serious but not actively exploited flaw whose exploitation requires real work rather than a one-shot remote code execution [5]. The requirement to brute-force or engineer an MD5 collision — as opposed to firing a single deterministic exploit — is the key nuance that separates the theoretical criticality of this bug from its practical exploitation cost.

4. Discovery & timeline

The vulnerability was reported by Artem Turyshev of Rosatom Automated Control Systems Joint-Stock Company (RASU), who identified it during industrial control system audits [2][7]. Disclosure and remediation proceeded in stages: Moxa published the EDS-508A advisory (MPSA-241407) on January 15, 2025 [2]; the companion PT-switch advisory (MPSA-241408) followed in March 2025 [3][6]; and the EDS-508A advisory was subsequently updated on July 22, 2026 to broaden the affected inventory to additional families including TN-G [2]. A third advisory (MPSA-241409) further broadened the affected set to additional managed Ethernet switch families under the same CVE [4].

5. Technical reference

• CVE: CVE-2024-12297 [1]
• CWE: CWE-656, Reliance on Security Through Obscurity [1][5]
• CVSS v4.0: 9.2 (CRITICAL), vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L [1]. The key metrics: AV:N (network attack vector) reflects that the management interface is remotely reachable; AC:L with AT:P indicates low attack complexity but a present attack requirement — the brute-force / MD5-collision effort that is not a guaranteed one-shot; PR:N/UI:N means no prior privileges and no user interaction; VC:H/VI:H/VA:H capture full confidentiality, integrity, and availability impact on the switch itself; and the subsequent-system metrics SC:L/SI:L/SA:L reflect limited spillover to downstream systems.
• EPSS: ~0.83% (~54th percentile) [5]
• Advisory mirrors: GitHub Advisory GHSA-jp78-8mxr-44qr confirms CWE-656, CVSS 9.2, and the EDS-508A + PT scope [5]; Tenable corroborates the same baseline facts [9].
• Code/commit refs: None public. The exact vulnerable file/endpoint is not disclosed [1][2].

6. Consequence & CFSE path analysis

Real-world consequence. An attacker who bypasses the authorization check obtains full administrative authority over a switch’s configuration. In the OT and critical-infrastructure settings where these devices are deployed, that translates concretely into three things: the ability to reconfigure the device and change forwarding behavior; the ability to disrupt or degrade the process communications that ride through the switch; and the ability to enable port mirroring to intercept control-network traffic, credentials, and configuration data [7]. These are the tangible harms a defender should reason about, independent of any score.

Why the CFSE Path Score differs from CVSS. The published CVSS v4.0 baseline is 9.2 CRITICAL. The CFSE reachable-consequence analysis lands one band lower, at HIGH, with direction OVER (i.e., CVSS over-states relative to reachable consequence), with requirements_missed: 2. The entry decomposes CVE-2024-12297 into three co-dominant consequence paths, each independently assessed HIGH:

• ACCOUNT_AUTHORITY — admin/config authority over switch forwarding and device settings. Critically, this authority does not extend to a signing key or firmware trust root, so authority tier (AT) is capped at 3.
• DEVICE_AVAILABILITY — disrupting or reconfiguring the switch to break OT process communications.
• DATA_PRIVACY — port-mirroring to eavesdrop on control-network traffic, credentials, and configuration.

All three paths share the same exposure profile: RE:4 network-reachable management interface (consistent with AV:Network), but EX bounded to 2 by EC:2 because exploitation requires brute-force or MD5-collision hash forgery rather than a one-shot RCE. Evidence is report-backed (EV:2) and the lifecycle is patch-available. No cap or systemic uplift changes the base HIGH band on any path. The overall path_verdict is HIGH. The gap from the 9.2 CRITICAL CVSS baseline is driven principally by the exploitation-cost bounding (EC:2 → EX:2) and by authority being capped at 3 for lack of a firmware trust-root compromise — both of which the CVSS base score does not fully discount.

Verdict carried from seed: HIGH.

7. Remediation & mitigations

Grounded, bug-specific remediation [2][6]:

• EDS-508A: Apply the patch obtained by contacting Moxa Technical Support — no single public fixed-version string is published for this series [2].
• Other affected series: Apply the firmware upgrades Moxa has published where available (some EDS/SDS/TN series) [2]. PT-series fixed firmware is not enumerated in sources; PT operators should confirm the fixed version directly with Moxa [3].
• Restrict reachability of the management interface: Because the entire attack depends on network reachability to the web management interface, minimizing that exposure is the highest-value interim control — segment the switch onto a management VLAN/network isolated from general OT traffic, and restrict management/SSH access via firewall rules and ACLs to a small set of trusted administrative hosts [2].
• Remote administration: Route any required remote administration through a VPN or SSH rather than exposing the management interface directly [2].
• Detection: Deploy IDS/IPS positioned to observe management-interface traffic; brute-force attempts against the authorization mechanism are the observable signal for the credential-guessing technique [2].
• Access hardening: Where supported, enforce MFA/RBAC on administrative access to raise the cost of the brute-force path [2].