CVE-2026-67442: FUXA Business Logic Flaw: Role Deletion Without User Assignment Cleanup
FUXA is a web-based Process Visualization (SCADA/HMI/Dashboard) software. Prior to 1.3.3, DELETE /api/roles removes role definitions through server/runtime/users/usrstorage.js but does not remove the deleted role identifier from each user's info.roles array or the runtime usersMap cache. If a permission configuration still references that identifier, an affected user can retain authorization rights that an administrator intended to revoke, causing residual privilege, inconsistent access-control state, and misleading audit results. 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
Event History
Frequently Asked Questions
Which deployments and configurations are exposed?
FUXA deployments prior to version 1.3.3 are affected. Exposure requires use of role-based permissions where a deleted role identifier remains referenced by a permission configuration and assigned to a user's stored or cached role list.
What conditions are needed for residual privileges to persist?
An administrator must delete a role, and the affected user must still have that role identifier in their info.roles array or the runtime usersMap cache. Residual access occurs only if a permission configuration continues to reference that identifier.
What should administrators do to remediate or mitigate the issue?
Upgrade FUXA to version 1.3.3, which fixes the issue. If upgrading cannot occur immediately, review deleted roles, user role assignments, runtime user cache state, and permission configurations for stale references to deleted role identifiers.
How can an administrator identify an affected access-control state?
Check whether roles have been deleted while affected users still retain the deleted role identifier in their stored info.roles arrays or runtime usersMap cache, and whether permissions still reference that identifier. Such stale references can produce authorization that no longer matches the intended role configuration.