CVE-2026-0934: GitLab EE Protected Environment Access Control Bypass

Technical summary

CVE-2026-0934 stems from improper access control (CWE-863) in GitLab EE's protected environment configuration handling. The vulnerability allows authenticated users with custom role permissions to circumvent CI/CD visibility restrictions that are configured at the project level. When CI/CD visibility is disabled for a project, the protected environment API should enforce that restriction across all roles; however, the flaw permits certain authenticated principals to read, create, and modify protected environment data regardless of the visibility setting. The issue affects EE versions 17.9 through 18.11.5, 19.0.0 through 19.0.2, and 19.1.0.

Business impact

The primary risk is unauthorized disclosure and modification of protected environment configurations, which often contain deployment credentials, approval requirements, and production access policies. A user with limited or custom role permissions could gain visibility into deployment infrastructure, potentially exfiltrate secrets or policies, or alter deployment gates. In organizations where GitLab administrators have delegated project management to teams with custom roles, this vulnerability could enable privilege escalation or operational sabotage. The low CVSS score reflects the requirement for prior authentication and high privilege level; however, insider threat scenarios or compromised lower-privileged accounts could amplify the impact.

Affected systems

GitLab Enterprise Edition versions 17.9 through 18.11.5, 19.0.0 through 19.0.2, and 19.1.0 are affected. GitLab Community Edition and self-managed instances without Enterprise Edition licensing are not in scope. Cloud-hosted GitLab.com instances and on-premises EE deployments across these version ranges require immediate assessment and patching.

Exploitability

Exploitation requires an attacker to already be authenticated to the GitLab instance and possess a custom role with some level of project access. The attack is deterministic—no special conditions or user interaction needed—but the barrier to entry (valid authentication plus role assignment) limits the attack surface to internal or invited users. The CVSS vector (AV:N/AC:L/PR:H) indicates network accessibility with high privilege requirement; in this context, 'high privilege' means possession of a custom role with project visibility, not necessarily administrator status. The flaw is not known to be exploited in the wild (not listed on CISA KEV), but the simplicity of the attack once access is gained makes it a moderate insider threat.

Remediation

Upgrade to the patched versions as soon as feasible: GitLab EE 18.11.6 or later, 19.0.3 or later, or 19.1.1 or later. Organizations on earlier versions should prioritize patching, particularly if custom roles are in use for project delegation. During the patching window, review audit logs for any unauthorized access to protected environment configurations and validate that CI/CD visibility settings are correctly enforced in your deployment.

Patch guidance

Apply the vendor-supplied patches for GitLab EE through your standard update mechanism. For cloud-hosted GitLab.com, patching is automatic. For self-managed instances, verify that your current version falls within the affected ranges (17.9–18.11.5, 19.0.0–19.0.2, or 19.1.0), then schedule updates outside maintenance windows if possible. Test the patches in a non-production environment first, particularly if custom roles are heavily used. After patching, confirm that CI/CD visibility controls are re-enforced by attempting to access protected environment data with a low-privilege custom role.

Detection guidance

Review GitLab audit logs for API calls to protected environment endpoints by users with custom roles when CI/CD visibility is disabled. Look for patterns of repeated GET, POST, or DELETE requests to `/api/v4/projects/:id/protected_environments` by accounts with limited roles. Monitor for changes to protected environment configurations by users whose role should not permit such changes. If you have centralized logging, correlate GitLab authentication events with protected environment modifications to identify anomalous activity.

Why prioritize this

While the CVSS score is low (3.8) and the vulnerability is not yet a KEV entry, it affects a widely deployed enterprise product and directly targets operational security controls (protected environments and CI/CD policies). The combination of authenticated access with role-based bypass makes it particularly relevant for organizations using custom roles for access delegation. This is a 'medium priority' remediation: not emergency-level, but should be scheduled within the next quarterly patch cycle, especially for teams that rely on custom roles or have sensitive CI/CD infrastructure.

Risk score, explained

The CVSS 3.1 score of 3.8 (LOW) reflects the mandatory authentication requirement and high privilege level needed to trigger the vulnerability. However, this scoring does not account for the business sensitivity of protected environment data, which often contains deployment credentials and approval policies. Organizations should consider raising internal priority if custom roles are delegated to multiple team members or if protected environments contain high-value production infrastructure.

Frequently asked questions