CVE-2026-86341: 
GitLab Schwachstellenanalyse und -minderung

CVE-2026-86341 is an improper access control vulnerability in GitLab EE that allows authenticated users with Owner or Maintainer permissions to silently disable protected environment deployment approval requirements, enabling unapproved deployments to reach production. It affects all GitLab EE versions from 17.1 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. The vulnerability was published on September 16, 2026, and has been patched by GitLab. It carries a CVSS v3.1 base score of 4.4 (Medium) (GitHub Advisory).

The root cause is classified as CWE-1280 (Access Control Check Implemented After Asset is Accessed), meaning the access control validation occurs after the protected resource has already been modified rather than before. Under certain conditions, an authenticated user with elevated project-level permissions (Owner or Maintainer) can manipulate protected environment settings in a way that bypasses deployment approval enforcement. The flaw is mapped to CAPEC-180 (Exploiting Incorrectly Configured Access Control Security Levels), indicating the attacker leverages misconfigured or improperly sequenced access controls. No public proof-of-concept exploit code has been identified (GitHub Advisory, Feedly).

Successful exploitation allows an authenticated Owner or Maintainer to disable deployment approval gates for protected environments without detection, permitting unapproved code to be deployed directly to production systems. This primarily affects integrity — there is no confidentiality or availability impact. In environments where deployment approvals serve as a critical change-control or compliance mechanism, this bypass could result in unauthorized or malicious code reaching production, potentially enabling supply chain compromise or regulatory violations (GitHub Advisory).

There is no evidence of active in-the-wild exploitation, no public proof-of-concept code, and the vulnerability has not been added to the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.318%, indicating a low near-term exploitation probability. Exploitation requires authenticated access with high privileges (Owner or Maintainer role), which significantly limits the attacker pool. The NVD SSVC assessment also confirms no known exploitation at this time (GitHub Advisory).

1. Gain Privileged Access: Obtain or compromise an account with Owner or Maintainer permissions on a GitLab EE project running an affected version (17.1 through 19.1.7, 19.2.0–19.2.5, or 19.3.0–19.3.1).
2. Identify Protected Environment: Locate a project environment configured with deployment approval requirements (e.g., a production environment requiring one or more approvals before deployment).
3. Trigger the Vulnerable Code Path: Under the specific conditions that trigger the flaw, modify the protected environment configuration in a way that causes the access control check to execute after the resource has already been updated — effectively bypassing the approval requirement enforcement.
4. Silently Disable Approvals: The approval requirement is removed without generating expected audit alerts or visible changes to other users, leaving the environment unprotected.
5. Deploy Unapproved Code: Initiate a deployment pipeline to the now-unprotected environment; the deployment proceeds to production without requiring the previously mandated approvals (GitHub Advisory).

• Logs: GitLab audit logs showing changes to protected environment deployment approval settings by Owner or Maintainer accounts, particularly where approval requirements were reduced to zero or removed without a corresponding change management record.
• Logs: Pipeline deployment events to protected environments (e.g., production) that lack associated approval records or approval bypass justifications.
• Application Events: Deployments reaching protected environments during periods when approval requirements appear to have been temporarily disabled and then re-enabled.
• Configuration: Protected environment settings showing required_approval_count set to 0 or approval rules removed unexpectedly when reviewed via the GitLab API (GET /projects/:id/protected_environments/:name) (GitHub Advisory).

GitLab has released patched versions: 19.1.8, 19.2.6, and 19.3.2. All GitLab EE instances running versions from 17.1 through 19.3.1 should be upgraded immediately. As a post-patch remediation step, administrators should review audit logs for unauthorized changes to protected environment deployment approval settings and restore any approval requirements that may have been silently disabled. No configuration-based workaround is documented; upgrading is the recommended and only confirmed fix (GitHub Advisory, GitLab Patch Release).

Coverage of this vulnerability appeared in security news outlets including GBHackers, which reported on critical GitLab flaws alongside this CVE. The vulnerability was also noted on Mastodon/infosec.exchange by community members. General community sentiment reflects moderate concern given the privileged access requirement, though the lack of a public PoC and low EPSS score have tempered urgency. No notable vendor statements beyond the GitLab patch release advisory have been identified (GBHackers, GitLab Patch Release).