Gitlab

GitLab API request redirection in zereight's mcp-gitlab (gitlab-mcp) MCP server lets attackers who control the job_id parameter escape the intended /jobs/ path prefix and reach arbitrary GitLab REST API endpoints under the operator's personal access token. Because the token is a bearer of the operator's full GitLab privileges, a crafted value such as '../../../user' resolves to /api/v4/user (or any other resource), turning a scoped job lookup into broad unauthorized data access. No public exploit was identified at time of analysis, and it is not listed in CISA KEV, but the flaw is trivially triggerable and was reported by VulnCheck with a vendor fix committed.

Work item metadata in GitLab EE is exposed to authenticated users holding only minimal project permissions due to missing authorization checks on affected API or web endpoints, enabling unauthorized reads of private project data. Affected deployments span GitLab EE 18.9 through pre-18.11.7, 19.0 through pre-19.0.4, and 19.1 through pre-19.1.2, with patched releases now available from the vendor. No public exploit has been identified at time of analysis, the vulnerability is not listed in CISA KEV, and the CVSS 4.3 Medium score reflects narrow impact - confidentiality-only, metadata-scoped, with no integrity or availability consequence.

Private project existence disclosure in GitLab CE/EE (versions 9.1 through 18.11.x, 19.0.x, and 19.1.x) enables low-privilege GitLab account holders to confirm whether a private project exists via improperly authorized cross-project reference pages. The flaw stems from missing authorization controls (CWE-862) on reference resolution endpoints, leaking project existence metadata to users who have no authorized access to the targeted private project. No public exploit exists and this vulnerability is not listed in CISA KEV; GitLab has released patches across all three affected version branches.

Stored/reflected cross-site scripting in GitLab Enterprise Edition lets an authenticated user holding Developer-role permissions inject arbitrary scripts that execute in a victim user's browser session, enabling session hijacking or actions performed as the victim. It affects a broad version range (13.11 through 18.11.6, 19.0.x before 19.0.4, and 19.1.x before 19.1.2) and stems from improper sanitization of user-supplied input. There is no public exploit identified at time of analysis, though the flaw was disclosed through a HackerOne bug-bounty report.

Improper authorization on GitLab EE GraphQL operations permits authenticated users holding auditor-level access to write modifications to compliance violation records - an action that role should not permit. Affected versions span all GitLab EE releases from 18.2 through the patched thresholds (18.11.7, 19.0.4, 19.1.2). No public exploit code exists and CISA KEV does not list this vulnerability; with CVSS 2.7 and PR:H, real-world impact is narrow but meaningful for organizations relying on compliance audit trails for regulatory evidence.

Stored/reflected cross-site scripting in GitLab CE/EE (all versions from 15.7 before 18.11.7, 19.0 before 19.0.4, and 19.1 before 19.1.2) lets an authenticated user inject unsanitized input that executes arbitrary JavaScript in a victim's browser session, enabling session hijacking or actions on the victim's behalf. The scope-changed CVSS 7.3 reflects that the payload crosses a security boundary into another user's context. There is no public exploit identified at time of analysis, though the flaw originated from a HackerOne bug bounty submission and vendor patches are already available.

Improper authorization in GitLab Enterprise Edition allows an already-authenticated high-privilege user to modify group-level settings beyond the scope their role should permit. Affecting all EE versions from 16.10 through the patched releases of 18.11.7, 19.0.4, and 19.1.2, the flaw enables unauthorized integrity changes to group-wide policies without any user interaction. No public exploit or active exploitation has been identified at time of analysis, and the PR:H CVSS requirement substantially constrains real-world risk to a narrow set of already-privileged insiders.

Credential disclosure in GitLab Enterprise Edition allows an authenticated maintainer-role user to retrieve another user's stored credentials through insufficient authorization controls. All GitLab EE versions from 9.5 through the patched releases (18.11.7, 19.0.4, and 19.1.2) are affected, representing a broad historical exposure window spanning multiple major releases. No public exploit identified at time of analysis; the vulnerability was disclosed via HackerOne responsible disclosure (report 3720483), and GitLab has issued patched versions.

Content spoofing in GitLab CE/EE versions 16.5 through 18.x, 19.0, and 19.1 allows authenticated users to construct repositories where the web interface renders content that diverges from the actual downloadable source, exploiting improper Git reference name resolution (CWE-706). The CVSS score of 3.5 (Low) reflects the authentication requirement (PR:L), mandatory viewer interaction (UI:R), and limited integrity-only impact with no confidentiality or availability consequences. No public exploit code or CISA KEV listing has been identified at time of analysis, placing real-world risk firmly in the low tier despite the broad version range affected.

Credential leakage in electron-updater (the auto-update component of electron-builder / builder-util-runtime) before 9.7.0 allows an attacker controlling a redirect target to harvest update-feed credentials. The HTTP redirect handler only stripped a header keyed exactly as lowercase "authorization", so PRIVATE-TOKEN (GitLab personal access tokens) and mixed-case Authorization (GitLab Bearer/OAuth) headers were forwarded to attacker-controlled cross-origin redirect destinations. There is no public exploit identified at time of analysis, but the upstream fix is published in version 9.7.0.

Approval-gate bypass in Woodpecker CI before 3.15.0 lets an attacker who can open a merge request from a fork against a GitLab-backed repository run unapproved, attacker-controlled pipelines. Because the GitLab forge driver populates pipeline.Author from the spoofable git commit author name (commit.author.name) rather than the GitLab-validated user identity, an attacker simply sets the commit author to a name listed in ApprovalAllowedUsers, making needsApproval return false. This grants arbitrary CI step execution on a Woodpecker agent and exposure of CI secrets; there is no public exploit identified at time of analysis, but the issue was reported by VulnCheck and is trivially reproducible.

Coolify's GitLab webhook endpoint leaks its secret token through a timing side-channel, enabling unauthenticated network attackers to reconstruct the token incrementally by measuring HTTP response time differences. All self-hosted Coolify instances prior to 4.0.0-beta.461 with GitLab webhook integrations configured are affected. Once the secret is recovered, an attacker can forge arbitrary GitLab webhook events and potentially trigger unauthorized deployments. No public exploit or active exploitation has been identified at time of analysis; the CVSS-assigned AC:H correctly reflects the practical difficulty of conducting reliable timing measurements over real-world networks.

Denial of service in linkify-it (npm) through v5.0.0 lets remote unauthenticated attackers wedge a rendering worker by submitting tens of KB of repeated email/link-like text. The core public API LinkifyIt.prototype.match runs an O(N²) scan loop that re-slices the input and re-runs unanchored fuzzy regex searches once per match, so 64 KB of "a@b.com" burns ~2.5 s of single-threaded CPU and 128 KB ~10 s. The flaw is inherited by markdown-it (~21.6M weekly npm downloads) whenever linkify:true is set, exposing forums, chat, wikis and AI chat UIs; publicly available exploit code (a PoC in the GHSA advisory) exists, but there is no evidence of active exploitation.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

The /gitlab connect slash command in Mattermost fails to enforce administrator-level authorization on the setDefaultInstance call, enabling any authenticated user to overwrite the workspace-wide default GitLab instance configuration. Affected across four concurrent release trains (11.7.0, 11.6.x ≤ 11.6.2, 11.5.x ≤ 11.5.5, 10.11.x ≤ 10.11.17), this missing authorization flaw (CWE-862) is exploitable by any valid Mattermost account holder without elevated privileges. No public exploit code or active exploitation has been identified at time of analysis, but the low attack complexity and low privilege requirement make this accessible to any workspace member targeting GitLab integration infrastructure.

Incomplete SSRF remediation in mailpit v1.29.2 through v1.30.1 leaves the Link Check API bypassable via IPv6 transition mechanism literals (6to4, NAT64, IPv4-compatible IPv6, ISATAP, Teredo) and unclassified IPv6 prefixes (fec0::/10, 2001:db8::/32) that Go's stdlib Is* classification helpers silently pass. An unauthenticated network attacker who can deliver email to mailpit's SMTP listener and invoke the Link Check API can coerce the application into dialing internal IPv4 destinations - including cloud metadata endpoints at 169.254.169.254 - by encoding the target as an IPv6 literal that returns false for all seven predicates in IsInternalIP, bypassing the guard introduced for CVE-2026-27808. Publicly available exploit code exists in the form of a reproducible unit test and end-to-end proof-of-concept published in the advisory; this is the same deny-list bypass class confirmed in CVE-2026-44430 (MCP Registry) and CVE-2026-45741 (Gotenberg).

Stored XSS in allure-generator (versions <= 2.38.1) allows arbitrary JavaScript execution in the browser of anyone who views a generated Allure report containing crafted test result data. The vulnerable `ansi.js` Handlebars helper passes unsanitized `statusMessage` and `statusTrace` values - sourced from JUnit XML failure messages and equivalent fields in TRX, xUnit XML, xctest, and Allure 1/2 plugins - through `ansi-to-html` without HTML escaping, then wraps the output in `SafeString` to bypass Handlebars' auto-escape protection. A publicly available proof-of-concept demonstrates exploitation via a crafted JUnit XML file; the attack is particularly relevant to CI/CD environments (Jenkins, GitLab, GitHub Actions) where reports are served on shared infrastructure with active authenticated sessions.

Denial of service in libtiff v4.7.1 and prior allows processing of a crafted TIFF file containing an abnormally large SamplesPerPixel tag value to crash or hang the affected process. Any application or service that passes attacker-controlled TIFF files through libtiff is potentially vulnerable, including web-based image processors, document converters, and media ingestion pipelines. No active exploitation has been confirmed by CISA KEV, and no public exploit code has been identified at the time of this analysis.

Improper authorization in DevGuard versions prior to v1.4.2 allows any authenticated user on the instance - including users with no membership in the target organization, project, or asset - to perform write operations on vulnerability-triage endpoints of any public asset. The flaw lets attackers create, modify, or delete VEX rules, dependency-vulnerability events, license risks, external references, and artifacts, corrupting the integrity of published vex.json/sbom.json output consumed by downstream supply-chain users. No public exploit identified at time of analysis, and EPSS probability is very low (0.04%, 11th percentile), reflecting the niche audience but not the integrity blast radius.

Uncontrolled resource consumption in GitLab CE/EE's file upload processing pipeline enables any authenticated user to trigger denial of service by submitting a specially crafted file. All self-managed GitLab instances running versions from 17.10 up through the patched releases (18.10.8, 18.11.5, 19.0.2) are affected across both Community and Enterprise Editions. A publicly available exploit exists on HackerOne (report #3517331), though no active exploitation has been confirmed by CISA KEV.

Incorrect authorization checks in GitLab CE/EE expose confidential issue details to authenticated low-privileged users under specific conditions. The flaw spans an enormous version range starting from 12.0, meaning a large population of self-hosted GitLab instances running unpatched versions is potentially affected. A publicly available exploit was disclosed via HackerOne (report #3578216), which elevates practical risk above what the low CVSS score of 3.1 alone suggests, even though active exploitation has not been confirmed by CISA KEV.

Incorrect authorization enforcement in GitLab CE/EE exposes hidden merge requests to unauthorized modification by authenticated users holding developer-role permissions. The flaw spans a wide version range - from 15.10 through the patched releases 18.10.8, 18.11.5, and 19.0.2 - meaning a large proportion of self-managed GitLab deployments are potentially affected. A publicly available proof-of-concept exists via a disclosed HackerOne report, raising the practical exploitation risk beyond what the medium CVSS score alone suggests; no confirmed active exploitation (CISA KEV) has been recorded at time of analysis.

Incorrect authorization enforcement in GitLab Enterprise Edition allows an authenticated user holding the Security Manager role to manage project security configurations even when the relevant security feature has been administratively disabled. Affecting all EE versions from 13.9 through the patched releases (18.10.8, 18.11.5, 19.0.2), the flaw bypasses the feature-disabled gate by failing to validate feature state alongside role-based permissions. No public exploit is confirmed as actively exploited (not in CISA KEV), though a publicly available HackerOne exploit report exists, and EPSS data was not provided in available intelligence.

Account takeover in GitLab Enterprise Edition versions 15.5 through 19.0.2 allows an authenticated group Owner to hijack other group members' accounts through improper authorization in the Group SAML identity management functionality. Publicly available exploit code exists via a HackerOne report, and GitLab released patched versions 18.10.8, 18.11.5, and 19.0.2 on 2026-06-10. The flaw stems from CWE-639 (Authorization Bypass Through User-Controlled Key) and yields a scope-changing high-impact compromise per CVSS 3.1.

Merge request diff manipulation in GitLab CE/EE allows authenticated users with developer-role permissions to hide file changes from code reviewers by exploiting improper input handling of file names, undermining the integrity of the code review process. Publicly available exploit code exists via HackerOne report #3638136 (tagged 'exploit' in vendor references), though no confirmed active exploitation has been recorded in CISA KEV. The vulnerability spans a broad version range from 15.9 through the patched releases, meaning self-managed GitLab deployments without current patch levels are at risk from malicious insiders or compromised developer accounts bypassing review gates.

Denial of service in GitLab CE/EE versions 12.10 through 18.10.8, 18.11 before 18.11.5, and 19.0 before 19.0.2 allows unauthenticated remote attackers to crash or degrade the API request parsing middleware via malformed input. Publicly available exploit code exists (HackerOne report 3671995), and the CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/A:H) reflects trivially-reachable, no-auth exploitation against any internet-exposed GitLab instance. No CISA KEV listing at time of analysis.

Stored cross-site scripting and account integrity abuse in GitLab Enterprise Edition versions 13.1.4 through 18.10.7, 18.11 prior to 18.11.5, and 19.0 prior to 19.0.2 allows an authenticated low-privileged user to inject unsanitized input into certain group setting fields and add unauthorized email addresses to a targeted user's account. Publicly available exploit code exists via a HackerOne report, though EPSS exploitation probability remains very low at 0.02% and the SSVC framework rates current exploitation as 'none' with total technical impact when successful.

Server-Side Request Forgery (SSRF) in GitLab CE/EE's repository import feature allows an authenticated low-privileged user to read arbitrary files from the backend Gitaly server and probe internal network resources by supplying maliciously crafted secondary URLs that bypass input validation. Affected versions span the 18.10, 18.11, and 19.0 release lines, all patched by GitLab on 2026-06-10. No public exploit code and no CISA KEV listing have been identified at time of analysis, though the combination of authentication-only gating and network-accessible entry point makes this a meaningful lateral-movement risk in self-managed GitLab deployments.

Content injection via Service Desk email template processing in GitLab CE/EE allows an unauthenticated attacker to impersonate the GitLab Support Bot and inject arbitrary content into issue threads. The vulnerability affects all GitLab instances running versions from 15.9 through 19.0.1 with the Service Desk feature active, and stems from improper neutralization of substitution characters (CWE-153) in email template rendering. A publicly available exploit exists on HackerOne, though no active exploitation has been confirmed by CISA KEV; the official CVSS score of 2.6 reflects the high attack complexity and limited integrity-only impact.

Stored cross-site scripting in GitLab Enterprise Edition's Analytics Dashboard allows an authenticated developer-role user to execute arbitrary client-side JavaScript in the browser of a targeted user, leveraging improper input sanitization. The flaw affects all 17.1 through 18.10.x, 18.11.x, and 19.0.x branches before fixed releases, and publicly available exploit code exists via a HackerOne report, raising the realistic risk of opportunistic abuse against multi-tenant GitLab instances.

Denial of service on the GitLab CI/CD Catalog page is achievable by any authenticated user across a broad version range (17.0 through pre-patch releases of 18.10, 18.11, and 19.0) due to improper sanitization of user-supplied content. The low-privilege, network-accessible attack vector means any GitLab account holder can trigger the condition without elevated permissions or complex setup. No public exploit code or CISA KEV listing has been identified at time of analysis, and the limited availability impact (A:L) constrains real-world severity, though the wide version exposure across three concurrent release branches broadens organizational risk.

Credential exposure in Red Hat Quay 3's config-tool GitLab OAuth validator allows OAuth client_id and client_secret to leak into system logs. The config-tool incorrectly appends these sensitive values as URL query parameters on POST requests to the GitLab endpoint, causing them to appear in server access logs, reverse proxy logs, and monitoring infrastructure. A highly privileged attacker with read access to those log systems can harvest the exposed OAuth credentials and use them for unauthorized GitLab API access. No public exploit code exists and this is not listed in CISA KEV.

Incorrect authorization enforcement in GitLab CE/EE permits a blocked Project Access Token to continue reading private project resources despite administrative revocation. Affected are all GitLab CE/EE instances running versions 18.9 through 18.10.6, 18.11 through 18.11.3, and 19.0.0 - patched versions 18.10.7, 18.11.4, and 19.0.1 were released 2026-05-27. A publicly available exploit exists via HackerOne report #3554993, though no confirmed active exploitation (CISA KEV) has been identified at time of analysis.

Unauthorized CI data access in GitLab CE/EE allows an authenticated low-privileged user to read CI pipeline data from a ref type (branch, tag, or merge request ref) other than the one they are authorized to view, under certain unspecified conditions. All GitLab installations - both Community and Enterprise editions - running versions from 12.7 through the unpatched releases are affected. The vulnerability is classified as information disclosure with low confidentiality impact; no public exploit code has been identified at time of analysis and it is not listed in the CISA KEV catalog.

Unauthorized private project enumeration in GitLab CE/EE exposes confidential project metadata to unauthenticated network attackers due to incorrect authorization checks (CWE-863). All GitLab installations running versions from 18.2 through the patched releases are affected - both Community and Enterprise editions. While the direct impact is limited to information disclosure (project enumeration rather than content access), exposed project names and IDs can facilitate targeted follow-on attacks against otherwise hidden repositories. No public exploit code has been identified at time of analysis, and this CVE is not listed in the CISA KEV catalog.

Authorization bypass in GitLab Enterprise Edition allows authenticated users holding only developer-role permissions to circumvent flow restrictions when foundational flows are enabled at the group level. Affecting all EE versions from 18.7 through 19.0 (prior to the respective patch releases), this flaw stems from missing authorization checks (CWE-862) and results in a low-integrity-impact, network-accessible exploitation path. No active exploitation has been identified (SSVC: Exploitation none), and GitLab has released patches across all affected branches as of 2026-05-27.

Identity confusion in GitLab EE's Duo AI workflow runners lets an authenticated, low-privileged user cause specific Duo AI workflows to execute under another user's identity, crossing the trust boundary between accounts (CVSS scope: changed). The flaw stems from improper user identity resolution and affects GitLab Enterprise Edition 18.8 through 18.10.6, 18.11 through 18.11.3, and 19.0, with High confidentiality and integrity impact but no availability impact. No public exploit has been identified, CISA's SSVC marks exploitation as 'none,' and the High attack complexity (AC:H) combined with the 'under certain conditions' caveat indicates exploitation is non-trivial rather than push-button.

GitLab Enterprise Edition exposes sensitive deployment data to authenticated users holding only developer-role permissions due to missing authorization checks on deployment-related project resources (CWE-862). Affected versions span a wide range - all EE releases from 11.5 through 18.10.6, 18.11.0 through 18.11.3, and 19.0.0 - making this broadly applicable across unpatched GitLab EE deployments. No public exploit identified at time of analysis per CISA KEV, though SSVC intelligence indicates proof-of-concept code exists, and a HackerOne report (3556381) corroborates researcher discovery.

Denial of service in GitLab CE/EE affects all versions from 17.1 through those prior to 18.10.7, 18.11.4, and 19.0.1, allowing a low-privileged authenticated user to crash or degrade service availability through insufficient input validation. The root cause is CWE-770 (resource allocation without limits or throttling), meaning a specially crafted request can exhaust server-side resources under certain conditions. Publicly available exploit code exists per SSVC assessment, though CISA has not added this to the Known Exploited Vulnerabilities catalog and automated mass exploitation is considered unlikely.

VM escape in Kata Containers allows any Kubernetes user with pod-creation rights to break out of the VM sandbox and gain full read/write access to the host filesystem. All Kata Containers installations prior to commit ffa59ce3aa78 are affected when using the default configuration.toml, which enables the `virtio_fs_extra_args` and `kernel_params` pod annotations out of the box. An attacker crafts a pod with two annotations: one to redirect virtiofsd to serve the host root filesystem (`/`) into the guest VM, and a second to enable the agent debug console - after which the entire host filesystem is accessible from inside the supposedly isolated VM. A fully working proof-of-concept with confirmed output against Kata Containers 3.28.0 on Ubuntu 24.04 has been publicly disclosed; no public exploit confirmed as actively exploited (CISA KEV) at time of analysis.

Command injection in Prefect 3.6.18's GitHub integration allows authenticated users to execute arbitrary git commands through the unsanitized reference field. The GitHubRepository block concatenates user input directly into git clone commands, enabling attackers to inject malicious options that can lead to SSRF, credential theft, or remote code execution. While no active exploitation is confirmed, the straightforward attack vector and high impact make this a priority for organizations using Prefect's GitHub integration features.

Unauthenticated agent token theft in Coder v2 (self-hosted developer workspace platform) stems from azureidentity.Validate() verifying the PKCS#7 signer's certificate chain but skipping signature verification of the signed content itself. Remote attackers who know a target VM's vmId (a UUIDv4) can forge a PKCS#7 envelope containing a legitimate Azure certificate alongside attacker-controlled content and POST it to the unauthenticated /api/v2/workspaceagents/azure-instance-identity endpoint to receive the victim workspace agent's session token, which then unlocks Git SSH keys, OAuth tokens for GitHub/GitLab/Bitbucket, and workspace secrets. No public exploit identified at time of analysis, but the vulnerability is vendor-confirmed via GHSA-6x44-w3xg-hqqf and a detailed root-cause analysis with attack-path diagram is published.

Broken access control in Arcane's GitOps backend (versions <= 1.18.1) allows any authenticated low-privilege user to exfiltrate plaintext Git credentials (PATs/SSH keys) stored for source-of-truth repositories. Eight of nine /api/customize/git-repositories endpoints omit the checkAdmin() gate, letting a 'user' role attacker repoint a repository URL to an attacker-controlled host and trigger a /test or /branches call that transmits the decrypted token via HTTP Basic auth. No public exploit identified at time of analysis, but the GHSA advisory documents a complete attack chain and a patched release (1.19.0) is available.

{option}` or `/gitlab webhook {option}`, resulting in availability impact (A:H) to the Gitlab plugin infrastructure. CVSS 6.5 reflects moderate risk, with EPSS data and active exploitation status not available at time of analysis.

GitLab CE and EE are vulnerable to authenticated denial of service through excessive memory consumption, affecting all installations from version 8.3 up to the patched releases. An authenticated user with minimal privileges can submit maliciously crafted input that bypasses proper validation, causing the server to allocate memory without adequate bounds until service degradation or outage occurs. EPSS is low at 0.06% (18th percentile), no active exploitation is confirmed (CISA KEV absent, SSVC exploitation status: none), and a vendor patch was released on May 13, 2026.

Private group member enumeration in GitLab CE/EE affects all versions from 15.1 through unfixed releases 18.9.6, 18.10.5, and 18.11.2, permitting any authenticated user holding project membership to discover the member list of an otherwise private group due to a missing authorization check (CWE-862). The flaw collapses GitLab's tiered permission boundary between project-level and group-level access, leaking organizational membership data to users who have no entitlement to view it. No public exploit has been identified at time of analysis, and an EPSS score of 0.01% (2nd percentile) reflects near-zero observed exploitation probability.

Stored cross-site scripting in GitLab Enterprise Edition lets an authenticated user holding Developer-role permissions inject arbitrary JavaScript that executes in the browsers of other users who view the affected content. The flaw stems from improper input sanitization and affects all 16.4-series through 18.11.x releases prior to the 18.9.7, 18.10.6, and 18.11.3 patch releases. No public exploit identified at time of analysis, and EPSS is very low (0.02%), but CVSS is rated 8.7 because the scope-changing XSS can hijack higher-privileged user sessions.

Server-Side Request Forgery (SSRF) in GitLab Enterprise Edition's virtual registry upstream feature allows an authenticated low-privileged user who controls a virtual registry upstream to direct the GitLab server to issue HTTP requests against internal hosts that would otherwise be inaccessible from the network perimeter. Affected versions span GitLab EE 18.8 through 18.11 across three patch trains. No public exploit exists and no active exploitation has been identified at time of analysis; EPSS probability stands at 0.01%, consistent with the narrow preconditions required.

Stored cross-site scripting in GitLab Enterprise Edition's customizable analytics dashboards allows an authenticated user to execute arbitrary JavaScript in the browsers of other users who view the affected dashboard. The flaw affects EE 18.7-18.9.6, 18.10-18.10.5, and 18.11-18.11.2, carries a CVSS 8.7 (scope-changed) rating, and a vendor patch is available. No public exploit identified at time of analysis and EPSS is very low (0.02%, 5th percentile).

Merge request approval bypass in GitLab Enterprise Edition allows authenticated users to circumvent policy-enforced approval gates due to improper cleanup of orphaned approval policy records. Affected are all GitLab EE deployments running versions from 15.7 up to (but not including) 18.9.7, 18.10.6, and 18.11.3. No public exploit exists and no active exploitation has been confirmed; however, the integrity impact carries meaningful governance risk in regulated environments where merge approval policies serve as a compliance or change-management control.

Cross-site scripting in GitLab CE/EE 18.11.x (before 18.11.3) enables an authenticated low-privilege attacker to inject unsanitized content that executes arbitrary JavaScript within another user's browser session. The CVSS Scope Changed (S:C) flag reflects the cross-user impact boundary: the vulnerability allows one GitLab principal to affect a distinct security context belonging to a different user, including potentially higher-privileged accounts such as project owners or instance administrators. No public exploit code exists and no active exploitation has been identified - EPSS at 0.02% (5th percentile) and SSVC exploitation status of 'none' both confirm low immediate urgency - though GitLab's wide enterprise deployment makes patching to 18.11.3 advisable.

Stored cross-site scripting in GitLab Enterprise Edition 18.7-18.11.x allows an authenticated user to inject arbitrary JavaScript that executes in other users' browser sessions due to improper input sanitization. The CVSS 8.7 score is elevated by Scope:Changed (S:C), reflecting that injected script can pivot across security contexts and potentially target administrators. No public exploit identified at time of analysis, EPSS is very low (0.02%, 5th percentile), and SSVC indicates no observed exploitation, but a vendor patch is available across all three affected branches.

Improper access control in GitLab Enterprise Edition allows authenticated users holding only developer-role permissions to remove code owner approval rules from merge requests, effectively bypassing a critical gatekeeping control in the software development lifecycle. Affected are all GitLab EE versions from 11.10 up to (but not including) 18.9.7, 18.10.6, and 18.11.3. No public exploit or active exploitation has been identified at time of analysis; EPSS is 0.01% and CISA SSVC rates exploitation as none, indicating this is a low-urgency but organizationally meaningful integrity issue for teams relying on code owner rules for compliance or security enforcement.

Cross-Site Request Forgery in GitLab CE/EE allows an unauthenticated attacker to create unauthorized Jira subscriptions within a targeted authenticated user's namespace by tricking the victim into clicking a specially crafted link. All GitLab installations from version 11.10 through the pre-patch 18.x releases are affected across both Community and Enterprise editions. No public exploit exists and this is not listed in CISA KEV; however, the broad version range spanning over seven years of releases and the prevalence of Jira integrations in enterprise GitLab deployments make patching a meaningful priority.

Improper authorization in GitLab CE/EE exposes confidential issue content to any authenticated user on public projects across three active release branches. The flaw (CWE-288) allows a low-privileged, authenticated user - including users with no project membership - to read issue content that project owners explicitly marked confidential and restricted. With patch versions released on May 13, 2026 and no public exploit or KEV listing identified at time of analysis, the immediate threat is bounded, though the confidentiality impact is rated High by CVSS given the potential for sensitive business or security-relevant issue data to be disclosed.

Package protection rule bypass in GitLab CE/EE allows authenticated users holding developer-role permissions to circumvent registry protections that should restrict their write or publish actions. Affecting all GitLab Community and Enterprise Edition instances running versions 18.3 through 18.9.6, 18.10 through 18.10.5, and 18.11 through 18.11.2, an attacker with a legitimately provisioned developer account can undermine the integrity controls placed on protected packages. No public exploit code exists and no active exploitation has been identified at time of analysis; the EPSS score of 0.01% (1st percentile) and SSVC exploitation rating of 'none' confirm this is a low-urgency finding.

GitLab's Jira integration exposes out-of-scope Jira issues to authenticated GitLab users across all editions (CE and EE) from version 13.7 through the patched releases, due to the integration's project-scope filter operating only as a UI display control rather than an enforced access boundary. The Changed scope (S:C) in the CVSS vector reflects that impact crosses into Atlassian Jira - a component outside GitLab's own trust domain - allowing confidential Jira issue data to leak beyond intended project boundaries. No public exploit exists and no active exploitation has been confirmed; EPSS is negligible at 0.01% (3rd percentile), placing this firmly in low-exploitation-probability territory despite a broad version range spanning over five years of releases.

Unauthorized debug symbol exposure in GitLab CE/EE allows access to private debugging artifacts from projects the requester should not be able to reach, due to improper authorization controls (CWE-639: Authorization Bypass Through User-Controlled Key). Affected instances span all GitLab CE and EE deployments running versions from 16.7 up through the patched releases 18.9.7, 18.10.6, and 18.11.3 - a broad version window of roughly two years of releases. No public exploit has been identified at time of analysis, EPSS is 0.02% (5th percentile), and CISA SSVC rates exploitation status as none, collectively indicating low near-term exploitation probability despite the wide version exposure.

Authenticated developers in GitLab CE/EE versions before 18.9.7, 18.10.6, and 18.11.3 can bypass PyPI package protection rules and upload restricted packages due to improper authorization checks. Despite CVSS 4.3 rating, the 0.01% EPSS score and CISA SSVC assessment (exploitation: none, automatable: no, technical impact: partial) indicate minimal real-world exploitation risk, with no confirmed active exploitation or public exploits identified at time of analysis.

GitLab Enterprise Edition's instance-level approval rule editing prevention control can be bypassed by authenticated Maintainer-level users due to missing server-side authorization checks (CWE-862). Affected are all GitLab EE versions from 16.10 through before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3. An attacker holding Maintainer permissions can modify or delete project approval rules even when an administrator has explicitly enabled the instance-level restriction designed to prevent such changes, undermining the integrity of merge request approval workflows. No public exploit identified at time of analysis, and EPSS is at the 1st percentile, indicating negligible opportunistic exploitation risk.

Denial of service in GitLab CE/EE allows unauthenticated remote attackers to disrupt service availability by sending specially crafted requests that exploit insufficient input validation. Affected versions span 9.0 through 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 across both Community and Enterprise editions, with no public exploit identified at time of analysis and a low EPSS score (0.04%) indicating limited near-term exploitation likelihood despite the network-reachable attack surface.

Authenticated developers in GitLab CE/EE can bypass container registry tag protection policies and delete protected tags due to improper server-side authorization checks (CWE-639), affecting all versions from 17.10 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3. The vulnerability was privately disclosed via HackerOne (report 3480620) and remediated in the May 2026 patch release cycle. No public exploit identified at time of analysis, and an EPSS of 0.01% (1st percentile) combined with SSVC exploitation status of 'none' indicate minimal current real-world exploitation risk.

OAuth scope enforcement bypass in GitLab CE/EE allows an authenticated user holding a read_api-scoped OAuth token to perform unauthorized write operations - specifically creating issues and adding comments - in private projects. Affected are all GitLab Community and Enterprise Edition installations from version 16.0 up to the patched releases 18.9.7, 18.10.6, and 18.11.3. A publicly available proof-of-concept exists, and while EPSS probability is extremely low (0.01%, 1st percentile) with no CISA KEV listing, the integrity impact is rated High given the ability to inject content into private project issue trackers.

Denial-of-service in GitLab Enterprise Edition allows a crafted file upload to exhaust service availability through improper deserialization validation. The vulnerability spans an exceptionally wide range, affecting all GitLab EE instances from version 11.9 through the 18.11 line until patched releases. There is no public exploit identified at time of analysis and EPSS sits at 0.02% (4th percentile), indicating low observed exploitation pressure, though the breadth of the affected version range means unpatched installations represent a meaningful attack surface for availability disruption.

Denial of service in GitLab Community and Enterprise Editions (versions 18.5 through 18.11.2) allows remote unauthenticated attackers to exhaust resources by submitting specially crafted JSON payloads that bypass input validation. The flaw is network-reachable with low complexity and no authentication required, but only impacts availability (CVSS 7.5, A:H). No public exploit identified at time of analysis, and EPSS exploitation probability is very low at 0.04% (11th percentile), though CISA SSVC flags the issue as automatable.

Denial of service in GitLab Community and Enterprise Edition versions 18.5 through 18.11.2 allows unauthenticated remote attackers to disrupt service availability by sending specially crafted payloads to certain API endpoints. The flaw maps to CWE-1284 (improper validation of specified quantity in input) and has been patched in 18.9.7, 18.10.6, and 18.11.3. No public exploit identified at time of analysis and EPSS probability is very low (0.03%, 9th percentile), but the SSVC framework flags the attack as automatable with partial technical impact.

Unauthorized issue disclosure in GitLab CE/EE exposes confidential project data to authenticated Guest-level users who lack explicit project membership. By exploiting an object-level authorization flaw (CWE-639), a Guest user can retrieve issues belonging to projects they have no sanctioned access to, bypassing GitLab's project-level visibility controls. No public exploit exists and EPSS sits at 0.01%, but the broad version range - spanning GitLab 15.1 all the way through 18.11.2 - means a large install base requires patching, and the confidentiality risk is real for organizations using issues to track sensitive engineering or security work.

HTML and JavaScript injection via email notifications in GitLab CE/EE (versions 15.11 through 18.11.2) allows an authenticated low-privileged user to deliver malicious content to other users' inboxes by embedding unsanitized markup into platform-generated notifications. The attack crosses a scope boundary (S:C in CVSS) because the injected code executes in the recipient's email client or browser context rather than GitLab itself, enabling phishing, credential harvesting, or session theft against targeted users. No public exploit has been identified at time of analysis and SSVC signals no active exploitation, though the broad version range - spanning over three years of releases - expands the exposed population significantly.

Unauthenticated remote access to GitLab API operations via gitlab-mcp-server's SSE transport allows attackers to execute all 86 exposed GitLab management tools-including repository deletion, file modification, and configuration changes-using the operator's Personal Access Token. When configured with USE_SSE=true (a documented feature), the Node.js server binds to 0.0.0.0 with wildcard CORS headers, enabling both network-adjacent attackers and malicious web pages to invoke destructive operations without credentials. Public exploit code demonstrates the attack path from initial SSE connection through authenticated GitLab API calls. Patch version 0.6.0 addresses the authentication bypass per GitHub advisory GHSA-8jr5-6gvj-rfpf.

draw.io is a configurable diagramming and whiteboarding application. Prior to version 29.7.9, the draw.io client accepts a ?gitlab= URL parameter that overrides the GitLab server URL used during OAuth sign-in. A crafted link causes the user's click on draw.io's "Authorize in GitLab" dialog to open a popup on the attacker-controlled host instead of gitlab.com. This can lead to credential fishing and session state token exfiltration. This issue has been patched in version 29.7.9.

Policy rollback vulnerability in gittuf versions up to 0.13.1 allows attackers with push access to the Reference State Log (RSL) to downgrade repository policies to previously signed versions, bypassing security controls. An attacker cannot roll back to policies that would be unsigned by the current root keys, but can selectively choose any valid prior policy state. Vendor-released patch: gittuf v0.14.0 introduces monotonically increasing version numbers to all policy metadata to prevent rollback attacks.

Cross-site scripting (XSS) in GitLab CE/EE 18.11 before 18.11.1 allows authenticated users to inject unauthorized content into other users' browsers through improper input validation in the Mermaid diagram sandbox. An attacker must have valid GitLab credentials and the victim must view a malicious diagram, limiting real-world impact despite the publicly available exploit code. SSVC analysis rates this as non-automatable with partial technical impact, consistent with the low CVSS 3.5 score.

Cross-Site Request Forgery (CSRF) in GitLab CE/EE allows remote unauthenticated attackers to execute GraphQL mutations as authenticated victims through crafted web pages. Affects all versions from 17.0 through 18.11.0, with publicly available exploit code (HackerOne report 3627285). Despite high CVSS 8.1, exploitation requires user interaction (phishing/social engineering) and is not automatable per CISA SSVC framework. No evidence of active exploitation in CISA KEV at time of analysis. Vendor patches released: 18.9.6, 18.10.4, and 18.11.1.

Authenticated users can trigger denial of service in GitLab CE/EE versions 10.6 through 18.11.0 by sending crafted requests to the discussions endpoint that exhaust server resources. The vulnerability requires valid authentication credentials and affects all affected versions across the 10.6, 18.9, 18.10, and 18.11 release branches. Publicly available exploit code exists; CISA has not yet listed this in the Known Exploited Vulnerabilities catalog, but active exploitation likelihood is moderate given public POC availability and the low complexity of resource exhaustion attacks.

Authenticated users can trigger denial of service in GitLab by overwhelming system resources through the GraphQL API due to insufficient resource allocation limits. Affected versions span from 12.4 through 18.11.0 across three release branches. Publicly available exploit code exists, though active exploitation has not been confirmed in CISA KEV. CVSS 6.5 reflects moderate severity with high availability impact but requires valid authentication.

Denial of service in GitLab CE/EE affects authenticated users who can trigger resource exhaustion when retrieving notes under specific conditions, causing service unavailability. Versions 9.2 through 18.9.5, 18.10.0 through 18.10.3, and 18.11.0 are vulnerable. An authenticated attacker with standard user privileges can exploit this remotely without user interaction via crafted note retrieval requests. A publicly available exploit exists, and patches have been released by GitLab.

Authenticated project owners in GitLab CE/EE versions 11.2-18.9.5, 18.10-18.10.3, and 18.11-18.11.0 can bypass group fork prevention settings due to improper authorization checks, allowing them to create forks when they should be restricted. The vulnerability requires authentication and high-privilege access (project owner role), resulting in low severity (CVSS 2.7). Publicly available exploit code exists and patch versions have been released by the vendor.

Denial of service in GitLab CE/EE versions 12.3 through 18.11.0 allows authenticated users to trigger excessive resource consumption during issue import operations due to improper input validation on user-supplied data. The vulnerability affects all minor versions from 12.3 onwards until patched versions 18.9.6, 18.10.4, and 18.11.1. Publicly available exploit code exists, and CISA SSVC assessment indicates the vulnerability is exploitable but not automatable at scale.