Loading vulnerability…
Improper authorization account takeover in GitLab EE Group SAML identity management
CVE-2026-6552 is an improper authorization vulnerability in GitLab Enterprise Edition affecting the Group SAML identity management functionality, including the Group SAML Identity API. In affected versions, authorization checks were insufficient under certain conditions, allowing an authenticated user who already held the Owner role within a group to manipulate Group SAML identity management in a way that could result in takeover of another member's GitLab account. The issue affects GitLab EE versions from 15.5 before 18.10.8, 18.11 before 18.11.5, and 19.0 before 19.0.2.
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 can lead to full takeover of another group member's GitLab account by a malicious authenticated group Owner. This creates high confidentiality and integrity impact because the attacker may gain access to the victim's data, projects, and actions available through that account, and may perform unauthorized changes as the compromised user. Available information indicates no direct availability impact.
If you can’t patch tonight, do this now.
If immediate patching is not possible, reduce exposure by tightly limiting assignment of the group Owner role, especially in groups using SAML-based identity management, and review Group SAML identity administration activity for unauthorized changes. Restrict administrative access to trusted personnel only and prioritize accelerated upgrade to a fixed version, as no complete vendor-provided workaround is available in the supplied information.
Patch, then assume compromise.
Upgrade GitLab EE to a fixed release. Patched versions are 18.10.8, 18.11.5, and 19.0.2 or later in the respective release lines. GitLab advised self-managed customers running affected versions to upgrade immediately. The patch release includes database migrations, so single-node deployments should plan for possible downtime, while multi-node deployments should follow GitLab's zero-downtime upgrade procedures where applicable.
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.
10 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.