GitLab Security Advisory: 4 New Vulnerabilities — SSRF, DoS, Email Injection, and Service Desk Impersonation (June 2026)

nick

GitLab Security Advisory: 4 New Vulnerabilities — SSRF, DoS, Email Injection, and Service Desk Impersonation (June 2026)

by

GitLab Security Advisory — June 2026 (Second Release)
4 New CVEs | CVSS Range: 5.3 – 7.5 | All fixed in GitLab 18.10.8, 18.11.5, and 19.0.2
This is the second GitLab security release this period, following the June 11 advisory covering 8 CVEs. The combined total now stands at 12 CVEs for this release cycle.

GitLab has published a supplemental security advisory addressing 4 additional vulnerabilities across its Community Edition (CE) and Enterprise Edition (EE) products. These vulnerabilities span server-side request forgery (SSRF) with arbitrary file read, an unauthenticated denial-of-service vector, email injection via group settings, and a Service Desk email impersonation flaw. All four vulnerabilities are resolved in the same patch versions as the June 11 release: GitLab 18.10.8, 18.11.5, and 19.0.2. Organisations that have already upgraded to these versions are protected. Those still on earlier releases should prioritise upgrading to address all 12 CVEs across both advisories.

CVE-2026-9204 — Gitaly SSRF and Arbitrary File Read (CVSS 5.3)

Severity: Medium (CVSS 5.3)
Component: Gitaly (Git RPC service)
Attack vector: Network, authenticated

A server-side request forgery (SSRF) vulnerability exists in Gitaly that can be triggered during repository import operations. An attacker with the ability to initiate a repository import can cause Gitaly to make requests to internal or external resources, potentially reading arbitrary files from the Gitaly server filesystem. While the CVSS base score is moderate, this vulnerability is particularly concerning in environments where Gitaly runs on a dedicated node with access to internal network segments. Successful exploitation could allow an attacker to pivot from the GitLab application layer into otherwise isolated internal infrastructure.

The SSRF vector arises from insufficient validation of repository URLs and references supplied during import. By crafting a malicious repository reference, an attacker can coerce Gitaly into fetching resources from internal endpoints or reading local files that should not be accessible through the application.

CVE-2026-7250 — Unauthenticated API Denial of Service (CVSS 7.5)

Severity: High (CVSS 7.5)
Component: API request parsing middleware
Attack vector: Network, unauthenticated

A denial-of-service vulnerability exists in GitLab’s API request parsing middleware that can be triggered without authentication. By sending specially crafted requests to the GitLab API, an unauthenticated remote attacker can exhaust server resources, causing significant degradation or complete loss of API availability. This is a high-severity issue because the attack requires no credentials and can be executed against any internet-facing GitLab instance.

The vulnerability resides in the middleware layer that processes incoming API requests before authentication and authorisation checks occur. Malformed or excessively complex request payloads can trigger resource exhaustion in the parsing pipeline, bypassing normal rate limiting and request validation mechanisms. In practical terms, an attacker with network access to a GitLab instance can degrade or disrupt CI/CD pipelines, merge request operations, and all API-driven automation that depends on GitLab availability.

CVE-2026-8589 — Unauthorised Email Injection via Group Settings (CVSS 7.3)

Severity: High (CVSS 7.3)
Component: Group email notification settings
Attack vector: Network, authenticated

An email injection vulnerability exists in GitLab’s group settings that allows an authenticated attacker to inject arbitrary email content into system-generated notification emails. By manipulating group configuration fields that are incorporated into email templates without sufficient sanitisation, an attacker can inject headers, modify email body content, or inject malicious payloads into emails sent to group members.

This vulnerability is particularly dangerous in organisations that use GitLab groups for large-scale collaboration. Injected content could be used to phish group members, impersonate system communications, or distribute malicious links under the guise of legitimate GitLab notifications. Because the emails originate from the genuine GitLab instance’s mail infrastructure and bypass external email security scanners’ reputation checks, recipients are more likely to trust and act upon them.

CVE-2026-9694 — Service Desk Email Impersonation

Severity: Medium
Component: Service Desk email handling
Attack vector: Network, unauthenticated (via email)

A vulnerability in GitLab’s Service Desk feature allows an attacker to impersonate other users when submitting issues via email. The Service Desk functionality, which enables external parties to create issues by sending email to a project-specific address, does not adequately verify the sender’s identity in certain configurations. An attacker can craft emails that appear to originate from a different user, potentially creating issues attributed to an impersonated identity.

While no CVSS score has been published for this CVE at the time of writing, Service Desk impersonation has significant operational security implications. It could be used to inject misleading or malicious issue reports under another person’s identity, compromise incident response workflows that rely on Service Desk triage, or bypass access controls that depend on the submitter’s identity for routing and prioritisation. Organisations using GitLab Service Desk for customer-facing or security-sensitive issue intake should treat this vulnerability seriously.

Affected Versions and Remediation

All four vulnerabilities affect GitLab CE and EE across all supported release tracks prior to the fixed versions. The following releases contain fixes for all 12 CVEs disclosed in this June 2026 release cycle (the 8 from June 11 plus these 4):

  • GitLab 18.10.8 — for installations on the 18.10.x release track
  • GitLab 18.11.5 — for installations on the 18.11.x release track
  • GitLab 19.0.2 — for installations on the 19.0.x release track

Important: If you upgraded to 18.10.8, 18.11.5, or 19.0.2 following the June 11 advisory, you are already protected against these four additional CVEs. No further action is required. GitLab has confirmed that these CVEs were fixed in the same patch releases and are only being disclosed now as part of a coordinated supplemental advisory.

For installations still running versions prior to the fixed releases above, the upgrade addresses all 12 CVEs from this release cycle simultaneously. There are no incremental patches or workarounds that address individual CVEs in isolation. GitLab recommends upgrading to the appropriate patched version for your release track.

To upgrade GitLab:

  1. Review the GitLab upgrade documentation for your installation method (Omnibus, Helm chart, Docker, or source).
  2. Follow the recommended upgrade path for your current version to avoid skipped required intermediate upgrades.
  3. Schedule a maintenance window and perform a full backup before upgrading.
  4. After upgrading, verify the installed version in the Admin Area under Admin > Monitoring > System Info or by checking the Help page.

Context: 12 CVEs This Release Cycle

This supplemental advisory brings the total to 12 CVEs disclosed in GitLab’s June 2026 security release cycle. The June 11 advisory covered the first 8 CVEs, which included a critical authentication bypass (CVE-2026-1234), multiple cross-site scripting (XSS) vulnerabilities, an access control bypass in the GraphQL API, and several moderate-severity issues across pipeline execution and project import functionality. The 4 CVEs in this advisory extend that release with additional vectors across Gitaly, the API layer, group email handling, and Service Desk.

GitLab’s decision to disclose these in two tranches rather than a single advisory is consistent with coordinated disclosure practices where additional CVEs complete their validation and assignment process after the initial publication window. The single set of patch versions covering all 12 CVEs means that organisations with a responsive upgrade cadence are already protected.

Recommendations

  1. Verify your GitLab version immediately. If you are on 18.10.8, 18.11.5, or 19.0.2 (or later), you are protected against all 12 June 2026 CVEs. No further action is needed for these specific vulnerabilities.
  2. Upgrade if not yet on a patched version. The unauthenticated DoS vector (CVE-2026-7250, CVSS 7.5) is the most pressing concern for internet-facing GitLab instances. Even without authentication, an attacker can degrade or deny API access, impacting CI/CD pipelines and developer workflows.
  3. Audit Gitaly network segmentation. CVE-2026-9204’s SSRF and file read capability underscores the importance of network-layer isolation for Gitaly nodes. Ensure Gitaly servers are not routable from the application layer to sensitive internal services, and that Gitaly does not have unnecessary outbound network access.
  4. Review group email settings. After upgrading, audit existing group notification configurations for any injected content that may have been inserted via CVE-2026-8589 prior to patching. Look for unexpected email templates, header modifications, or suspicious URLs in group-level notification settings.
  5. Assess Service Desk usage. If your organisation relies on GitLab Service Desk for issue intake — especially for security-sensitive or customer-facing workflows — review recent Service Desk issues for signs of impersonation via CVE-2026-9694. Pay particular attention to issues attributed to unexpected users or containing anomalous content.
  6. Adopt a proactive upgrade strategy. GitLab releases security patches monthly, typically alongside their regular release cadence (18.10.x, 18.11.x, 19.0.x, etc.). Subscribe to GitLab’s security release mailing list or RSS feed to receive notifications when new advisories are published. Where possible, automate GitLab upgrades in non-production environments and stage production upgrades within 7 days of a security release.
  7. Monitor GitLab API availability. The unauthenticated DoS vulnerability highlights the importance of external monitoring for GitLab API endpoints. Ensure your monitoring stack alerts on elevated error rates, increased response latency, or unusual request patterns at the API layer.

References

Disclaimer: This information is provided for educational and defensive purposes only. CVE descriptions and CVSS scores are based on publicly available information at the time of writing. Always verify details against official NVD listings and the GitLab Security Release page before taking action in production environments.

Threat Modeling and Security by Design

Threat modeling and Security by Design methods, tools, and approaches to help secure your business and IT landscape.

Terms of Service | Privacy Policy

AI chatbot & help center by 99helpers.com

Threat Modeling
Threat Modeling Tool
Threat Modeling Tool Explainer
What is Threat Modeling?
STRIDE Threat Modeling
PASTA Threat Modeling
Automated Threat Modeling
Threat Modeling Framework
CISO Security Mind Map 2026
CIS Controls
OWASP Top 10

© Threat-Modeling.com

Connect with me

Enter your Email address if you want to connect and receive threat modeling updates (I won’t spam you or share your contact details).

AND / OR

Try my threat modeling tool, it's completely free to use.

Thanks for signing up!