Loading vulnerability…
Improper access control in GitLab Workspaces cross-group agent association
CVE-2023-6955 is an improper access control vulnerability in GitLab Remote Development / GitLab Workspaces. In affected versions, authorization checks are insufficient when creating a workspace, allowing a workspace created under one group or root namespace to be associated with an agent belonging to a different group. This breaks expected group-boundary isolation in the Workspaces feature and permits cross-namespace resource association that should be rejected by the application.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation allows an attacker to create a GitLab workspace in one group while binding it to an agent from another group. The primary impact is unauthorized cross-group resource use and violation of tenant or namespace isolation within GitLab Workspaces. Depending on how the affected deployment uses agents and workspace trust boundaries, this could expose functionality or resources that should be restricted to the agent's owning group and could undermine administrative and security assumptions around group scoping.
If you can’t patch tonight, do this now.
No specific workaround is currently available in the provided information beyond applying the vendor fix. As a temporary risk-reduction measure, organizations should restrict access to GitLab Workspaces and Remote Development features to trusted users, review group and agent administration practices, and monitor for unexpected workspace creation or cross-group agent associations until patching is completed.
Patch, then assume compromise.
Upgrade GitLab to a fixed release. Affected versions are all versions prior to 16.5.6, 16.6 prior to 16.6.4, and 16.7 prior to 16.7.2. Later vendor guidance also recommended upgrading beyond the initial patch set to 16.5.7, 16.6.5, 16.7.3, or newer because of an additional database migration issue in the earlier releases. Self-managed deployments should apply the vendor-supported fixed version appropriate to their branch.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
4 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.