Executive Summary
CVE-2026-13207 is an authentication bypass by spoofing in Frangoteam FUXA SCADA/HMI versions 1.3.1 and earlier that lets an unauthenticated remote attacker enumerate every user account and role assignment on the instance. The physical criticality is indirect but real: FUXA is the operator-facing control layer, and disclosing the full account and privilege map hands an attacker the exact target list for follow-on credential attacks against the interface that drives valves, pumps, and process setpoints.
Technical Exposure Breakdown
FUXA is a web-based, open-source SCADA and HMI platform built on a Node.js backend with a browser front end. It is popular precisely because it is free and easy to stand up, which means it appears in places where formal engineering review and asset governance are thin. That deployment profile matters here.
The flaw carries a CVSS v3 base score of 7.5 and is characterized as Authentication Bypass by Spoofing. In practice the vulnerable component is an API endpoint or response path that returns user and role data without validating an authenticated session. An attacker who can reach the FUXA web service over the network sends a crafted request and receives back the account inventory: usernames, role assignments, and the privilege structure of the deployment.
The conditions for exploitation are minimal. No credentials, no prior foothold, no user interaction. The only precondition is network reachability to the FUXA service port. This is not code execution and it does not by itself move a physical output, but it is high-quality reconnaissance. It converts a blind credential-stuffing or brute-force campaign into a targeted one. Knowing which account holds administrative or engineering role rights tells the attacker exactly where to spend effort. It also exposes naming conventions that often extend to Active Directory, jump hosts, and engineering workstations.
Because FUXA is frequently deployed on small footprint hardware or general-purpose servers inside the OT network, and sometimes exposed to corporate segments or the internet through poorly configured remote access, the reachable attack surface is larger than the vendor scope suggests.
OT Impact and Compliance Risk
The affected sectors named in the advisory are Critical Manufacturing, Energy, and Water and Wastewater. In each of these, the HMI is the human decision layer. Enumeration does not trip a relay, but it directly undermines the access control assumptions that safety cases and compliance frameworks are built on.
Under IEC 62443, this maps to failures in the Identification and Authentication Control and Use Control foundational requirements. An interface that leaks its own account structure to an anonymous requester cannot satisfy the account management expectations at any meaningful security level. For NERC CIP registered entities, if a FUXA instance touches a BES Cyber System or an associated Electronic Access Control or Monitoring System, this bears on CIP-005 electronic access controls and CIP-007 account and access management. For water and wastewater utilities, AWIA 2018 risk and resilience assessments should treat unauthenticated account disclosure as a documented finding, not an academic one. Pipeline operators under TSA SD-02C should note this in access control and monitoring measures for the HMI tier.
Compensating Controls
Do not rely solely on a version bump. Treat network reachability as the primary control lever.
- Segment and restrict. FUXA should never be reachable from corporate or internet-facing zones. Enforce a deny-by-default firewall policy so only named engineering workstations and jump hosts can reach the FUXA web port. This alone neutralizes an unauthenticated remote attacker who has no path to the service.
- Virtual patch at the proxy. Where FUXA is fronted by a reverse proxy, block or filter the specific endpoints that return user and role data to unauthenticated sessions. Require a valid session cookie or token at the proxy layer before the request reaches the Node.js backend.
- Suricata detection concept. Write a rule that alerts on HTTP requests to the FUXA API path patterns associated with user or role listing where no authenticated session header or cookie is present, and where the source is outside the approved engineering subnet. Alert on the response as well if it carries the account inventory in JSON. This gives detection even before a control change is enforced.
- Do not fix this with active scanning. Aggressive vulnerability scanning against a FUXA host or the OT segment it sits on can destabilize the Node.js service and adjacent embedded components. Prefer passive discovery and configuration review to confirm exposure.
- Assume enumeration already happened. If the instance was internet-reachable, rotate credentials for exposed accounts and tighten role assignments to least privilege.
BreachSpider Intel
BreachSpider tracks FUXA and other open-source ICS platform exposures across OT environments, correlating advisory data against reachable assets so teams can act on enumeration risk before it becomes a credential attack. Visit BreachSpider for continuous monitoring.