CVE-2025-11246 in Community Edition
Summary
by MITRE • 01/09/2026
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.4 before 18.5.5, 18.6 before 18.6.3, and 18.7 before 18.7.1 that could have allowed an authenticated user with specific permissions to remove all project runners from unrelated projects by manipulating GraphQL runner associations.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 01/23/2026
This vulnerability exists within GitLab community and enterprise editions across multiple version ranges, specifically impacting installations from version 15.4 through 18.5.4, 18.6 through 18.6.2, and 18.7 through 18.7.0. The flaw represents a privilege escalation issue that allows authenticated users with certain permissions to manipulate GraphQL runner associations in a manner that enables them to remove all project runners from unrelated projects. This represents a significant security concern as it undermines the isolation mechanisms that should protect separate projects within the same GitLab instance. The vulnerability stems from inadequate access controls and validation within the GraphQL API endpoints responsible for managing runner associations, creating a path for unauthorized modification of runner configurations across project boundaries.
The technical implementation of this vulnerability involves the manipulation of GraphQL queries that handle runner associations between projects and runners. An authenticated user with specific permissions can craft malicious GraphQL requests that bypass normal access controls and execute operations that should be restricted to project owners or administrators. This flaw typically requires the attacker to have at least contributor-level permissions on a project, though the exact permission requirements may vary based on the specific GitLab configuration and version. The vulnerability exploits the lack of proper authorization checks when processing GraphQL mutations related to runner assignment, allowing an attacker to target runners associated with other projects through carefully constructed API calls.
The operational impact of this vulnerability extends beyond simple permission bypass, as it can lead to significant disruption of CI/CD pipelines and potential service degradation across multiple projects. When an attacker successfully removes all runners from unrelated projects, it effectively disables continuous integration and deployment capabilities for those projects, potentially halting development workflows and automated testing processes. This can result in substantial business disruption, particularly in environments where multiple teams rely on shared GitLab instances for their development operations. The vulnerability also creates a potential for data integrity issues, as the removal of runners may cause pipeline failures that could result in uncommitted changes or incomplete builds. Organizations may experience cascading effects as automated processes across multiple projects become unavailable, potentially leading to extended downtime and recovery efforts.
Mitigation strategies for this vulnerability should focus on immediate patching of affected GitLab installations to versions 18.5.5, 18.6.3, or 18.7.1, depending on the current version in use. Organizations should also implement additional monitoring of GraphQL API endpoints for unusual activity patterns, particularly around runner association modifications. Access control reviews are essential to ensure that only authorized personnel have the necessary permissions to manage runners, and that least privilege principles are enforced. Network-level controls can be implemented to restrict access to GraphQL endpoints where possible, though this should not replace proper application-level authentication. The vulnerability aligns with CWE-284 (Improper Access Control) and can be mapped to ATT&CK technique T1078.004 (Valid Accounts: Cloud Accounts) when attackers leverage legitimate accounts with appropriate permissions to exploit the vulnerability. Organizations should also consider implementing automated security scanning of their GitLab installations to identify similar access control issues that may exist in other parts of their CI/CD infrastructure.