CVE-2026-47718: FUXA Auth Bypass Vulnerability

CVE-2026-47718 Overview

FUXA is a web-based Process Visualization (SCADA/HMI/Dashboard) platform used to monitor and control industrial processes. CVE-2026-47718 describes an authentication bypass [CWE-287] in FUXA version 1.3.0-2773. When the secureEnabled=true setting is applied, the application still accepts guest requests and requests bearing invalid tokens against the project, alarms, and scheduler APIs. Unauthenticated attackers can therefore read sensitive SCADA/HMI configuration data over the network. Version 1.3.1 remediates the issue by enforcing authentication on the affected endpoints.

Critical Impact
Unauthenticated remote attackers can read FUXA project definitions, alarm configurations, and scheduler data even when secure mode is enabled, exposing operational technology configuration to disclosure.

Affected Products

FUXA version 1.3.0-2773 with secureEnabled=true
FUXA releases prior to 1.3.1
Deployments exposing the FUXA HTTP API to untrusted networks

Discovery Timeline

2026-08-12 - CVE-2026-47718 published to the National Vulnerability Database
2026-08-12 - Last updated in NVD database
Fix released in FUXA v1.3.1 with details in GHSA-r9g5-7q8j-958c

Technical Details for CVE-2026-47718

Vulnerability Analysis

FUXA exposes REST APIs for retrieving project layouts, alarm definitions, and scheduler entries. The secureEnabled=true configuration is intended to require authenticated sessions for these endpoints. In version 1.3.0-2773, the server-side authorization checks on the project, alarms, and scheduler API handlers do not reject guest-role requests or requests presenting invalid bearer tokens. As a result, the enforced access control model does not match the documented behavior, allowing attackers to enumerate SCADA/HMI configuration data. The advisory classifies the flaw under [CWE-287] (Improper Authentication).

Root Cause

The root cause is missing or incomplete authentication enforcement in the middleware or route handlers backing the project, alarms, and scheduler endpoints. Requests that should be rejected when secureEnabled=true fall through to the resource handlers and return data. The 1.3.1 release corrects the authorization logic so that guest and invalid-token requests receive an authentication error.

Attack Vector

Exploitation requires only network reachability to the FUXA web interface. An attacker sends HTTP requests to the vulnerable API paths without credentials, or with an arbitrary token, and receives the underlying resource data. No user interaction or prior privileges are required. Because FUXA is commonly deployed on operational technology segments, the disclosure of project and alarm configurations can support reconnaissance for follow-on attacks against industrial control systems.

See the FUXA v1.3.1 release notes and GHSA-r9g5-7q8j-958c advisory for the fix details.

Detection Methods for CVE-2026-47718

Indicators of Compromise

HTTP GET requests to FUXA project, alarms, or scheduler API endpoints originating from unauthenticated sessions
Successful 200 OK responses to API requests that contain no valid session cookie or Authorization header
Requests carrying malformed or expired bearer tokens that still return resource payloads

Detection Strategies

Inspect FUXA and reverse-proxy access logs for API reads without an associated authenticated user identifier
Alert on repeated enumeration of /api/project, /api/alarms, and /api/scheduler style routes from a single source
Correlate FUXA API access against expected operator IP ranges and workstations

Monitoring Recommendations

Forward FUXA application and web server logs to a centralized analytics platform for retention and query
Baseline normal API call patterns from operator consoles to surface anomalous unauthenticated access
Monitor for FUXA instances on version 1.3.0-2773 that remain unpatched after the 1.3.1 release

How to Mitigate CVE-2026-47718

Immediate Actions Required

Upgrade FUXA to version 1.3.1 or later, which enforces authentication on the affected APIs
Restrict network access to the FUXA management interface to trusted operator networks only
Rotate any tokens or credentials that may have been exposed through the affected endpoints

Patch Information

The fix is included in FUXA v1.3.1. The maintainers documented the authentication issue in GHSA-r9g5-7q8j-958c. Operators should validate secureEnabled=true after upgrading and test that guest and invalid-token requests are rejected with an authentication error.

Workarounds

Place FUXA behind a reverse proxy that requires authentication before forwarding to the project, alarms, and scheduler routes
Apply network access control lists to block untrusted sources from reaching the FUXA HTTP interface
Disable public exposure of the FUXA instance until the 1.3.1 upgrade is validated in production

bash

# Example nginx snippet to require basic authentication in front of FUXA
location /api/ {
    auth_basic "FUXA restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:1881;
}