Gitlab

Server-Side Request Forgery in Gitingest through 0.3.1 allows unauthenticated attackers to redirect outbound server connections to arbitrary attacker-controlled hosts by exploiting a prefix-only hostname validation bypass in the `_validate_host` function. Because Gitingest may carry GitHub personal access tokens as HTTP basic auth credentials on outbound git requests, any host whose name begins with `git.`, `gitlab.`, or `github.` passes validation and becomes a credential harvesting endpoint. No public exploit code is confirmed at time of analysis and no CISA KEV listing exists, but the CVSS 4.0 score of 8.3 reflects the combination of low attack complexity, unauthenticated access, and high confidentiality impact.

Server-Side Request Forgery (SSRF) in GitLab's AI Gateway component allows an authenticated user with Duo Agent Platform access to redirect outbound model requests to an attacker-controlled endpoint by injecting a crafted inline flow configuration that overrides the HTTP Host header. Exploitation results in exfiltration of Google Cloud Vertex cloud service credentials and private signing keys held by the AI Gateway, enabling an adversary to subsequently authenticate to GCP services outside GitLab's control. No public exploitation (CISA KEV) has been confirmed, but a publicly available exploit exists via a disclosed HackerOne report, materially increasing real-world risk.

Server-Side Request Forgery (SSRF) in GitLab AI Gateway allows authenticated users with Duo Agent Platform access to exfiltrate Google Vertex AI or AWS Bedrock cloud service credentials by injecting a malicious endpoint into crafted model metadata, causing the gateway to proxy requests - including cloud credentials - to an attacker-controlled server. All AI Gateway releases from 18.9.0 through 19.2.2 are affected across three version branches; GitLab has confirmed remediation. A public exploit exists per the HackerOne reference, and the CVSS Scope Change metric (S:C) reflects that successful exploitation extends compromise to external cloud infrastructure beyond the GitLab instance itself.

GitLab Enterprise Edition's SCIM user provisioning feature allows an authenticated low-privileged user to trigger an unbounded loop via specially crafted input, causing denial of service on the affected instance. Versions spanning a wide range from 11.10 through 19.3.0 are affected, with vendor-released patches now available. A publicly available exploit is documented in HackerOne report #3292470; however, this vulnerability is not listed in CISA KEV, indicating active exploitation has not been confirmed at scale.

Improper authorization in GitLab Enterprise Edition allows an authenticated project Maintainer to access the interactive terminal of a protected environment they are explicitly excluded from, bypassing environment-level access controls enforced separately from project roles. Affected versions span a wide range - all EE releases from 11.3 through 19.3.0 - meaning the exposure window is substantial across the enterprise install base. A publicly available exploit exists via a disclosed HackerOne report; no active exploitation (CISA KEV) has been confirmed at time of analysis.

Improper authorization in GitLab Enterprise Edition allows an authenticated reporter-level user who authored a merge request to reset that MR's approval rules, potentially bypassing mandatory code-review controls enforced by administrators. All GitLab EE versions from 13.1 through 19.3.0 are affected, with remediated releases published. A publicly available exploit exists via HackerOne, though the vulnerability is not listed in CISA KEV and the low CVSS score (3.5) reflects the constrained attack conditions requiring authentication and prior MR authorship.

Improper job dependency handling in GitLab Enterprise Edition's Pipeline Execution Policy enforcement allows an authenticated developer-role user to influence the execution environment of policy enforcement jobs. Affected versions span the 19.1, 19.2, and 19.3 release trains prior to their respective patches. While CVSS rates this a moderate 4.3, a publicly available exploit exists via HackerOne, and the security significance is elevated because Pipeline Execution Policies are a deliberate administrative security control - undermining their enforcement environment erodes a defense-in-depth layer in CI/CD pipelines. No active exploitation has been confirmed (not in CISA KEV).

Arbitrary command execution in GitLab Enterprise Edition's CI pipeline context is possible for authenticated users holding developer-role permissions, exploiting the platform's Claude agent which processes configuration drawn from a user-controlled source. Affected versions span the 18.9 through 19.3 release trains, with fixes delivered in 19.1.7, 19.2.5, and 19.3.1. A publicly available exploit exists via HackerOne report #3863650, though active exploitation has not been confirmed by CISA KEV; the CVSS score of 7.3 and public proof-of-concept make this a credible and urgent patching priority for GitLab EE operators.

GitLab CE/EE allows any authenticated user to cause denial of service against background job processing due to missing object count limits, affecting all versions from 12.8 through pre-19.3.1. The CVSS vector (PR:L, AV:N, A:H) confirms low-privilege network-accessible exploitation with full availability impact on Sidekiq-backed async processing, including CI/CD pipelines and repository operations. No public exploit code has been identified and this vulnerability is not listed in CISA KEV at time of analysis.

Stack-based buffer overflow in GNOME Dia diagram editor (0.98.0 and earlier) permits stack exhaustion and potential return-address corruption when a victim opens a crafted .dia XML file containing a Bus object with an attacker-controlled bus_handles value and then moves a handle in the diagram. The root cause - an unbounded g_alloca() call driven by an unvalidated file attribute - is also present in objects/Misc/tree.c via Tree objects, widening the attack surface. No public exploit or CISA KEV listing exists at time of analysis, but the GitLab issue provides sufficient technical detail for proof-of-concept development.

CPU exhaustion in libsoup's HTTP Range header processing affects any SoupServer deployment carrying the CVE-2025-32907 fix but not MR !550. Supplying a Range header with approximately 25,000 repeated satisfiable byte ranges triggers an O(N²) coalescing loop - each g_array_remove_index() call induces an O(N) memmove on GArray - blocking the server's event loop for roughly 90 ms per request from a single unauthenticated client. The description explicitly rules out memory corruption and information disclosure; this is a pure availability issue with no public exploit identified at time of analysis.

Remote code execution in GitLab CE/EE package registry exposes instances across three active version branches to full host compromise by an authenticated low-privilege user. Path traversal (CWE-22) in the package registry component allows directory escape and arbitrary file write under certain server-side conditions, with CVSS scope change (S:C) confirming that impact extends beyond the GitLab application to the underlying host. A publicly available exploit exists via HackerOne report 3754194, though this vulnerability is not listed in the CISA KEV catalog at time of analysis.

GraphQL multiplex query handling in GitLab CE/EE improperly validates request methods, permitting unauthenticated attackers to trigger state-changing mutations via HTTP GET requests, effectively bypassing CSRF protections. All GitLab CE/EE deployments running versions 18.2 through the affected ranges across the 18.x, 19.0, 19.1, and 19.2 release lines are exposed. A publicly available exploit exists via HackerOne disclosure, and successful exploitation allows an attacker to perform arbitrary data-modifying operations on behalf of any authenticated GitLab user who can be lured to a malicious page.

Unauthenticated data tampering in GitLab CE/EE (18.2-18.11.10, 19.0-19.0.7, 19.1-19.1.5, 19.2-19.2.3) lets a remote attacker modify or delete public projects and user data by abusing a GraphQL directive, per CVE-2026-19478 (CVSS 9.4). The flaw was self-reported by GitLab and publicly available exploit code exists via a HackerOne disclosure, though it is not listed in CISA KEV. Impact is weighted toward integrity and availability rather than data theft (CVSS C:L/I:H/A:H).

Unauthorized message injection in the Mattermost GitLab Plugin (<=11.8) allows authenticated users to post bot-authored messages containing arbitrary URLs into restricted channels by exploiting two missing authorization checks: channel permission verification on the caller-supplied `post_id` parameter, and GitLab instance validation of the `web_url` parameter. Exploitation targets the `createIssue` and `attachCommentToIssue` API endpoints without requiring elevated privileges. No active exploitation is confirmed by CISA KEV and no public exploit code has been identified at time of analysis, but the low attack complexity and authenticated-only prerequisite make this a realistic internal threat in any Mattermost deployment running the GitLab integration.

Incorrect privilege assignment in GitLab Enterprise Edition allows a user with pending group membership to receive permissions granted by a custom role, bypassing the membership approval gate entirely. The flaw spans all GitLab EE versions from 15.6 through 19.2.1 - a window of approximately four years - and is documented via a public HackerOne report, though no active exploitation has been recorded in the CISA KEV catalog. The vendor-assigned CVSS score of 3.3 accurately reflects the narrow exploitation conditions: high attack complexity and high privilege prerequisites constrain real-world impact to partial confidentiality and integrity effects within a single affected group.

Unauthorized disclosure of external status check configuration in GitLab Enterprise Edition allows any authenticated user holding a developer-role to read merge request API data that should be restricted to higher-privileged roles (maintainer or owner), due to a missing authorization check on the affected endpoint. Versions spanning 16.0 through 19.2.x are affected across a wide installation base. A publicly available proof-of-concept was disclosed via HackerOne (report #3622861), and GitLab has confirmed and remediated the issue; no confirmed active exploitation (CISA KEV) has been reported at time of analysis.

IP-based access restriction bypass in GitLab Enterprise Edition exposes private project merge request metadata to authenticated users who would otherwise be blocked by network-level controls. Affecting all EE versions from 12.0 up to 19.0.6, 19.1.4, and 19.2.2, the flaw stems from a missing authorization check in a merge requests API endpoint that fails to enforce configured IP allowlists. A publicly available exploit exists via HackerOne, and while the confidentiality impact is scoped to limited merge request information, the bypass of a deliberate security boundary elevates practical risk for organizations relying on IP restrictions as a compensating control.

Stored cross-site scripting in GitLab CE/EE's analytics dashboard component allows an authenticated low-privilege user to inject malicious JavaScript into table cell content that executes in the browsers of other users who view the affected dashboard. The scope change (S:C in CVSS) confirms the impact crosses security boundaries, enabling session hijacking, credential theft, or unauthorized API actions on behalf of victims including administrators. A publicly available proof-of-concept exploit exists via HackerOne report #3830478; no confirmed active exploitation in CISA KEV at time of analysis.

Stored or reflected cross-site scripting in GitLab CE/EE's analytics dashboard allows an authenticated attacker with low privileges to inject malicious scripts into pagination controls, executing in the browser context of any user who views the affected page. Affected versions span 18.2 through 19.2.1 across all three supported release trains. A publicly available proof-of-concept exists via HackerOne report 3830061; the Changed scope (S:C) and High C/I impacts elevate real-world risk significantly beyond a typical low-privilege XSS.

Privilege escalation in GitLab Enterprise Edition exposes project governance controls to any authenticated project member due to missing authorization checks on the project update API endpoint. Affecting EE versions 19.1.0 through 19.1.3 and 19.2.0 through 19.2.1, this flaw lets lower-privileged users (developers, reporters) silently overwrite project settings normally restricted to maintainers or owners - including branch protection rules, merge approval requirements, and access policies. A publicly available exploit exists via HackerOne; active exploitation is not confirmed by CISA KEV, but the low attack complexity combined with public proof-of-concept code significantly elevates operational urgency.

Incorrect authorization in GitLab Enterprise Edition's GraphQL layer allows authenticated users to read policy configurations belonging to namespaces they have no authorized access to. Affected versions span GitLab EE 19.1 before 19.1.4 and 19.2 before 19.2.2. A publicly available proof-of-concept exploit exists (HackerOne report #3776182), though no active exploitation has been confirmed by CISA KEV, making this a medium-severity information disclosure risk for organizations running GitLab EE at affected patch levels.

Improper authorization of namespace identity in GitLab Enterprise Edition 19.1.x and 19.2.x allows an authenticated low-privilege user to attribute AI feature usage to arbitrary namespaces they do not own, crossing organizational authorization boundaries within a multi-tenant deployment. The flaw, classified as CWE-639, arises because user-supplied identity information in requests is insufficiently validated before being used to authorize namespace-scoped AI operations, producing a scope change that affects namespaces beyond the attacker's own. GitLab has released patches in versions 19.1.4 and 19.2.2, and no public exploit code exists at time of analysis.

Denial of service in GitLab CE/EE (versions 18.5 through pre-19.0.6, 19.1 before 19.1.4, and 19.2 before 19.2.2) allows unauthenticated remote attackers to exhaust server resources through improper input validation, rooted in CWE-770 (resource allocation without throttling limits). Exploitation is conditional - the description explicitly qualifies 'under certain conditions' - which is reinforced by SSVC classifying the attack as non-automatable despite a CVSS PR:N/AC:L rating. A publicly available proof-of-concept exists via a HackerOne disclosure, though EPSS sits at only 0.41% (34th percentile) and CISA has not listed this in the KEV catalog, suggesting exploitation remains opportunistic rather than widespread.

Package registry metadata modification in GitLab CE/EE exposes an improper authorization flaw (CWE-863) that permits authenticated developer-role users to alter package registry metadata normally restricted to maintainers, across all instances running versions 17.6 through 19.2.1. A publicly available exploit has been disclosed via HackerOne (report 3598070), making this immediately actionable for insider or contractor threat scenarios. No active exploitation has been confirmed by CISA KEV, but the combination of wide version range, broad GitLab deployment footprint, and public exploit code elevates practical risk beyond the moderate CVSS 4.3 score alone.

Improper authorization in GitLab CE/EE pipeline reference validation allows authenticated developer-role users to execute CI/CD pipelines on protected branches they lack push permissions to access, effectively bypassing branch protection policies. All GitLab versions from 19.0 through 19.2 are affected until the respective patch releases. A publicly available exploit exists via HackerOne report #3832069, though no confirmed active exploitation has been recorded in the CISA KEV catalog at time of analysis.

Stored cross-site scripting in GitLab CE/EE 19.2 before 19.2.2 lets an authenticated user holding only developer-role permissions inject unsanitized HTML that executes in the browser of a higher-privileged user who opens a CI job modal, enabling privilege escalation. Publicly available exploit code exists (HackerOne report #3880796), though EPSS is modest at 0.30% (22nd percentile) and CISA SSVC records no observed exploitation. The high CVSS 9.0 is driven by a scope change and total confidentiality/integrity/availability impact once the payload runs in a victim's session.

Improper authorization checks on a GitLab Enterprise Edition group settings page allow any authenticated user to view restricted configuration settings they should not have access to. GitLab EE versions from 17.7 through 19.0.5, 19.1.0 through 19.1.3, and 19.2.0 through 19.2.1 are affected; patched releases (19.0.6, 19.1.4, 19.2.2) are available. No public exploit code and no confirmed active exploitation exist at time of analysis.

Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged user achieve arbitrary host command execution by storing a malicious Git branch value and triggering a deployment. The branch fields (customGitBranch, branch, gitlabBranch, bitbucketBranch, giteaBranch) were left without server-side validation because the earlier fix for CVE-2026-45628 was incomplete, so attacker-controlled input flows unescaped into shell-based git clone commands. No public exploit has been identified at time of analysis, but the flaw carries a CVSS of 9.9 and is fixed in 0.29.13.

Remote code execution and privilege escalation across Jenkins core and multiple plugins were disclosed in the 2026-08-05 security advisory, with the most critical issue being a JEP-200 deserialization filter bypass (CVE-2026-70426) in Remoting 3384.v60d89463d9e0 and earlier that allows agent processes or holders of Agent/Connect permission to execute arbitrary code on the Jenkins controller. Compounding this, two separate arbitrary file-write primitives (CVE-2026-70427 via malicious tar archives, CVE-2026-70428 via path traversal in file parameter names) independently enable code execution by writing into JENKINS_HOME/init.groovy.d/ or deploying rogue plugins. No public exploit code or CISA KEV listing was identified at time of analysis, but the attack surface spans both network-accessible agents and authenticated users with low-privilege build permissions.

Heap buffer overflow in libXfont2's font-server client allows a malicious or compromised font server to overflow the X server's heap with attacker-controlled content by sending overlapping glyph source offsets. Affected systems running X server as root are exposed to privilege escalation; unprivileged X server instances crash with denial of service. All libXfont2 versions prior to 2.0.9 are affected. No public exploit code or CISA KEV listing has been identified at time of analysis, but the attacker-controlled write primitive makes this a high-severity memory corruption issue.

Out-of-bounds heap read and write in libXfont2's font server client (all versions prior to 2.0.9) allows a malicious or compromised network font server to corrupt X server heap memory, enabling privilege escalation when the X server runs as root or denial of service via crash in unprivileged configurations. The flaw arises because fs_read_glyphs() in src/fc/fserve.c allocates the encoding[] array based on num_extents from one protocol reply but indexes it using num_chars from a separate reply with no cross-validation, so a crafted server can send mismatched values to trigger OOB heap reads and attacker-controlled OOB heap writes. No public exploit code or CISA KEV listing has been identified at time of analysis; the vendor-released fix is confirmed in libXfont2-2.0.9.

GitLab CE/EE permits an authenticated developer-role user who has been removed from a project to continue committing code changes by exploiting improper authorization checks on merge request collaboration settings (CWE-863). The flaw spans a massive version range from 10.6 through 19.2.0, affecting both Community and Enterprise editions. No active exploitation is confirmed via CISA KEV, but a publicly available proof-of-concept exists on HackerOne, and the issue has been patched in 19.0.5, 19.1.3, and 19.2.1.

Reflected cross-site scripting in GitLab CE/EE across a vast version range (14.0 through pre-patch releases) enables an unauthenticated attacker to execute arbitrary JavaScript in a victim's browser by enticing them to open a crafted URL. The CVSS vector confirms no authentication is required on the attacker side (PR:N), user interaction is needed (UI:R), and the scope changes (S:C) - meaning the injected script runs outside the originating page's trust boundary, enabling session hijacking, credential theft, or actions performed on the victim's behalf. A publicly available exploit exists on HackerOne (report #3539833), raising the practical risk above what the moderate CVSS score of 4.7 alone suggests.

Improper access control in GitLab CE/EE exposes CI/CD test report contents to authenticated users holding only guest-role permissions, allowing unauthorized read access to data from projects they should not be able to view. Affected versions span 18.4 through pre-19.0.5, 19.1 through pre-19.1.3, and 19.2 through pre-19.2.1. Publicly available exploit code exists via a disclosed HackerOne report, though no active exploitation has been confirmed by CISA KEV at time of analysis.

Information disclosure in GitLab CE/EE (all versions from 10.1.0 before 19.0.5, 19.1 before 19.1.3, and 19.2 before 19.2.1) allows an authenticated user holding only the Developer role to reach unauthorized information because internal request handling enforces insufficient access controls (CWE-201). Publicly available exploit code exists (referenced HackerOne report #3658324), but there is no public exploit identified as being used in active attacks. With a CVSS of 8.5 driven by a scope-changing confidentiality impact, this is a meaningful privilege/authorization boundary failure rather than a full remote code execution flaw.

Unauthorized disclosure of project import source information in GitLab CE/EE stems from a missing authorization check (CWE-863), allowing unauthenticated remote users to view sensitive metadata about how a project was originally imported. All GitLab installations running versions from 16.6 up to 19.0.4, 19.1.2, and 19.2.0 are affected. A publicly available exploit exists via a disclosed HackerOne report, though no confirmed active exploitation (CISA KEV) has been recorded at time of analysis.

Improper attribute validation in GitLab CE/EE (18.0 through 19.0.5, 19.1 through 19.1.3, 19.2 through 19.2.1) lets an authenticated user tamper with CI/CD configuration owned by another user by injecting user-controlled attributes into pipeline schedule input processing. Publicly available exploit code exists (HackerOne #3800511), though the flaw is not listed in CISA KEV and requires authentication plus high-complexity conditions to trigger. GitLab, the reporter, has shipped fixed releases across all supported branches.

Approval bypass in GitLab Enterprise Edition allows authenticated users to merge code into protected branches without satisfying required approval rules by exploiting a race condition in the approval rule processing pipeline. Affected deployments span GitLab EE versions 17.0 through 19.2, with fixed releases available at 19.0.5, 19.1.3, and 19.2.1. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, though the integrity risk is significant in regulated environments where protected branch approvals serve as a primary code integrity control.

Improper authorization in a GitLab CE/EE projects API endpoint allows an authenticated user holding the Maintainer role to modify protected branch configurations beyond what their role should permit, across all versions from 12.8 through 19.2.0. Maintainer-role users - commonly assigned in enterprise GitLab deployments - can exploit this to weaken or remove branch protection rules that enforce code review gates and direct-push restrictions. A publicly available exploit exists via HackerOne report 3807593; no confirmed active exploitation (CISA KEV) has been identified at time of analysis, though the POC materially lowers the bar for exploitation.

Confidential issue title disclosure in GitLab CE/EE affects all versions from 8.8 through 19.2 (pre-fix), allowing unauthenticated access to sensitive issue titles via improper authorization checks on publicly accessible merge requests. An attacker who can access a public merge request linked to a confidential issue can read the confidential issue's title without any project membership or authentication. No active exploitation confirmed in CISA KEV, but a publicly available exploit exists via HackerOne report 3708242, and EPSS data was not provided - risk is moderate given broad version impact and low exploitation complexity.

Information disclosure in GitLab Enterprise Edition's AI-assisted code review feature allows authenticated users to access data from projects they are not authorized to view. Affected versions are 19.1.x before 19.1.3 and 19.2.x before 19.2.1. An attacker with any level of authenticated access can craft malicious code content that, when processed by the AI review engine, causes the model to return information from unauthorized projects - a classic prompt injection boundary-crossing attack. No public exploit code has been identified and the vulnerability is not listed in the CISA KEV catalog.

Improper authorization enforcement during token generation in GitLab Enterprise Edition allows an authenticated low-privilege user to bypass administrator-configured tool governance policies. Affected are all GitLab EE installations running 19.1 before 19.1.3 and 19.2 before 19.2.1. No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV; however, the network-accessible, low-privilege attack vector makes this a realistic insider threat in enterprises relying on GitLab EE's governance controls.

Denial of service in GitLab CE/EE (all versions from 11.8 before 19.0.5, 19.1 before 19.1.3, and 19.2 before 19.2.1) allows an unauthenticated attacker to exhaust server resources through insufficient throttling when the application processes merge request discussions. Vendor-reported by GitLab with no public exploit identified at time of analysis; the availability-only impact (CVSS 7.5, A:H) reflects service disruption rather than data compromise. Exploitation is conditional ('under certain conditions'), which tempers the otherwise network-reachable, no-auth attack surface.

Sensitive information disclosure in GitLab EE's virtual registries feature allows low-privileged authenticated users to trigger improper forwarding of upstream requests, potentially exposing sensitive data - such as credentials or authentication headers - to unintended hosts. All GitLab EE versions from 18.8 through pre-19.2.1 are affected, with patched releases now available at 19.0.5, 19.1.3, and 19.2.1. No public exploit code has been identified and this vulnerability does not appear in CISA KEV, indicating no confirmed active exploitation at time of analysis.

Server-Side Request Forgery in Gitea's `restore-repo` CLI command allows an attacker who can supply a malicious dump archive to a Gitea administrator to force the server to issue `git fetch` against arbitrary attacker-controlled or internal URLs, including cloud metadata endpoints and local filesystem paths via `file://`. The root cause is a Go language logic defect: `CheckAndEnsureSafePR` is invoked with an empty `commonCloneBaseURL` string, causing `strings.HasPrefix(anything, "")` to always return `true`, which silently disables the URL validation guard for `Head.CloneURL` in the restore path only. A detailed PoC is publicly documented in the GHSA advisory; no CISA KEV listing is present, indicating active exploitation is unconfirmed at time of analysis. Fix is available in Gitea v1.27.0.

Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authenticated user bypass the migration URL allow/block list by supplying a permitted public Git URL that HTTP-redirects the server's git subprocess to an otherwise-blocked internal endpoint. Because Gitea validates only the originally submitted URL while git runs with its default http.followRedirects=initial, the redirected internal Git repository is cloned into an attacker-controlled repository, and pull mirrors keep re-fetching it on schedule. No public exploit identified at time of analysis; a vendor-authored local proof-of-concept confirmed the redirect is followed to 127.0.0.1, and EPSS/KEV data were not supplied.

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.