CVE-2026-5309: GitLab EE Authorization Bypass in Virtual Registry Cleanup Policies

Technical summary

CVE-2026-5309 is an authorization control weakness (CWE-639) in GitLab EE's virtual registry cleanup policy management. The vulnerability allows authenticated users to perform unauthorized read and write operations on group-scoped cleanup policies through API or web interface calls. Affected versions span 18.6–18.11.5, 19.0–19.0.2, and 19.1–19.1.0. The issue stems from insufficient permission validation when accessing or modifying policy objects, enabling lateral privilege escalation within the same GitLab instance.

Business impact

Attackers with valid GitLab accounts can alter container registry cleanup schedules for other groups, potentially causing unintended image retention or deletion that disrupts CI/CD pipelines and image availability. In multi-tenant or shared GitLab environments, this enables data tampering and could facilitate resource exhaustion if malicious policies are applied to high-volume registries. Integrity and confidentiality of registry governance are directly threatened.

Affected systems

GitLab Enterprise Edition (EE) only. Affected version ranges are 18.6 through 18.11.5, 19.0.0 through 19.0.2, and 19.1.0. Community Edition and self-managed instances running these versions are in scope. SaaS customers running GitLab.com are patched by the vendor automatically.

Exploitability

Exploitability is moderate. The attack requires valid authentication credentials but no special role, making it accessible to any GitLab user. The conditions triggering the vulnerability are not exotic or rare—normal API or web UI operations can trigger the flaw. No CVSS exploit availability data is tracked; the vulnerability is not listed on CISA's Known Exploited Vulnerabilities catalog, suggesting active exploitation in the wild is not yet confirmed at publication.

Remediation

Upgrade to GitLab EE 18.11.6, 19.0.3, or 19.1.1 or later. No workarounds are documented. Community Edition users are not affected and require no action. Verify patch deployment before considering remediation complete.

Patch guidance

For GitLab EE deployments, prioritize upgrading to the nearest available patched version corresponding to your current track: version 18.11.6+ for the 18.x line, 19.0.3+ for 19.0, or 19.1.1+ for 19.1. Test patches in a staging environment before production rollout to ensure compatibility with custom registry configurations and downstream automation. Consult your GitLab deployment model (self-managed, Docker, Kubernetes, etc.) for version-specific upgrade procedures in the official GitLab release notes.

Detection guidance

Monitor API audit logs for unauthorized access patterns to `/api/v4/groups/{group_id}/registry_policies` or similar endpoints by non-group members. Review web UI access logs for users modifying cleanup policies outside their assigned groups. Baseline normal policy modification patterns, then flag anomalies. If available, enable GitLab's audit event logging and search for policy-related changes initiated by accounts with no documented relationship to the affected groups.

Why prioritize this

This is a MEDIUM-severity issue (CVSS 5.4) requiring authentication but enabling horizontal privilege escalation within a shared instance. It directly compromises data integrity of critical container registry operations. Organizations with multi-tenant GitLab or shared developer environments should treat this as higher priority due to trust boundary violations. Isolated single-group instances face lower risk. Update timelines should align with patch availability and your change management cycles, targeting completion within 30 days.

Risk score, explained

The CVSS 5.4 score reflects a low attack complexity and low privileges required (authenticated access), balanced against limited confidentiality and integrity impact confined to group-level registry policy data. Availability is not affected. The network-accessible, unauthenticated-free nature of the vulnerability (once credentials are obtained) and the ease of triggering it elevate the score beyond minimal thresholds. Organizational context—the number of users with GitLab access, sensitivity of registry governance, and multi-tenancy patterns—should inform your local risk assessment.

Frequently asked questions