CVE-2026-65984: FUXA: JWT lifecycle flaws allow deleted or demoted users to retain privileged sessions
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
FUXAto a version that resolves this vulnerability.Fixed in 1.3.3 - Compensating control
If you suspect active abuse of privileged refresh cookies/tokens for users that were deleted/disabled/demoted, invalidate active sessions/refresh tokens for those accounts to stop continued JWT minting via POST /api/refresh and prevent unauthorized access that can be preserved by ongoing refresh-cookie rotation.
Event History
Frequently Asked Questions
Which versions require remediation?
FUXA 1.3.2 and earlier are affected. The issue is fixed in version 1.3.3.
What must an attacker possess to exploit this?
An attacker needs a previously issued privileged refresh cookie or access token. They can retain privileged access even after the associated user is deleted, disabled, demoted, or has roles removed.
What can be done if patching cannot occur immediately?
Treat previously issued privileged sessions as potentially valid until they are invalidated. If upgrading cannot happen immediately, revoke or otherwise invalidate affected privileged refresh cookies and access tokens, especially for users whose access was removed or reduced.
How can administrators identify potential exposure?
Review whether deleted, disabled, or demoted users have previously held privileged sessions, and investigate continued API activity using their old credentials. Relevant affected endpoints are POST /api/refresh and POST /api/heartbeat.