CVE-2026-41891

mediumpriority · track · 0EPSS 0.003 · 19 %ileEUUS
grimoire priorityP3 · Track
Exploitable?
—
no known exploitation
Likely / severe?
0.27% (19th) EPSS
CVSS 5.3 · medium
Is it mine?
2 products
Check your exposure
Who says so?
3 sources
cnnvd · enisa_euvd · osv

EPSS · scored 2026-10-27

CI4MS is a CodeIgniter 4-based CMS skeleton that delivers a production-ready, modular architecture with RBAC authorization and theme support. From version 0.26.0 to before version 0.31.8.0, the auth filter has the deactivated/banned user check commented out. This issue has been patched in version 0.31.8.0.

01

cvss

Technical severity, 0–10. One row per scoring source.

5.3
010

base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · low–medium · 1.3–5.3

v4.05.3mediumCVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:Nsecondary · ENISA EU
v4.05.3mediumCVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Xsecondary · security-advisories@github.com
v4.01.3lowCVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Xsecondary · CVSS-BT (t0sche)
02

ssvc

A stakeholder decision — act, attend, or track — from exploitation and impact.

Trackcoordinatorcisa_ssvcUS
03

weaknesses

The CWE weakness classes this flaw belongs to.

04

affected products (2)

Products and version ranges known to be affected.

05

advisories (1)

Vendor and ecosystem advisories describing this.

  • GHSA-5hfv-c864-qcq9CI4MS has a Deactivated User Session Bypass (active=0)2026-05-04ghsa · osvUS

    ### Summary The auth filter has the deactivated/banned user check commented out. ### Details CodeIgniter Shield's `loggedIn()` re-checks the `status` field (catching `status='banned'`), but does **not** re-check the `active` field for existing sessions. When an admin deactivates a user (`active=0`) after they have already logged in: - Their session cookie remains valid - `auth()->loggedIn()` still returns `true` - The commented-out code is the only mechanism that would have checked `!$user->active` ### Evidence <img width="981" height="654" alt="image" src="https://github.com/user-attachments/assets/6f75d144-5bcf-4a3f-bc35-bb0715c3ed05" /> ### Impact - User deactivation does NOT immediately revoke backend access - Deactivated user retains full access until session expires (default: 7200s) ### Additional note The commented-out block appears to be a deferred placeholder — it was written but disabled from the very first commit that introduced the filter, and has never been active. The later addition of SessionTracker (v0.31.4.0) suggests the dev was aware of the session revocation gap, but account-level deactivation (users.active = 0) remains unenforced. Could you verify if this is intentionally pending or simply forgotten and not documented?.

06

also known as (3)

Other names and identifiers for this entity.

07

sources

Which sources assert this record, and when.

published 2026-05-07modified 2026-10-26
08

references (6)

External citations — patches, advisories, analysis.

scry

Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.

Free scan