CVE-2026-12910 in GitLab
Summary
by MITRE • 09/15/2026
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.6 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that under certain conditions could have allowed an authenticated user to bypass SAML SSO sign-in restrictions and authenticate without SSO due to missing authentication enforcement checks.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
GitLab has addressed a critical security vulnerability affecting its Community Edition (CE) and Enterprise Edition (EE) platforms, specifically impacting versions ranging from 18.6 up to but not including 19.1.8, as well as the 19.2 series prior to version 19.2.6 and the 19.3 series prior to version 19.3.2. This flaw represents a significant deviation in access control logic within the authentication subsystem, allowing for unauthorized bypass of configured Single Sign-On (SSO) policies. The vulnerability stems from missing or incomplete enforcement checks during the SAML SSO sign-in process, which is a common method organizations use to centralize identity management and enforce strict security protocols across their development environments.
The technical nature of this flaw lies in the failure of the application to properly validate authentication state when handling SAML assertions under specific conditions. In a correctly secured environment, any user attempting to access GitLab resources that are governed by an organization-wide or group-level SSO requirement must be redirected through the identity provider and successfully complete the SAML handshake before gaining entry. However, due to this implementation error, certain code paths failed to enforce these restrictions, effectively allowing authenticated users who had previously logged in via standard username and password methods, or potentially other non-SSO mechanisms, to retain access even when their account was subsequently subject to mandatory SSO enforcement. This bypass occurs because the session validation logic did not re-evaluate the authentication method against current policy requirements upon subsequent requests or specific state transitions within the application flow.
From an operational perspective, this vulnerability poses a severe risk to organizations that rely on GitLab for secure software development lifecycle management. The primary impact is the circumvention of identity governance controls designed to ensure that all users authenticate through approved channels. This can lead to unauthorized access if legacy credentials are compromised or if accounts were provisioned without proper SSO integration initially but later required it due to policy changes. Furthermore, it undermines audit trails and compliance reporting, as actions taken by these bypassing users may not be correctly attributed to the centralized identity provider, making forensic analysis more difficult. The ability to authenticate without adhering to strict SSO policies also increases the attack surface for credential stuffing attacks or phishing campaigns targeting individual user passwords rather than requiring multi-factor authentication typically enforced at the IdP level.
This issue is categorized under CWE-287, which describes Improper Authentication, as it involves a failure in verifying credentials against established security policies. It aligns with MITRE ATT&CK technique T1078, specifically Valid Accounts, where an adversary uses legitimate account credentials to gain access without detection by bypassing intended authentication mechanisms. The vulnerability highlights the importance of rigorous state management and policy enforcement checks within web applications that handle sensitive identity data.
To mitigate this risk, organizations running affected versions must upgrade immediately to GitLab 19.1.8 or later for the 19.1 branch, 19.2.6 or later for the 19.2 branch, and 19.3.2 or later for the 19.3 branch. Until an upgrade is performed, administrators should monitor access logs closely for anomalies in authentication patterns, particularly looking for sessions that appear to bypass expected SSO redirects. Additionally, enforcing multi-factor authentication at the identity provider level can provide a compensating control, reducing the likelihood of successful exploitation even if the application-level check fails. Regular security audits and penetration testing focused on authentication flows are recommended to ensure no similar logic flaws exist in other parts of the platform.