Is there a patch available for CVE-2026-7887?

Yes, a patch is available for CVE-2026-7887. Update the affected software to the latest version immediately.

Concrete CMS CVE-2026-7887

Q: What is the CVSS score of CVE-2026-7887?

CVE-2026-7887 has a CVSS 4.0 base score of 2.3 (Low). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/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:X. EPSS exploitation probability: 0.1%.

EUVD-2026-31364 LOW

Improper Validation of Specified Type of Input (CWE-1287)

2026-05-21 ConcreteCMS

GHSA-f54h-78c9-c24h

Authentication Bypass Concrete Cms

2.3

CVSS 4.0 · NVD

Severity by source

NVD PRIMARY

2.3 LOW

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/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:X

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/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:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

May 21, 2026 - 22:35 vuln.today

DescriptionCVE.org

For Concrete CMS 9.5.0 and below, OAuth 2.0 Authorization-Code Handler Bypasses Account Status. A user with uIsActive=0 (suspended, banned, terminated employee) can still authenticate via OAuth and receive valid API tokens. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 2.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N. Thanks 0x4c616e for reporting.

AnalysisAI

OAuth 2.0 Authorization Code handler in Concrete CMS 9.5.0 and earlier fails to enforce account status checks, allowing users with suspended, banned, or terminated accounts (uIsActive=0) to complete OAuth flows and receive valid API tokens. Deployments using OAuth 2.0 as an authentication mechanism are affected, with the primary real-world impact being unauthorized continued access by deprovisioned users - such as terminated employees or revoked contractors - who retain OAuth credentials. With a CVSS v4.0 score of 2.3, no CISA KEV listing, and no public exploit identified at time of analysis, this is a low-severity issue with narrow scope but meaningful identity governance implications for organizations relying on CMS-level account suspension as a deprovisioning control.

Technical ContextAI

Concrete CMS is a PHP-based content management system; affected versions span 5.0 through 9.5.0 per CPE identifier cpe:2.3:a:concrete_cms:concrete_cms and EUVD-2026-31364. The OAuth 2.0 Authorization Code grant type involves multiple validation steps: credential verification, scope evaluation, and - critically in this case - account lifecycle state validation. The root cause is classified as CWE-1287 (Improper Validation of Specified Type of Input), reflecting the handler's failure to validate the uIsActive field against allowable states before issuing tokens. The uIsActive=0 flag in Concrete CMS's user model represents suspended, banned, or terminated status; this flag is properly enforced in standard login flows but is bypassed in the OAuth authorization code path. The decoupling between the OAuth handler and the account status check creates a gap specifically in federated or API-driven authentication scenarios.

RemediationAI

Upgrade to Concrete CMS 9.5.1, which is referenced in the vendor release notes at https://documentation.concretecms.org/9-x/developers/introduction/version-history/951-release-notes and is inferred to contain the fix for this bypass - note that the fix version is inferred from the referenced URL and should be independently verified against the release notes before deployment. If immediate patching is not feasible, disable the OAuth 2.0 Authorization Code flow in Concrete CMS settings if it is not required for your deployment, as this eliminates the vulnerable code path entirely with the trade-off of losing OAuth-based authentication for all users. Alternatively, audit and manually revoke all active OAuth tokens associated with accounts where uIsActive=0, and implement an out-of-band token revocation step as part of the user offboarding process at the API gateway or OAuth provider level. Organizations using an external identity provider should consider enforcing account status checks at the IdP layer as a defense-in-depth measure, though this does not substitute for patching the CMS-side handler.