GitLab EE CVE-2026-9268

Exploitation requires an authenticated GitLab EE account with at least limited project permissions; it is not available to anonymous/unauthenticated attackers. The description qualifies the flaw as occurring only 'under certain conditions,' indicating it is not reliably triggerable in every deployment and likely depends on a specific project CI/CD rollback configuration state. The impact is bounded to unauthorized modification of CI/CD deployment rollback settings (integrity only) - no confidentiality or availability consequences - which meaningfully limits realistic risk despite the network attack vector. Affected deployments are GitLab EE versions 13.6 up to the fixed releases 19.2.8, 19.3.5, and 19.4.2.

This is a low-severity authorization flaw (CVSS 2.7, CWE-863 Incorrect Authorization) in GitLab EE. The provided CVSS vector (AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N) indicates a network-reachable, low-complexity issue with no confidentiality or availability impact and only limited integrity impact, requiring an authenticated attacker. Publicly available exploit code exists (HackerOne report #3687442), but there is NO CISA KEV listing and no EPSS score was provided, so there is no evidence of active exploitation - POC availability and active exploitation are distinct signals and should not be conflated. Notably, the vendor's vector sets PR:H (high privileges) while the description states 'an authenticated user with limited permissions,' which points to PR:L - this discrepancy slightly raises the realistic risk but does not change the overall low priority. Net assessment: a genuine but low-priority defect; the impact is confined to unauthorized modification of CI/CD deployment rollback settings, not code execution or data disclosure. Prioritize patching during normal maintenance cycles rather than as an emergency, giving weight to the fact that working exploit code is public for a product with a large enterprise footprint.

A low-privileged but authenticated GitLab user (e.g. a project member without maintainer rights) sends a crafted API or UI request to alter a project's CI/CD deployment rollback configuration that they should not be permitted to change. Because access-control checks are insufficient under certain conditions, the change is accepted, tampering with deployment safety controls. Public exploit code for this flaw is available on HackerOne (report #3687442), lowering the effort to reproduce it.