CVE-2026-81906 in Concrete CMS
Summary
by MITRE • 09/11/2026
Concrete CMS OAuth callback login path prior to version 9.5.3 did not check whether an account was active or email-validated before establishing a session. A deactivated or unvalidated user with an existing OAuth binding could complete authentication and receive a session that was fully authenticated for the callback response, with the login recorded and login events dispatched. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 6.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified in Concrete CMS versions prior to 9.5.3 represents a critical flaw within the OAuth authentication workflow, specifically concerning the validation of user account status during session establishment. The core technical issue lies in the callback handler logic which processes incoming authorization responses from external identity providers. Upon receiving a successful authentication response, the system associates the provided credentials with an existing local user account based on email or other unique identifiers. However, this process fails to perform necessary security checks regarding the current state of that user account before issuing a session token and recording the login event. Specifically, the application does not verify whether the associated account has been deactivated by an administrator or if it is still in a pending validation state due to unverified email addresses. This oversight allows users who should be denied access based on administrative actions or incomplete registration processes to bypass these restrictions entirely through the OAuth flow.
From a technical perspective, this flaw constitutes a logic error where the authentication mechanism trusts external identity assertions without validating local account policies. In standard security architectures, an authorization server must ensure that the resource owner's account is active and compliant with organizational policy before granting access tokens or establishing sessions. By skipping these checks, Concrete CMS effectively treats all OAuth-bound accounts as fully authorized regardless of their internal status flags. This creates a scenario where a deactivated user retains functional authentication capabilities because the system prioritizes the successful external login over local account management rules. The vulnerability is particularly insidious because it operates silently in the background during standard login procedures, making it difficult to detect through routine monitoring unless specific anomalies in session creation are tracked against disabled accounts.
The operational impact of this vulnerability allows for unauthorized access by users who have been explicitly removed from or suspended within the system. For organizations relying on Concrete CMS for content management with strict user governance policies, such as educational institutions or corporate intranets, this represents a significant security risk. An attacker could exploit this to regain access after being deactivated, potentially leading to data exfiltration, unauthorized modifications, or further privilege escalation if combined with other vulnerabilities. The CVSS v4.0 score of 6.3 reflects the medium severity of the issue, highlighting that while it requires no user interaction and has low complexity, its impact is primarily limited to integrity rather than confidentiality or availability in many contexts. However, for systems where account deactivation is a primary control mechanism for revoking access, this flaw undermines the fundamental principle of least privilege and proper identity lifecycle management.
This vulnerability aligns with CWE-287 Improper Authentication as it involves a failure to correctly verify user credentials against current system state policies. It also relates to CWE-613 Insufficient Session Expiration in terms of session validity relative to account status, although the primary issue is authentication bypass rather than expiration timing. In the context of MITRE ATT&CK, this behavior can be categorized under Tactic TA0004: Privilege Escalation or more accurately under Initial Access techniques where an attacker leverages valid credentials that should have been invalidated. The specific technique resembles T1078 Valid Accounts but with a twist involving account status manipulation bypasses common in enterprise identity management systems.
Mitigation for this vulnerability requires immediate upgrading to Concrete CMS version 9.5.3 or later, which includes the necessary code changes to validate user account status during the OAuth callback process. Administrators should ensure that their deployment pipelines are updated and verify that no legacy instances remain unpatched in production environments. Additionally, implementing robust logging mechanisms can help detect any anomalous login attempts from deactivated accounts if upgrading is not immediately feasible, although this serves only as a compensatory control rather than a fix. Security teams should also review their OAuth provider configurations to ensure they are aware of the implications and monitor for unusual activity patterns that might indicate exploitation attempts during the window before patching occurs.