CVE-2026-65984 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, POST /api/refresh in server/api/auth/index.js falls back from current user data to decoded.groups, including when the user is deleted or groups is zero, and POST /api/heartbeat in server/api/index.js re-signs inbound JWT claims without validating the current database record. An attacker who possesses a previously issued privileged refresh cookie or access token can continue minting privileged JWTs after account deletion, disablement, role removal, or demotion. Continued refresh-cookie rotation can extend the stale session and preserve unauthorized access to user management, project manipulation, runtime configuration, scripts, and backdoor-account creation. This issue is fixed in version 1.3.3.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
FUXA serves as a web-based Process Visualization software functioning within SCADA, HMI, and dashboard environments, where access control mechanisms are critical for maintaining operational integrity and security. In versions prior to 1.3.3, specifically affecting version 1.3.2 and earlier, the authentication and session management subsystems contain significant logic flaws that undermine identity verification processes. These vulnerabilities reside primarily within the server-side API endpoints responsible for handling user sessions and token refresh operations, creating a pathway for unauthorized privilege retention even after administrative actions intended to revoke access have been executed.
The first critical flaw involves the POST /api/refresh endpoint located in server/api/auth/index.js. This function is designed to issue new access tokens based on existing credentials but fails to properly validate the current state of the user account against the database before generating a response. Instead, it falls back to using decoded.groups from the incoming token or session data when determining permissions. Consequently, if a user account has been deleted, disabled, or had their roles removed and demoted in the backend database, the system continues to trust the legacy group information embedded within the existing JWT claims rather than querying the authoritative source of truth. This logic error allows an attacker who possesses a previously issued privileged refresh cookie or access token to continue minting new privileged JWTs indefinitely, effectively bypassing administrative revocation efforts.
A second related vulnerability exists in the POST /api/heartbeat endpoint found in server/api/index.js. This routine is responsible for maintaining active sessions by re-signing inbound JSON Web Token claims without validating them against the current database record of the user. By failing to cross-reference the token's contents with live account status, the system permits session extension and privilege preservation even when the associated account no longer exists or has been restricted. The combination of these two flaws means that continued refresh-cookie rotation can extend stale sessions indefinitely, preserving unauthorized access to sensitive functionalities including user management interfaces, project manipulation tools, runtime configuration settings, script execution environments, and potentially backdoor-account creation capabilities.
From a technical classification perspective, this vulnerability aligns with CWE-270, which describes the privilege context error where an application fails to properly maintain or update privileges during state transitions such as account deletion or role change. It also relates closely to CWE-613, insufficient session expiration, and CWE-862, missing authorization checks within critical business logic flows. In terms of adversarial tactics, this behavior facilitates the ATT&CK technique T1078, Valid Accounts, specifically allowing attackers to maintain persistence using legitimate credentials that should have been invalidated by system administrators. The ability to mint new tokens from old ones without re-authentication against a live directory constitutes a severe breach of trust boundaries within the application's security model.
The operational impact of these flaws is substantial in industrial control systems and enterprise dashboards where FUXA is deployed. An attacker with initial access, whether through stolen credentials or session hijacking, can retain full administrative privileges long after an incident response team has attempted to neutralize the threat by disabling accounts. This persistence mechanism complicates forensic analysis and remediation efforts, as standard account deactivation procedures prove ineffective against this specific implementation flaw. The ability to manipulate runtime configurations and execute scripts further elevates the risk from mere data exfiltration to potential operational disruption or compromise of connected industrial processes.
To mitigate these risks, organizations must immediately upgrade FUXA to version 1.3.3 or later, where the authentication logic has been corrected to enforce strict validation against current database records during token refresh and heartbeat operations. Until an upgrade is feasible, administrators should implement network-level controls such as short-lived session timeouts and aggressive cookie expiration policies to limit the window of opportunity for attackers exploiting stale tokens. Additionally, deploying a Web Application Firewall with rules targeting suspicious JWT manipulation patterns may provide partial protection by detecting anomalous request frequencies or malformed token structures associated with this exploitation technique. Regular audits of active sessions against user account status can also help identify lingering unauthorized access resulting from these specific logic flaws in older versions.