CVE-2026-46657: Bludit CMS Auth Bypass Vulnerability

CVE-2026-46657 Overview

CVE-2026-46657 affects Bludit, a flat-file content management system (CMS). Versions prior to 3.22.0 contain a flaw in the user management logic that lets deactivated accounts retain access through persistent authentication tokens. When an administrator disables a user account, the application does not invalidate or clear the associated tokenAuth and tokenRemember fields stored in the JSON database. Any user with a pre-existing "Remember Me" cookie can bypass the account disablement and maintain an authenticated session. The issue is classified under [CWE-212] (Improper Removal of Sensitive Information Before Storage or Transfer). Version 3.22.0 patches the issue.

Critical Impact
Disabled Bludit accounts retain valid authenticated sessions through stale "Remember Me" cookies, defeating the account lockout control entirely.

Affected Products

Bludit CMS versions prior to 3.22.0
Bludit CMS instances with users who previously enabled the "Remember Me" option
Bludit deployments relying on the administrator account disablement function for access revocation

Discovery Timeline

2026-06-08 - CVE-2026-46657 published to NVD
2026-06-09 - Last updated in NVD database

Technical Details for CVE-2026-46657

Vulnerability Analysis

Bludit stores user state, including authentication artifacts, in a JSON-based flat-file database. The application supports a "Remember Me" feature that issues long-lived authentication tokens written to the tokenAuth and tokenRemember fields of each user record. Clients present these tokens via cookie to re-establish sessions without re-entering credentials.

The user management workflow exposes a function to disable an account, intended to revoke access without deleting the user. The disablement routine flips the account status flag but does not regenerate or clear the persisted token fields. Because session re-establishment validates the cookie token against the stored token rather than the account status flag, the disabled user remains effectively logged in.

The attack requires an attacker who already holds a valid "Remember Me" cookie from a prior session. This makes the issue most relevant in insider-threat, offboarding, and compromised-account scenarios where an administrator believes access has been revoked.

Root Cause

The defect is a state-synchronization failure between two parallel authentication signals. The account-status check and the token-validation check are not coupled, so revocation of one does not propagate to the other. The fix in version 3.22.0 ensures token fields are cleared or invalidated as part of the disablement operation.

Attack Vector

Exploitation is remote and requires the attacker to possess a previously issued "Remember Me" cookie. The attacker submits the cookie to any authenticated endpoint of the Bludit application. The server matches the token against the JSON user record and grants a session despite the disabled status. No social engineering or additional credentials are required.

No verified public proof-of-concept code is available. See the GitHub Security Advisory GHSA-ggqg-xvx6-hgwh for the maintainers' technical description.

Detection Methods for CVE-2026-46657

Indicators of Compromise

Authenticated requests from disabled user accounts appearing in Bludit access logs after the disablement timestamp
HTTP requests carrying a BLUDIT-KEY or remember-me cookie tied to a user marked as inactive in bl-content/databases/users.php
Session activity from source IP addresses no longer associated with active employees or contributors

Detection Strategies

Audit the bl-content/databases/users.php file for non-empty tokenAuth or tokenRemember values on accounts with the disabled status flag set
Correlate web server access logs with the current user roster to identify successful authenticated requests from accounts that should be revoked
Compare authentication events against HR offboarding records to surface accounts that retain activity after deactivation

Monitoring Recommendations

Log every administrative action that disables a user and verify the corresponding token fields are emptied in the JSON store
Alert on any authenticated request whose session identifier maps to an account flagged as inactive
Track unusual session longevity in Bludit deployments, particularly cookies that survive password resets or role changes

How to Mitigate CVE-2026-46657

Immediate Actions Required

Upgrade Bludit to version 3.22.0 or later, available from the Bludit 3.22.0 GitHub Release
Manually clear the tokenAuth and tokenRemember fields for every disabled user in bl-content/databases/users.php
Force re-authentication for all active users by rotating tokens after the upgrade

Patch Information

Bludit 3.22.0 modifies the user disablement logic to invalidate persistent authentication tokens at the time of account deactivation. Administrators should review the GitHub Security Advisory GHSA-ggqg-xvx6-hgwh for the full patch notes and validate the fix in a staging environment before production rollout.

Workarounds

Edit bl-content/databases/users.php directly and remove the tokenAuth and tokenRemember values for any account that has been disabled
Disable the "Remember Me" feature in the Bludit configuration to prevent persistent tokens from being issued until upgrade is possible
Restrict administrative endpoints to trusted source IP ranges using a reverse proxy or web application firewall rule

bash

# Configuration example: locate and clear persistent tokens for disabled users
grep -n '"status": "disabled"' bl-content/databases/users.php
# After identifying disabled accounts, set tokenAuth and tokenRemember to empty strings,
# then restart the web server to invalidate cached sessions.