GitLab Fixes High-Severity XSS And Unauthenticated DoS Vulnerabilities

GitLab has released security updates for several vulnerabilities that can expose self-managed GitLab instances to cross-site scripting, denial-of-service attacks, access control problems, and other security risks.

The fixes arrived in GitLab Community Edition and Enterprise Edition versions 18.11.3, 18.10.6, and 18.9.7. GitLab strongly recommends that all affected self-managed installations upgrade to one of these versions as soon as possible.

GitLab.com already runs the patched version, and GitLab Dedicated customers do not need to take action. The main exposure applies to self-managed GitLab CE and EE instances that still run affected versions.

What GitLab fixed in the latest patch release

The May 13, 2026 patch release addresses a broad set of vulnerabilities across GitLab CE and EE. The highest-severity issues include multiple XSS flaws and unauthenticated DoS bugs.

The XSS vulnerabilities could allow an authenticated attacker to execute JavaScript in another user’s browser if the victim views affected content. These bugs can create serious risk because GitLab often handles source code, merge requests, analytics dashboards, project metadata, and developer workflows.

The DoS vulnerabilities are also important because some of them do not require authentication. A remote attacker could send specially crafted requests or JSON payloads to affected endpoints and disrupt availability.

Category	Main risk	Who should act
XSS vulnerabilities	Malicious JavaScript execution in another user’s browser	Self-managed GitLab CE and EE administrators
Unauthenticated DoS vulnerabilities	Service disruption through crafted requests or payloads	Self-managed GitLab CE and EE administrators
Authorization and access control issues	Unauthorized actions or access in specific features	Teams using affected features and integrations
GitLab.com	Already patched by GitLab	No user action required
GitLab Dedicated	Managed by GitLab	No customer action required

The most serious XSS vulnerabilities

GitLab fixed several high-severity XSS vulnerabilities in this release. The most serious entries carry CVSS scores of 8.7.

CVE-2026-7481 affects GitLab EE analytics dashboard chart rendering. GitLab says an authenticated user with developer-role permissions could execute arbitrary JavaScript in other users’ browsers because of improper input sanitization.

CVE-2026-5297 affects global search in GitLab CE and EE. GitLab says an authenticated user could execute arbitrary JavaScript in other users’ browsers through another input sanitization issue.

CVE-2026-6073 affects Duo Agent output rendering in GitLab EE. This flaw could also let an authenticated user run JavaScript in another user’s browser.

CVE	Issue	Affected product	CVSS
CVE-2026-7481	XSS in analytics dashboard chart rendering	GitLab EE	8.7
CVE-2026-5297	XSS in global search	GitLab CE/EE	8.7
CVE-2026-6073	XSS in Duo Agent output rendering	GitLab EE	8.7
CVE-2026-7377	XSS in customizable analytics dashboards	GitLab EE	8.7

Why the XSS bugs matter

Cross-site scripting matters in GitLab because developers and administrators often work inside trusted project areas. If malicious JavaScript runs in a victim’s browser, it may perform actions in that user’s session context.

An attacker still needs the conditions described in each advisory. For example, several XSS flaws require an authenticated user and user interaction. That lowers the attack path compared with unauthenticated remote code execution, but it does not make the bugs minor.

In a development platform, browser-session compromise can affect code review, project settings, repository activity, and internal workflows. That makes fast patching important for any instance with many users or exposed collaboration features.

Unauthenticated DoS vulnerabilities also received fixes

GitLab also fixed multiple denial-of-service issues that could allow unauthenticated attackers to disrupt affected self-managed instances.

CVE-2026-1659 affects the CI/CD job update API. GitLab says an unauthenticated user could cause denial of service by sending specially crafted requests due to insufficient input validation.

CVE-2025-14870 affects the Duo Workflows API. GitLab says an unauthenticated user could cause denial of service by sending specially crafted JSON payloads. CVE-2025-14869 affects certain internal API endpoints and can also be triggered without authentication.

CVE	Issue	Affected product	CVSS
CVE-2026-1659	DoS in CI/CD job update API	GitLab CE/EE	7.5
CVE-2025-14870	DoS in Duo Workflows API	GitLab CE/EE	7.5
CVE-2025-14869	DoS in internal API endpoints	GitLab CE/EE	7.5
CVE-2026-1184	DoS in Insights Configuration	GitLab EE	6.5
CVE-2026-8280	DoS in direct transfer CSV parser	GitLab CE/EE	6.5

Affected GitLab versions

The affected version ranges differ by CVE, but the upgrade target stays the same. Administrators should move to GitLab 18.11.3, 18.10.6, or 18.9.7, depending on their supported release track.

For example, CVE-2026-7481 affects GitLab EE versions from 16.4 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3.

CVE-2026-5297 affects GitLab CE and EE versions from 15.11 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3. CVE-2026-1659 affects GitLab CE and EE versions from 9.0 before the fixed releases.

• Upgrade GitLab 18.11 installations to 18.11.3 or later.
• Upgrade GitLab 18.10 installations to 18.10.6 or later.
• Upgrade GitLab 18.9 installations to 18.9.7 or later.
• Review each CVE if your instance runs an older supported version.
• Prioritize internet-facing self-managed instances.

Access control and authorization issues were also patched

The release also includes fixes for several access control and authorization bugs. These issues carry medium or low severity ratings, but they still matter in environments with sensitive repositories, protected packages, or strict approval rules.

CVE-2026-1322 affects GraphQL token scope enforcement. GitLab says an authenticated user with a read_api scoped OAuth application could create issues and comments in private projects because of improper authorization.

Other fixes address confidential issue exposure, Helm package upload controls, PyPI package protection rules, code owner approval rules, and group member enumeration.

CVE	Issue	Severity
CVE-2026-1322	Improper authorization in GraphQL token scope enforcement	Medium
CVE-2026-4524	Access control issue in Issues API	Medium
CVE-2026-3607	Access control issue in Helm package upload	Medium
CVE-2026-3073	Access control issue in PyPI Package Protection Rules	Medium
CVE-2026-6063	Improper access control in code owner approval rules	Medium

Upgrade planning and downtime

GitLab says this patch includes database migrations that may affect the upgrade process. Single-node instances will experience downtime because migrations must finish before GitLab can start again.

Multi-node instances can apply the patch without downtime if administrators follow GitLab’s zero-downtime upgrade procedures. This makes planning important for larger environments that run GitLab as a central development platform.

The release also includes post-deploy migrations for version 18.9.7. Administrators should review upgrade documentation before starting maintenance, especially on larger installations with many projects and CI/CD workloads.

Recommended actions for administrators

Self-managed GitLab administrators should treat this as a high-priority security update. The combination of XSS, unauthenticated DoS, and access control issues creates risk across development, CI/CD, analytics, and collaboration workflows.

Teams should first identify the installed GitLab version, choose the correct fixed release, and schedule the update. Internet-facing instances and instances used by many developers should move first.

After upgrading, administrators should confirm the running version, check that background migrations complete, and review logs for unusual activity linked to affected endpoints or features.

1. Check the current GitLab CE or EE version.
2. Upgrade to 18.11.3, 18.10.6, or 18.9.7.
3. Plan downtime if the instance runs as a single-node deployment.
4. Use zero-downtime upgrade procedures for multi-node environments where possible.
5. Confirm the new version after the update finishes.
6. Monitor database and post-deploy migrations.
7. Review access logs, API logs, and error logs for suspicious activity.
8. Check GitLab Duo, analytics dashboards, CI/CD APIs, and integrations if your environment uses them.

Why this update matters for DevOps teams

GitLab often sits at the center of software delivery. It stores source code, manages CI/CD pipelines, handles merge requests, connects to package registries, and integrates with external tools.

That makes vulnerabilities in GitLab more important than ordinary application bugs. A disruption in GitLab can slow development, block deployments, or affect security workflows used by multiple teams.

The latest patch release does not mean every GitLab instance faced the same level of risk. Still, any self-managed instance running an affected version should upgrade quickly because attackers often scan for unpatched development platforms after public advisories appear.

FAQ