GitLab Patches Eight Security Vulnerabilities in Community and Enterprise Editions

GitLab has released new security updates for GitLab Community Edition and Enterprise Edition, fixing eight vulnerabilities across the platform.

The patched versions are 19.1.2, 19.0.4, and 18.11.7. GitLab said in its official patch release that all self-managed installations running affected versions should upgrade as soon as possible.

The update matters most for self-managed GitLab administrators. GitLab.com already runs the patched release, while GitLab Dedicated customers do not need to take action for this advisory.

What GitLab fixed

The July 8, 2026 release fixes two high-severity vulnerabilities, three medium-severity vulnerabilities, and three low-severity vulnerabilities.

The issues affect several GitLab features, including vulnerability evidence rendering, wiki markup, repository mirroring, work items, commit discussion display, Git references, group-level settings, and compliance violation management.

The Canadian Centre for Cyber Security also published a GitLab security advisory urging users and administrators to review the vendor guidance and apply the necessary updates.

CVE	Severity	Affected editions	Issue type
CVE-2026-6896	High	GitLab EE	Cross-site scripting in vulnerability evidence table renderer
CVE-2026-13320	High	GitLab CE/EE	HTML injection in wiki markup rendering
CVE-2026-11827	Medium	GitLab EE	Insufficiently protected credentials in repository mirroring
CVE-2026-8472	Medium	GitLab EE	Improper access control in work items
CVE-2026-7492	Medium	GitLab CE/EE	Missing authorization in commit discussion display
CVE-2025-12506	Low	GitLab CE/EE	Ambiguous Git reference handling
CVE-2026-13151	Low	GitLab EE	Incorrect authorization in group-level settings
CVE-2026-6352	Low	GitLab EE	Incorrect authorization in compliance violation management

The most serious issue is an XSS flaw in GitLab EE

The highest-scored vulnerability is CVE-2026-6896, a cross-site scripting issue in the vulnerability evidence table renderer.

GitLab says the issue could allow an authenticated user with Developer-role permissions to execute arbitrary scripts in another user’s browser session under certain conditions.

The vulnerability affects GitLab EE versions from 13.11 before 18.11.7, 19.0 before 19.0.4, and 19.1 before 19.1.2. GitLab assigned it a CVSS score of 8.7.

Wiki markup rendering also received a high-severity fix

The second high-severity issue is CVE-2026-13320, which affects GitLab CE and EE.

The flaw involves improper sanitization of user-supplied input in wiki markup rendering. The NVD entry for CVE-2026-13320 says exploitation could allow an authenticated user to execute arbitrary scripts in another user’s browser session under certain conditions.

GitLab lists the affected versions as all CE and EE versions from 15.7 before 18.11.7, 19.0 before 19.0.4, and 19.1 before 19.1.2.

• The attack requires an authenticated user.
• The CVSS vector includes high attack complexity.
• The attack requires user interaction.
• The issue has changed scope because it affects another user’s browser session.
• The fixed versions are 18.11.7, 19.0.4, and 19.1.2.

Medium-severity fixes cover credentials and private project metadata

CVE-2026-11827 affects repository mirroring in GitLab EE. GitLab says an authenticated user with Maintainer-role permissions could obtain another user’s stored credentials due to improper authorization controls.

CVE-2026-8472 affects work items in GitLab EE. Under certain conditions, a user with minimal access permissions could read work item metadata from private projects.

CVE-2026-7492 affects GitLab CE and EE. The NVD record for CVE-2026-7492 says the issue could allow an unauthenticated user to determine whether a private project exists because of improper authorization controls on cross-project reference pages.

Vulnerability	Risk	Why administrators should care
CVE-2026-11827	Credential exposure	Repository mirroring can involve stored credentials that need strict access control
CVE-2026-8472	Private metadata exposure	Work item metadata can reveal sensitive project context
CVE-2026-7492	Private project discovery	Attackers can use project existence leaks during reconnaissance

Low-severity bugs still matter for shared development platforms

GitLab also fixed three low-severity issues. These flaws do not carry the same urgency as the XSS and credential-related vulnerabilities, but they still affect trust and authorization boundaries.

CVE-2025-12506 could allow an authenticated user to create a repository where content shown in the web interface differs from content available for download because of Git reference name resolution behavior.

CVE-2026-13151 affects group-level settings in GitLab EE, while CVE-2026-6352 affects compliance violation management in GitLab EE. Both involve authorization checks that could allow actions beyond intended permissions under specific conditions.

Who needs to upgrade

Self-managed GitLab administrators should upgrade to one of the fixed versions: 19.1.2, 19.0.4, or 18.11.7.

The Canadian Cyber Centre advisory lists GitLab CE and GitLab EE versions prior to 19.1.2, 19.0.4, and 18.11.7 as affected by the July 8 security advisory.

Administrators should choose the fixed patch version that matches their supported branch. Teams running older or unsupported releases should plan an upgrade path instead of jumping blindly to the newest release.

Current branch	Patched version	Recommended action
19.1.x	19.1.2	Upgrade to the latest 19.1 patch release
19.0.x	19.0.4	Upgrade to the latest 19.0 patch release
18.11.x	18.11.7	Upgrade to the latest 18.11 patch release
Older supported branch	Depends on upgrade path	Review required upgrade stops before moving forward
Unsupported branch	Supported release required	Create an upgrade plan and test before production rollout

Upgrade notes for administrators

The release includes database migrations. GitLab says the patch can cause downtime on single-node instances because migrations must complete before GitLab can start.

Multi-node deployments can reduce disruption by using GitLab’s zero-downtime upgrade process, which upgrades nodes in sequence while load balancers and high-availability components keep service available.

Administrators should also use the GitLab upgrade documentation to plan the update, check backup requirements, review release notes, and confirm installation-specific steps.

1. Identify the current GitLab version and edition.
2. Check whether the instance runs GitLab CE or GitLab EE.
3. Back up the instance before starting the upgrade.
4. Review database migration notes for the target version.
5. Schedule downtime for single-node instances if needed.
6. Use zero-downtime procedures for supported multi-node environments.
7. Upgrade GitLab Runner where your deployment process requires version alignment.
8. Confirm the web interface reports 19.1.2, 19.0.4, or 18.11.7 after the update.

Why self-managed GitLab instances face more exposure

GitLab.com customers already run the patched version, so the main exposure sits with self-managed instances that administrators have not updated yet.

Self-managed GitLab servers often hold source code, CI/CD secrets, deployment pipelines, issue history, private project names, security scan results, and compliance data. That makes even medium-severity authorization and metadata leaks important in enterprise environments.

The risk grows when GitLab sits on the internet, accepts many contributors, or supports shared projects across business units. Attackers can use lower-severity issues to support reconnaissance, then combine them with stolen accounts or social engineering.

What security teams should prioritize

Security teams should first patch public-facing GitLab instances and deployments with many external or semi-trusted users.

They should then review logs for suspicious behavior around vulnerability evidence pages, wiki pages, repository mirrors, commit discussion references, group settings, compliance violation records, and work item metadata.

The GitLab patch notes also state that detailed vulnerability issues become public in the GitLab issue tracker 90 days after the release, which gives defenders a limited window before more technical details may become easier to find.

• Prioritize internet-facing GitLab instances.
• Patch environments with external contributors or large developer populations first.
• Review users with Developer, Maintainer, Auditor, and group-level administrative permissions.
• Audit repository mirror credentials and rotate them if exposure looks possible.
• Monitor private project references and unexpected work item metadata access.
• Review compliance and group setting changes after the upgrade.
• Watch for unusual wiki edits or vulnerability evidence content that could indicate XSS testing.

Recommended response after patching

After installing the update, administrators should verify background migrations, check service health, and confirm that GitLab Runner, Sidekiq, Puma, Gitaly, Redis, and PostgreSQL operate normally.

They should also review recent changes to sensitive settings and stored credentials. The medium-severity repository mirroring issue makes credential review important for GitLab EE environments that use mirrors.

For large deployments, the multi-node zero-downtime guide and the broader GitLab update guide can help teams reduce outage risk while still moving quickly on the security release.

The bottom line

GitLab’s July 2026 patch release fixes eight vulnerabilities across CE and EE, including two high-severity script injection issues and several authorization or metadata exposure flaws.

The release does not list a critical-severity bug, but administrators should still move quickly. GitLab instances often sit at the center of source code, CI/CD, security scanning, and deployment workflows.

Self-managed GitLab users should update to 19.1.2, 19.0.4, or 18.11.7, then review high-risk roles, mirror credentials, private project exposure, and recent changes to compliance or group settings.

The CVE-2026-13320 advisory and the CVE-2026-7492 advisory show why the release deserves attention: even flaws that require certain permissions or conditions can create serious risk on collaborative development platforms.

FAQ