CVE-2026-41891: CI4MS Auth Bypass Vulnerability

CVE-2026-41891 Overview

CVE-2026-41891 affects CI4MS, a CodeIgniter 4-based content management system (CMS) skeleton with role-based access control (RBAC) authorization and theme support. The vulnerability exists in the authentication filter, where the check for deactivated and banned users is commented out. As a result, users whose accounts have been disabled or banned by administrators retain valid sessions and can continue to access protected resources. The flaw affects versions from 0.26.0 up to but not including 0.31.8.0. Maintainers patched the issue in version 0.31.8.0.

Critical Impact

Deactivated and banned user accounts retain functional access to authenticated areas of the CMS, defeating administrative account suspension controls and enabling continued abuse by revoked users.

Affected Products

• CI4MS versions 0.26.0 through 0.31.7.x
• CodeIgniter 4-based deployments using the affected ci4ms package
• Applications relying on CI4MS auth filter for session validation

Discovery Timeline

• 2026-05-07 - CVE-2026-41891 published to the National Vulnerability Database (NVD)
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-41891

Vulnerability Analysis

The vulnerability is an authorization bypass classified under [CWE-613] Insufficient Session Expiration. CI4MS implements an authentication filter that runs on protected routes to validate user sessions. This filter is expected to verify that the requesting user is authenticated, that the session is valid, and that the underlying account remains active and not banned.

In affected releases, the code path that checks the account status flag (deactivated or banned) is commented out within the auth filter. Authentication succeeds on session validity alone. Account state is never reconciled against the database during request handling.

The practical effect is that an administrator who deactivates or bans a user does not terminate that user's access. The user can continue interacting with any endpoint protected by the auth filter until their session expires naturally.

Root Cause

The root cause is missing runtime authorization enforcement in the auth filter. Source code intended to query the user's status or banned attribute and reject the request was disabled by being commented out. This is a configuration and design flaw rather than a logic error in the surrounding code.

Attack Vector

Exploitation requires an authenticated session belonging to an account that has been deactivated or banned. The attacker reuses an existing session cookie or active browser session against any route protected by the affected auth filter. No special tooling is needed. The request succeeds because the filter never re-evaluates account status.

The vulnerability cannot be triggered without prior valid credentials, which limits exploitation to former employees, revoked partners, or banned community members. The impact remains scoped to whatever functionality the original account was authorized to use under its assigned RBAC role.

No public proof-of-concept exploit has been published. Refer to the GitHub Security Advisory GHSA-5hfv-c864-qcq9 for upstream technical context.

Detection Methods for CVE-2026-41891

Indicators of Compromise

• Successful authenticated requests from accounts marked as deactivated or banned in the user database.
• Application logs showing actions performed by user IDs whose status flags indicate suspension.
• Session cookies remaining valid after administrative account disablement events.

Detection Strategies

• Compare web access logs against the user status table and alert when disabled accounts produce successful requests.
• Add database-side audit triggers that log every request reaching protected controllers and join against users.status for review.
• Inspect deployed app/Filters source for commented-out deactivated or banned checks across the CI4MS codebase.

Monitoring Recommendations

• Forward CI4MS application and authentication logs to a centralized SIEM for correlation against account lifecycle events.
• Track the time delta between administrative account disablement and the last observed session activity for that account.
• Monitor for elevated request volumes from accounts that should have been revoked, particularly to administrative or RBAC-protected endpoints.

How to Mitigate CVE-2026-41891

Immediate Actions Required

• Upgrade CI4MS to version 0.31.8.0 or later, which restores the deactivated and banned user check in the auth filter.
• Invalidate all existing sessions after upgrading so previously suspended users cannot resume access with cached cookies.
• Audit the user table for accounts flagged as deactivated or banned and confirm none have recent successful authenticated activity.

Patch Information

The issue was fixed in CI4MS 0.31.8.0. The patched release reinstates the account status check inside the auth filter, ensuring that deactivated and banned accounts are rejected on every protected request. Release notes and source diffs are available in the GitHub Release 0.31.8.0.

Workarounds

• Reduce session lifetime in the CodeIgniter 4 session configuration so revoked accounts lose access more quickly.
• Force a global session reset whenever an administrator deactivates or bans a user, for example by rotating the session encryption key or truncating the sessions store.
• Add a temporary middleware in front of the auth filter that performs an explicit status lookup against the users table on every authenticated request until the upgrade is deployed.

# Configuration example
composer require ci4-cms-erp/ci4ms:^0.31.8.0
php spark migrate
php spark session:clear