GitLab CE/EE Authorization and Access Control Flaws

Remote code execution in GitLab CE/EE (all versions from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2) allows an unauthenticated attacker to execute arbitrary code on the GitLab server by supplying a specially crafted regular expression in a CI/CD configuration that passes insufficient regex validation; the defect is tracked as CWE-190 (integer overflow) and the vendor scores it 10.0 with scope change (S:C). Publicly available exploit code exists, referenced through HackerOne reports cited in the CVE record, but there is no CISA KEV entry and no confirmed active exploitation at time of analysis. Our independent assessment retains the same impact (C:H/I:H/A:H) but raises attack complexity to AC:H, because the vendor states the regex-validation path is reached by an unauthenticated user only 'under certain conditions' that are not detailed publicly and should be confirmed with GitLab; patched instances (19.4.2, 19.3.5, 19.2.8 or later) are not affected.

Stored cross-site scripting in GitLab CE/EE (affected ranges 19.1 through 19.2.7, 19.3 through 19.3.4, and 19.4 through 19.4.1) lets an authenticated user with repository write access embed a crafted file whose syntax-highlighted output is rendered with unsanitized HTML attributes, executing arbitrary JavaScript in the browser session of any other user who views it. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N reflects that the attacker must be authenticated (PR:L) and that a second user must render the malicious content (UI:R), but that successful execution crosses a trust boundary (S:C) with high confidentiality and integrity impact, including potential theft of session tokens or actions taken as the victim. Exploitation requires publicly available exploit code exists, with a HackerOne report and the upstream work item publicly linked; CISA KEV status was not indicated in the supplied intelligence, so this should be treated as a high-priority authenticated stored XSS rather than a confirmed actively exploited campaign. The affected surface is bounded by the requirement for repository control plus a victim viewing the highlighted file, so unauthenticated or pure drive-by exploitation is not possible.

An authenticated user holding only the Developer role can run CI/CD pipelines on protected branches in GitLab CE/EE without authorization, because the downstream (multi-project/child) pipeline creation service failed to enforce proper permission checks (CWE-863). All versions from 18.7 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 are affected, and exploitation is conditional: it requires a valid Developer account plus projects that combine downstream pipelines with protected-branch restrictions, which is why the independent assessment raises attack complexity to High even though the vendor rates the issue 8.5 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N). Publicly available exploit code exists in the form of a HackerOne report, but the provided data contains no confirmation of active exploitation and no KEV listing. Integrity impact is the dominant risk: unauthorized pipeline execution on a protected branch can inject or alter build, test, and deployment artifacts that the branch protection model was designed to shield.

Cache poisoning of raw repository file responses in GitLab CE/EE (all versions before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2) lets a low-privileged authenticated user supply crafted repository references so that cached raw-file content is served to other users. When a targeted victim's CI/CD pipeline subsequently fetches that poisoned raw file, the pipeline executes attacker-controlled content, potentially exposing protected environment variables. Publicly available exploit code exists (referenced via a HackerOne report), but the issue is not confirmed as actively exploited (no CISA KEV listing); exploitation is rated high complexity (AC:H), requires authentication (PR:L), and success depends on a victim pipeline actually pulling and running the poisoned content, making this a credible, high-priority issue rather than an emergency.

Improper cleanup of scheduled pipeline execution policy records in GitLab Enterprise Edition lets an authenticated user execute arbitrary CI/CD pipelines in a transferred project using the destination group's privileges. Affected releases are all EE versions from 18.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2. Exploitation is conditional - the attacker needs a valid account, a project that has a configured scheduled pipeline execution policy, the project-transfer workflow, and user interaction (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N, 7.7) - but publicly available exploit code exists per the referenced HackerOne report, and no CISA KEV entry has been recorded, so this is a moderate, conditional privilege-escalation risk rather than a mass-exploitation emergency.

Authenticated users of GitLab Enterprise Edition can inject specially crafted content into the context that AI agent features assemble, allowing unintended commands to be executed and attributed to other users. The issue affects GitLab EE from 19.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2, and exploitation requires a valid EE account (PR:L), the AI agent/conversation feature to be enabled and in use, and a separate victim user to trigger the affected AI interaction (UI:R), so realistic exposure is substantially narrowed despite the network attack vector. No public exploit code or confirmed active exploitation was identified at time of analysis; vendor-released patches are available in versions 19.2.8, 19.3.5, and 19.4.2.

Information disclosure in GitLab Pages (GitLab CE/EE) lets an authenticated user who already holds access to Pages log data recover access tokens and other secrets, because sensitive request data was written into log files and forwarded to error-tracking events. All GitLab CE/EE versions from 12.0 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 are affected, per CWE-532 (insertion of sensitive information into a log file). The assessed CVSS is 6.2 and the privilege requirement is high (PR:H) - the attacker must be an authenticated user who can already read the affected Pages logs, so this is not remotely reachable by anonymous users against a default configuration; no public exploit code or active exploitation has been identified at time of analysis. Impact is limited to disclosure of whatever tokens or secrets happened to be captured in logging or error tracking, but because the leaked credentials can span security boundaries the change scope is rated S:C.

Authentication token leakage in GitLab CE/EE (all versions from 13.11 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2) allows an authenticated user who controls a Kubernetes agent to redirect the Kubernetes proxy to an unintended server, exposing sensitive authentication tokens. Exploitation requires user interaction and only affects instances using the GitLab Kubernetes agent/proxy integration; publicly available exploit code exists. This moderate-severity issue (CVSS 5.8) is not a top-tier emergency but should be patched by affected deployments.

Unauthenticated information disclosure in GitLab CE/EE allows remote attackers to read confidential notes on public projects because of incorrect authorization checks, affecting versions from 17.4 up to specific branch fix releases. The flaw carries a CVSS 3.1 base score of 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), so exploitation needs no credentials or user interaction and is confined to confidentiality. Publicly available exploit code exists via a HackerOne report, but there is no confirmed active exploitation (CISA KEV not listed); GitLab states the issue is only exploitable under certain conditions, so not every public project is necessarily affected.

An incorrect authorization check in GitLab CE/EE allows an unauthenticated remote user to read work item contents from private groups and projects, exposing information that should be restricted to authorized members. All versions from 17.11 before 19.2.8, every 19.3 release, and 19.4 before 19.4.2 are affected, with vendor-released fixes available in 19.2.8 and 19.4.2. The issue carries a moderate CVSS of 5.3 (confidentiality-only impact) and publicly available exploit code exists via a HackerOne report, though exploitation is gated by unspecified 'certain conditions' and there is no confirmed active exploitation (CISA KEV).

Unauthenticated attackers can read internal notes and confidential system notes on public GitLab CE/EE projects through the GraphQL API, which fails to enforce proper authorization checks on affected versions (19.2 through 19.2.7, 19.3 through 19.3.4, and 19.4 through 19.4.1). The flaw carries a CVSS 3.1 score of 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), reflecting a confidentiality-only impact with no integrity or availability effect. Publicly available exploit code exists, with a HackerOne report and a GitLab work item referenced, so unpatched, internet-exposed instances hosting public projects with internal or confidential notes are the highest-priority targets for remediation.

Cache poisoning in GitLab CE/EE allows an authenticated user, on deployments running a specific caching configuration, to corrupt cached page content that is subsequently served to other users because cache keys are constructed improperly. Affected versions are all releases from 16.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 on both Community and Enterprise editions; exploitation requires a valid account (PR:L), a non-default deployment/caching setup, high attack complexity (AC:H), and victim interaction (UI:R), yielding only limited confidentiality, integrity, and availability impact (CVSS 4.6). No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV), so this is best treated as a low-priority, targeted-scenario issue rather than a broadly exploitable one.

Authenticated users of GitLab Enterprise Edition who hold a specific granular permission can obtain a GitLab Duo Agent Platform token that bypasses configured governance controls, due to the application relying on untrusted input when making a security decision. Only GitLab EE installations running the Duo Agent Platform with governance controls in place are affected, specifically versions from 19.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2; GitLab Community Edition is not affected, and unauthenticated or arbitrary low-privilege accounts cannot exploit the issue. GitLab has released fixes in 19.2.8, 19.3.5, and 19.4.2, and no public exploit code was identified at time of analysis - this is a medium-severity, lower-priority issue rather than an urgent threat.

Improper privilege assignment in GitLab Enterprise Edition lets an authenticated user who holds a custom role carrying compliance framework administration permissions configure and execute a specially crafted compliance pipeline across the projects of a group, effectively running pipeline content in projects beyond the scope their role was meant to grant. Affected deployments are GitLab EE from 17.0 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2; the practical impact is limited to integrity (CVSS 4.3, C:N/I:L/A:N) and depends on a non-default configuration in which a custom role and compliance framework administration have been deliberately assigned and the group uses compliance pipelines. No public exploit code or confirmed active exploitation was identified at time of analysis, and this is a low-to-moderate priority issue rather than a high-urgency one.

Authenticated users with limited project permissions in GitLab Enterprise Edition (EE) can alter CI/CD deployment rollback settings without proper authorization due to insufficient access control checks (CWE-863). This low-severity integrity flaw (CVSS 2.7) affects GitLab EE versions from 13.6 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2; publicly available exploit code exists, though active exploitation is not confirmed. The impact is limited to unauthorized modification of rollback settings, with no confidentiality or availability consequences, and exploitation requires an authenticated account and specific conditions.

Authenticated GitLab CE/EE users with only Guest-level access can read confidential epic content that is supposed to be restricted by external authorization, because the instance performs an incorrect authorization check on that content. All versions from 17.0 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 are affected, and the exposure is limited to read-only disclosure in deployments that actually protect confidential epics through external authorization. Publicly available exploit code exists, including a referenced HackerOne report, but there is no confirmed active exploitation (not in CISA KEV); GitLab itself reported and has since remediated the issue, and CVSS 3.1 scores it 4.3, reflecting the low, confidentiality-only impact.

A missing authorization check in GitLab CE/EE (Community and Enterprise Edition) lets an authenticated user holding only the Reporter role on a project read restricted CI artifact report content they should not be able to access, resulting in a confidentiality-only exposure (CVSS 3.1 base 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N). Every release from 13.8 up to - but not including - 19.2.8, 19.3.5, and 19.4.2 is affected, so the exposure window spans several years of deployments. Publicly available exploit code exists (a HackerOne report is referenced), but there is no confirmed active exploitation (CISA KEV) and the issue is rated low-to-moderate priority; exploitation still requires a valid authenticated account with Reporter access and a target project that actually stores restricted CI artifact reports. Patched versions 19.2.8, 19.3.5, and 19.4.2 are available from GitLab.

Incorrect authorization logic in GitLab CE/EE allows an authenticated user holding a project-scoped fine-grained Personal Access Token to permanently delete or modify group-level labels that the token should not be able to reach, affecting versions 18.11 through before 19.2.8, 19.3 through before 19.3.5, and 19.4 through before 19.4.2. The flaw is rated CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), meaning exploitation requires a low-privileged authenticated account and token, is confined to integrity impact on group labels, and does not expose data or cause a denial of service; GitLab states exploitation is further gated by unspecified 'certain conditions' around label ownership. Publicly available exploit code exists and the issue was reported through HackerOne, but the impact is limited to label tampering rather than broader project or repository compromise, making this a low-to-moderate priority authorization issue for affected self-managed and GitLab.com-style deployments.

Broken authorization in GitLab CE/EE lets an authenticated user who holds a project-scoped fine-grained Personal Access Token modify integrations belonging to a group outside that token's scope, affecting versions 19.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2. The issue carries a low CVSS 3.1 score of 4.2 (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N) and a CWE-863 root cause, requiring a valid token plus a high-complexity, not fully enumerated trigger, which limits the outcome to unauthorized integration changes rather than account or instance compromise. Publicly available exploit code exists (HackerOne report referenced as exploit material) and vendor-released patches are available; the vulnerability is not listed in CISA KEV, so it should be treated as a low real-world priority rather than an urgent one.

Improper authorization checks in GitLab CE/EE (CWE-863) allow an authenticated user to download package files belonging to a public project through the package registry when they should not have access, effectively bypassing project visibility and package-level access controls. The issue affects all versions from 15.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2; the CVSS vector (AV:N/AC:H/PR:L/UI:N) requires a valid account and depends on 'certain conditions' that are not fully enumerated, so exploitation is not reliable against arbitrary configurations. Publicly available exploit code exists - details were reported via HackerOne - but the CVE is not listed in CISA KEV, and the assessed impact is limited to unauthorized disclosure of package files, with no code execution, data modification, or availability impact, making this a low-to-moderate priority issue rather than an emergency.

Authenticated users of GitLab Enterprise Edition can approve a merge request even when they themselves contributed commits to it, defeating the separation-of-duties control that approval rules are meant to enforce. The flaw stems from improper identity resolution and affects all EE versions from 16.11 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2, and it requires a valid authenticated account that has already pushed commits to the target merge request, with high attack complexity because the identity-resolution edge case is not trivially triggered. Impact is confined to review governance (integrity of the approval workflow) with no confidentiality or availability impact; this is a low-severity issue (vendor CVSS 3.1 base 4.2, CWE-863), and no public exploit identified at time of analysis.

Server-side request forgery in GitLab CE/EE (all versions from 10.3 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2) allows an authenticated user with repository import rights to reach internal network resources by winning a time-of-check to time-of-use race condition in the URL validation performed during import operations. The base score is low (CVSS 3.1 3.5, AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N): the attacker must repeatedly race the validation and fetch windows, so the flaw does not trigger reliably and yields only limited confidentiality impact with no integrity or availability effect. There is no public exploit identified at time of analysis and no confirmed active exploitation; the primary risk is limited internal-network reconnaissance or access to internal services from a GitLab instance that can route to them.

Incorrect authorization of the import target namespace in GitLab CE/EE lets an authenticated user wielding a fine-grained Personal Access Token that is scoped only to user-boundary import permissions push project imports into group namespaces that fall outside the token's intended scope (CWE-863). Only installations running versions from 18.9 up to 19.2.8, 19.3.x before 19.3.5, and 19.4.x before 19.4.2 are affected, and the issue is limited to integrity (I:L) with no confidentiality or availability impact per CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N - a low-severity finding (base score 3.1) that does not warrant emergency prioritization. Publicly available exploit code exists (a HackerOne report and the corresponding GitLab work item are referenced), there is no confirmed actively exploited (CISA KEV) status, and exploitation additionally requires a valid scoped token plus favorable conditions, so the practical exposure is narrow.

An authenticated user holding maintainer-role permissions on GitLab CE/EE can remove certain package registry metadata that package protection rules are supposed to reserve for higher-privileged roles, due to improper authorization checks in the package registry. The issue affects all versions from 17.6 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2, and manifests only on instances where package protection rules are actually configured; the assessed impact is integrity-only (CVSS 3.1 base score 2.7), with no confidentiality or availability loss, and there is no public exploit identified at time of analysis. Vendor-released patches are available in GitLab 19.2.8, 19.3.5, and 19.4.2.