CVE-2021-22240
Description
Improper access control in GitLab EE versions 13.11.6, 13.12.6, and 14.0.2 allows users to be created via single sign on despite user cap being enabled
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
In GitLab EE, SSO user creation bypasses the user cap, allowing accounts to be auto-approved despite block_auto_created_users being enabled.
Vulnerability
GitLab EE versions 13.11.6, 13.12.6, and 14.0.2 contain an improper access control vulnerability in the single sign-on (SSO) user creation flow. When the user_cap setting is enabled and gitlab_rails['omniauth_block_auto_created_users'] is set to true, new users signing up via SSO are auto-approved instead of being blocked, as intended by the block_auto_created_users configuration [1]. The issue arises because the SetUserStatusBasedOnUserCapSettingWorker does not respect the block setting during SSO callbacks [1].
Exploitation
An attacker needs only network access to the GitLab instance and the ability to initiate an SSO login via a configured provider (e.g., GitLab itself or other OAuth/OpenID providers). No special authentication is required beforehand. The vulnerable code path is triggered when a new user attempts to sign up through SSO while the user cap is enabled, resulting in the user being automatically approved instead of blocked [1].
Impact
Successful exploitation allows an attacker to create new user accounts on the GitLab instance even when the administrator has set a user cap to limit total accounts. The new user may gain immediate access to the instance with the default permissions granted to new users, potentially leading to unauthorized resource access or account abuse [1].
Mitigation
GitLab has fixed this issue in versions 13.11.7, 13.12.7, and 14.0.3. Administrators should upgrade to one of these patched releases or later. No workaround is available; enabling block_auto_created_users without upgrading will not enforce the block when the user cap is set [1].
AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: 13.11.6, 13.12.6, 14.0.2
- Range: >=13.7, <13.11.6
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"The `SetUserStatusBasedOnUserCapSettingWorker` does not block newly created SSO users when `omniauth_block_auto_created_users` is enabled alongside a user cap."
Attack vector
An attacker can sign up via any configured SSO provider (e.g., GitLab as an OmniAuth provider) on a GitLab EE instance where both a user cap and `omniauth_block_auto_created_users = true` are set. The first SSO callback creates the user and returns a 401, but the user is not actually blocked — the `SetUserStatusBasedOnUserCapSettingWorker` runs and completes without blocking the account. On a subsequent sign-in attempt, the user is rejected by the OmniauthCallbacksController#failure path, but the unblocked user account already exists and can be used [ref_id=1].
Affected code
The issue is in the OmniauthCallbacksController, specifically in the callback handling for SSO providers. The `SetUserStatusBasedOnUserCapSettingWorker` is invoked after a user is created via SSO, but the worker does not enforce the `omniauth_block_auto_created_users` setting when a user cap is enabled [ref_id=1].
What the fix does
No patch is included in the bundle. The advisory [ref_id=1] identifies that the `SetUserStatusBasedOnUserCapSettingWorker` does not block newly created users when `omniauth_block_auto_created_users` is true and a user cap is enabled. The expected remediation would be to ensure that the worker (or the callback controller) respects the `block_auto_created_users` setting by blocking the user account at creation time rather than leaving it active.
Preconditions
- configGitLab EE instance must have a user cap configured
- configGitLab EE instance must have omniauth_block_auto_created_users set to true
- authAttacker must have access to a configured SSO provider (e.g., GitLab OmniAuth)
- authAttacker must not already have an account on the instance
Reproduction
Set user cap and `gitlab_rails['omniauth_block_auto_created_users']=true` in the GitLab configuration, then attempt to sign up using any SSO provider. The first sign-in attempt returns a 401 but creates an unblocked user account. A second sign-in attempt is redirected to the sign-in page, but the account remains active [ref_id=1].
Generated on May 25, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3- gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22240.jsonmitrex_refsource_CONFIRM
- gitlab.com/gitlab-org/gitlab/-/issues/327641mitrex_refsource_MISC
- hackerone.com/reports/1166566mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.