CVE-2026-67442 Overview
CVE-2026-67442 affects FUXA, a web-based Supervisory Control and Data Acquisition (SCADA), Human-Machine Interface (HMI), and dashboard software. The vulnerability resides in the DELETE /api/roles endpoint implemented in server/runtime/users/usrstorage.js. Deleting a role removes the role definition but does not purge the identifier from each user's info.roles array or the runtime usersMap cache. Users can retain authorization tied to a supposedly revoked role, producing residual privilege and inconsistent access-control state. The issue is fixed in FUXA 1.3.3 and is classified as [CWE-284] Improper Access Control.
Critical Impact
Administrators who delete a role in vulnerable FUXA installations may not fully revoke the privileges tied to that role, allowing affected users to retain unintended access to SCADA/HMI functions.
Affected Products
- FUXA versions prior to 1.3.3
- FUXA SCADA/HMI/Dashboard web software (frangoteam/FUXA)
- Deployments exposing the FUXA REST API for role management
Discovery Timeline
- 2026-08-18 - CVE-2026-67442 published to the National Vulnerability Database (NVD)
- 2026-08-19 - Last updated in NVD database
Technical Details for CVE-2026-67442
Vulnerability Analysis
FUXA maintains user-to-role associations in two places: persisted user records containing an info.roles array, and a runtime usersMap cache used for authorization decisions. When an administrator issues DELETE /api/roles, the handler in server/runtime/users/usrstorage.js removes the role definition itself. It fails to iterate users and strip the deleted role identifier from info.roles, and it does not refresh the usersMap cache. Authorization checks that subsequently reference the stale identifier can still grant access, defeating the intent of the administrator action.
Root Cause
The root cause is incomplete state cleanup during a destructive administrative operation. Role deletion updates only the role storage, not the dependent user records and cache entries. This is a classic [CWE-284] Improper Access Control pattern where the authoritative permission surface and the enforcement surface fall out of sync.
Attack Vector
Exploitation requires an authenticated administrator to delete a role and a permission configuration that still references the removed role identifier. A user previously assigned that role continues to satisfy authorization checks tied to the identifier, retaining access after revocation. The attack path is network-based over the FUXA API, but requires high privileges to perform the deletion and user interaction to complete the flawed workflow.
// Patch: server/runtime/users/index.js
// Security: improve settings sanitization and role cleanup (#2394)
return new Promise(function (resolve, reject) {
if (roles && roles.length) {
usrstorage.removeRoles(roles).then(() => {
const roleIds = new Set(roles.map(role => role.id));
for (const [username, user] of usersMap) {
if (Array.isArray(user.info?.roles)) {
usersMap.set(username, {
info: Object.assign({}, user.info, {
roles: user.info.roles.filter(roleId => !roleIds.has(roleId))
}),
groups: user.groups
});
}
}
resolve();
}).catch(function (err) {
logger.error(`users.usrstorage-remove-role failed! ${err}`);
Source: FUXA commit 7ce84dc
A second patch hardened the /api/settings endpoint by adding authMiddleware and role-aware sanitization through getSanitizedSettings and getPublicSettings, ensuring secrets such as secretCode, smtp.password, and daqstore.credentials are only exposed to administrators.
Detection Methods for CVE-2026-67442
Indicators of Compromise
- API access logs showing DELETE /api/roles calls followed by continued successful requests from users previously assigned the deleted role.
- User records in FUXA storage containing info.roles entries that do not correspond to any existing role definition.
- Audit output that reports a role as deleted while permission evaluations continue to reference the same role identifier.
Detection Strategies
- Compare each user's info.roles array against the current set of defined role IDs to identify orphaned references.
- Correlate role-deletion events with subsequent authorization decisions to detect access granted via stale identifiers.
- Review permission configuration files for references to role identifiers that no longer exist in usrstorage.
Monitoring Recommendations
- Alert on any DELETE /api/roles request against FUXA instances and require follow-up validation of downstream user records.
- Log the pre- and post-state of usersMap around administrative role operations to make drift visible.
- Track authentication and authorization outcomes per user after role changes to detect retained privileges.
How to Mitigate CVE-2026-67442
Immediate Actions Required
- Upgrade FUXA to version 1.3.3 or later, which includes the fix in pull request #2394.
- Audit all user records and remove any info.roles entries that no longer map to a defined role.
- Review permission configurations and eliminate references to deleted role identifiers.
Patch Information
The fix is delivered in FUXA v1.3.3 via pull request #2394 and commit 7ce84dc29a691b30016d65db17012bb8b282dcf0. Details are documented in the GHSA-cqww-jqx5-p32v security advisory. The patch removes deleted role identifiers from each user's info.roles array and updates the runtime usersMap cache atomically with role deletion.
Workarounds
- Restrict access to the FUXA administrative API to trusted networks and administrators until the upgrade is applied.
- After deleting a role, manually edit each affected user record to remove the stale role identifier and restart the FUXA runtime to rebuild usersMap.
- Recreate user accounts with the intended role set rather than relying on role deletion to revoke privileges.
# Upgrade FUXA to the patched release
git clone https://github.com/frangoteam/FUXA.git
cd FUXA
git checkout v1.3.3
npm install
npm run build
# Restart the FUXA service after upgrade
systemctl restart fuxa
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
