CVE-2026-92874 in GitLab
Summary
by MITRE • 09/24/2026
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.3 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an authenticated user with an MCP-scoped token to perform actions beyond the intended scope of that token due to improper authorization checks.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/24/2026
GitLab has addressed a critical security vulnerability impacting both Community Edition and Enterprise Edition across multiple release branches, specifically versions 18.3 prior to 19.2.7, 19.3 prior to 19.3.3, and 19.4 prior to 19.4.1. This flaw stems from a fundamental failure in the application's authorization logic when handling Machine Control Protocol scoped tokens. The vulnerability allows an authenticated user possessing such a token to execute operations that exceed the permissions explicitly granted by that specific scope, effectively bypassing intended access controls and gaining unauthorized privileges within the GitLab environment.
The technical root cause of this issue lies in improper authorization checks during the processing of MCP-scoped requests. In secure software architecture, tokens with limited scopes should strictly enforce boundaries on which resources can be accessed or modified. However, due to a logic error in the validation layer, the system failed to correctly map the token's specific permissions against the requested action. This discrepancy means that while the user is authenticated and possesses a valid token, the application does not adequately verify whether the current operation aligns with the restricted scope defined for that token. Consequently, actions intended to be blocked or limited by the MCP scope are permitted to proceed as if they were authorized under broader administrative privileges.
The operational impact of this vulnerability is significant because it compromises the principle of least privilege within GitLab's API and automation workflows. An attacker who obtains an MCP-scoped token could potentially escalate their access level, leading to unauthorized modifications of repositories, changes to project settings, or exposure of sensitive data that should remain protected under strict scope limitations. This type of authorization bypass is particularly dangerous in automated CI/CD pipelines or integration scenarios where tokens are used for programmatic interactions with the GitLab instance. If an attacker can exploit this flaw, they may achieve persistent access or perform destructive actions without triggering standard security alerts associated with full administrative compromise.
This vulnerability aligns closely with Common Weakness Enumeration identifier CWE-269, which describes Improper Privilege Control, and specifically relates to authorization bypass scenarios often categorized under ATT&CK technique T1078, Valid Accounts. The failure to enforce scope boundaries represents a classic case where authentication succeeds but authorization fails due to insufficient validation of user permissions against the requested resource actions. Organizations relying on GitLab for version control and DevOps automation must recognize that even scoped tokens are not immune to privilege escalation flaws if underlying access control logic is flawed.
To mitigate this risk, immediate action is required by upgrading all affected instances to a patched version. Users running versions 18.3 through 19.2 should upgrade to at least version 19.2.7. Those on the 19.3 branch must update to version 19.3.3 or later, and users of the 19.4 branch are advised to install version 19.4.1 or newer. Until upgrades can be performed, administrators should review audit logs for any anomalous activity involving MCP-scoped tokens, particularly looking for actions that fall outside typical automation patterns. It is also recommended to rotate all existing MCP-scoped tokens after patching the system to ensure that no potentially compromised credentials remain active in the environment.