GitLab CE/EE Authorization and Information Disclosure Flaws

Information disclosure in GitLab Enterprise Edition 19.1 (before 19.1.1) lets a user retrieve sensitive data previously committed to a project because Duo Workflows fails to adequately filter its output under certain conditions. The flaw exposes confidential repository content through GitLab's AI workflow feature without altering or destroying data. No public exploit is identified at time of analysis and CISA SSVC rates exploitation as 'none', though EPSS sits at a modest 0.33% (25th percentile).

Cross-site scripting in GitLab CE/EE (18.10 through 18.11.5, 19.0 through 19.0.2, and 19.1.0) lets an unauthenticated attacker run arbitrary JavaScript in a victim's authenticated browser session by abusing improper path validation, but only under specific conditions and after a logged-in user interacts with attacker-controlled content. The CVSS 8.0 rating (scope-changed, high confidentiality and integrity impact) reflects that successful exploitation effectively hijacks the victim's GitLab session. No public exploit has been identified at time of analysis and the issue is not in CISA KEV, though a HackerOne report exists and GitLab shipped fixes in 18.11.6, 19.0.3, and 19.1.1.

Authorization bypass in GitLab Enterprise Edition's virtual registry cleanup policy feature allows authenticated users to read or modify cleanup policy settings belonging to groups they do not own. Affected versions span all GitLab EE releases from 18.6 through 18.11.5, 19.0 through 19.0.2, and 19.1.0. Exploitation requires a valid GitLab EE account but no elevated privileges; no public exploit code exists and this is not in CISA KEV at time of analysis.

Stored cross-site scripting in GitLab Enterprise Edition (all versions from 16.4 before 18.11.6, 19.0 before 19.0.3, and 19.1 before 19.1.1) lets an authenticated user holding only developer-role permissions inject unsanitized input that executes as JavaScript in a victim's browser session. Because the script runs with scope change in the context of another (potentially higher-privileged) user, an attacker can hijack sessions, exfiltrate data, or act on the victim's behalf. The flaw was reported privately via HackerOne and patched by GitLab; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.

Incorrect authorization in GitLab Enterprise Edition's DAST site profile management exposes stored secrets to users with the Developer role under certain conditions. Affecting all GitLab EE releases from 13.11 through the recently patched 18.11.6, 19.0.3, and 19.1.1, the flaw allows a lower-privileged authenticated user to read secrets - such as authentication credentials or API tokens - embedded in DAST site profiles they should not have access to. No public exploit code or CISA KEV listing has been identified at time of analysis, and the high attack complexity (AC:H) implies specific conditions must align for exploitation to succeed.

Confidential issue references in GitLab CE/EE public projects are exposed to unauthenticated users due to missing authorization checks (CWE-862). Affecting all GitLab versions from 17.5 through 18.11.5, 19.0.0-19.0.2, and 19.1.0, this flaw enables any unauthenticated remote attacker to retrieve references to confidential issues on public projects - potentially revealing issue IDs, titles, or internal metadata that project owners explicitly restricted. No public exploit code or CISA KEV listing exists at time of analysis; however, the unauthenticated, low-complexity network vector makes this trivially automatable for reconnaissance against large GitLab installations.

Sensitive data exposure in GitLab CE/EE affects all instances running versions from 9.3 through 18.11.5, 19.0 through 19.0.2, and 19.1.0, where under certain conditions a CI/CD API endpoint fails to adequately filter sensitive information before writing it to application logs. A high-privileged local actor who can access application log files on the GitLab server may recover sensitive data that should never have been persisted. No public exploit code exists and this vulnerability is not listed in CISA KEV, indicating no confirmed active exploitation at time of analysis.

Content injection in GitLab CE/EE via improper Snippet input validation permits authenticated low-privilege users to conceal arbitrary content within Snippets, affecting all versions from 14.8 through 19.1.0. Despite being tagged as Code Injection (CWE-94) with RCE in vendor-supplied tags, the published CVSS score of 4.3 with only low integrity impact (I:L) indicates the vendor-confirmed impact is scoped to content concealment rather than full remote code execution. Patches are available in versions 18.11.6, 19.0.3, and 19.1.1; no public exploit and no CISA KEV listing have been identified at time of analysis.

Incorrect authorization in GitLab CE/EE's group packages feature exposes package metadata from projects where the Package Registry has been explicitly disabled, allowing any authenticated Reporter-level group member to enumerate package names, versions, and publish timestamps that project owners intended to restrict. The flaw spans a very wide version range - all 13.6+ releases up to the newly-issued fixes in 18.11.6, 19.0.3, and 19.1.1 - meaning a large proportion of self-hosted GitLab deployments are affected. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.

Incorrect authorization in GitLab CE/EE allows authenticated users holding developer-role permissions to bypass Maven package protection rules and overwrite protected package metadata. All GitLab versions from 17.11 through 18.11.5, 19.0.0 through 19.0.2, and 19.1.0 are affected, with patched releases available across all three trains. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV; real-world impact is scoped to organizations that have explicitly configured Maven package protection rules and host untrusted developer-role users.

Protected environment configuration bypass in GitLab Enterprise Edition exposes CI/CD deployment gates to authenticated users holding custom role permissions, even when CI/CD visibility is explicitly disabled for the project. Affecting all EE versions from 17.9 before 18.11.6, 19.0 before 19.0.3, and 19.1 before 19.1.1, this CWE-863 (Incorrect Authorization) flaw allows such users to view, create, or delete protected environment rules that should be inaccessible. No public exploit identified at time of analysis, and the flaw is not listed in CISA KEV.

Insufficient authorization checks in GitLab Enterprise Edition expose project information to authenticated users with limited permissions under specific, undisclosed conditions. Affecting all EE releases from 18.6 up to (but not including) 18.11.6, 19.0.3, and 19.1.1, this CWE-862 flaw allows a low-privileged authenticated attacker to read project data they should not have access to. No public exploit code exists and no active exploitation has been confirmed; the high attack complexity (AC:H) and requirement for an authenticated session substantially limit real-world risk.

Server-side request forgery (SSRF) in GitLab CE/EE allows an authenticated user with maintainer-role permissions to probe and interact with internal network resources by configuring malicious mirror synchronization URLs that bypass GitLab's URL validation controls. The flaw spans an exceptionally wide version range - from 8.3 all the way through the 19.x train - making the population of unpatched instances large. CWE-350 (Reliance on Reverse DNS Resolution) indicates the bypass likely exploits DNS-based validation circumvention rather than a simple allowlist gap. No public exploit or active KEV listing is confirmed at time of analysis, but the maintainer privilege bar is low enough in shared multi-tenant GitLab deployments to materially broaden the attacker population.