CVE-2026-67443 in FUXA
Summary
by MITRE • 08/18/2026
FUXA is a web-based Process Visualization (SCADA/HMI/Dashboard) software. In 1.3.2 and earlier, the allowDashboard authorization gate in server/integrations/node-red/index.js calls authJwt.verify for /nodered without inspecting the decoded identity. When nodeRedEnabled is true, secureEnabled is true, and nodeRedAuthMode is secure, a remote unauthenticated attacker can obtain a signed guest token from POST /api/heartbeat and use it to access the RED.httpAdmin editor and flow deployment API. Because the Node-RED configuration has no second adminAuth gate, the attacker can deploy function nodes or invoke fuxa.runScript and runtime.scriptsMgr.runScript, gaining control of FUXA project data, configuration, scripts, filesystem-capable runtime helpers, and potentially operating-system commands when nodeRedUnsafeModules is enabled. This issue is fixed in version 1.3.3.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
FUXA serves as a web-based Process Visualization platform functioning within SCADA, HMI, and dashboard environments, where the integrity of configuration and runtime execution is critical for industrial operations. In versions prior to 1.3.3, specifically up through version 1.3.2, a significant authentication bypass vulnerability exists within the Node-RED integration layer. The core technical flaw resides in the allowDashboard authorization gate located in server/integrations/node-red/index.js. This function is designed to verify user identity via authJwt.verify when accessing the /nodered endpoint; however, it fails to inspect or validate the decoded identity payload returned by the verification process. Consequently, the system does not enforce proper access control checks against the actual authenticated principal, allowing requests that lack valid administrative credentials to proceed if specific configuration flags are enabled.
The operational impact of this flaw is severe when the server is configured with nodeRedEnabled set to true, secureEnabled set to true, and nodeRedAuthMode set to secure. Under these conditions, a remote unauthenticated attacker can exploit the missing identity inspection by obtaining a signed guest token through a POST request to /api/heartbeat. This guest token, which should only grant limited or no access, is subsequently accepted as valid for accessing the RED.httpAdmin editor and the flow deployment API within Node-RED. Because the Node-RED configuration lacks a secondary adminAuth gate to re-validate permissions after this initial bypass, the attacker effectively gains full administrative control over the Node-RED environment embedded within FUXA.
Once inside the Node-RED interface, the attacker can deploy malicious function nodes or invoke internal methods such as fuxa.runScript and runtime.scriptsMgr.runScript. This capability allows for complete compromise of FUXA project data, configuration files, and script repositories. Furthermore, if the nodeRedUnsafeModules setting is enabled, which permits access to Node.js modules that interact with the underlying operating system, the attacker can execute arbitrary commands on the host machine. This escalation from web application control to OS-level command execution represents a critical security failure, potentially leading to data exfiltration, lateral movement within the industrial network, or complete service disruption.
This vulnerability is classified under CWE-287 as an Improper Authentication issue, specifically reflecting a failure in verifying identity after token validation. In terms of attack patterns, it aligns with MITRE ATT&CK techniques related to Initial Access via Web Applications and Privilege Escalation through misconfigured access controls. The exploitation path also touches upon Command Injection principles if unsafe modules are utilized. To mitigate this risk, organizations must upgrade FUXA to version 1.3.3 or later where the identity inspection logic has been corrected. Additionally, administrators should review their Node-RED configurations to ensure that nodeRedUnsafeModules is disabled unless absolutely necessary and strictly controlled, thereby reducing the blast radius of any potential future vulnerabilities in the integration layer.