GitLab Vulnerability Roundup: Self-Managed Servers Should Be on 19.1.2 or Later

Top/Articles/GitLab Vulnerability Roundup: Self-Managed Servers Should Be on 19.1.2 or Later

NewsPublished June 11, 2026 Updated 2 days ago

Table of contents

Key takeaways

On June 24, 2026, GitLab fixed 14 more vulnerabilities at once, including a flaw that lets a developer run malicious code in another user's screen and one that leaks information from its AI feature. Companies running GitLab on their own servers should update now to the latest releases (19.1.1 / 19.0.3 / 18.11.6). GitLab.com users are already covered.

If you run GitLab on your own servers (self-managed), versions older than 19.1.2 / 19.0.4 / 18.11.7 still contain unfixed vulnerabilities, including flaws that allow account takeover and information leaks. If you are on one of those releases or later, or on 19.2, the latest major version released on July 16, 2026, every vulnerability covered in this article is already closed and no further action is needed. GitLab's own cloud service "GitLab.com" and the managed "GitLab Dedicated" offering are patched as well, so their users have nothing to do.

Across three security releases in under a month, on June 10, June 24, and July 8, 2026, GitLab closed 34 vulnerabilities in total. The heaviest among them are a flaw that lets a group manager take over another member's account (CVE-2026-6552), a flaw that lets a developer-level user run malicious code inside another person's browser session (CVE-2026-10086), and a flaw that lets GitLab's AI feature leak information it should not (CVE-2026-12053). GitLab "strongly recommends that all installations running an affected version are upgraded to the latest version as soon as possible," as its official releases repeat each time.

This article walks through which versions are safe, what each release fixed, and what self-managed installations should check now. Two questions decide everything: is GitLab running on a server your company operates, and how far has its version number climbed?

What the software is, and who it affects

GitLab is the "foundation" of software development: it stores the code engineers write, lets many people edit it together, and automates testing and release into production. Alongside GitHub, it is one of the most common services of its kind, and companies that prefer not to keep code off-premises often run GitLab on their own servers. The source code that is the blueprint of a product, the keys to production servers, and passwords for external services typically all sit in this one place.

These fixes also target those self-hosted installations. GitLab.com is already handled, so only self-built and self-updated setups are affected. Because most companies manage these updates through an IT or infrastructure team, the first step is to confirm who is responsible for updating your GitLab.

How you use it	Impact	Action needed
On your own server (self-managed)	Affected	Check your version and update to a fixed release
GitLab.com (cloud)	Already patched	None
GitLab Dedicated (managed)	Already patched	None

The newest fixes: 8 flaws closed in 19.1.2 / 19.0.4 / 18.11.7 (July 8, 2026)

As of July 23, 2026, the most recent security release is 19.1.2 / 19.0.4 / 18.11.7, published on July 8, 2026, which closed 8 additional vulnerabilities. Even installations that applied both June rounds (14 and 12 fixes) do not have these 8, so environments updated at the end of June are affected too.

CVE-2026-6896: malicious code via the vulnerability evidence screen

The most serious of the 8. A security feature in the paid EE that lists evidence for detected vulnerabilities failed to check the text fed into its table. This is "cross-site scripting" (XSS), the technique of planting malicious code into a display screen: when another user opens crafted content, the attacker's code runs in their browser. Its CVSS score is 8.7, matching the analytics-screen flaw fixed in June (CVE-2026-10086). It affects EE from 13.11 onward, an unusually wide range.

CVE-2026-13320: injecting rogue content into Wiki pages

The Wiki feature, which hosts a project's documentation pages, allowed HTML (the markup that builds what a page displays) to be injected improperly. The CVSS is 7.3, and both the free CE and paid EE are affected. The remaining 6 issues are of medium to low severity; the full list is in the official release.

The 14 flaws fixed in 19.1.1 / 19.0.3 / 18.11.6 (June 24, 2026)

Two weeks before that, the June 24, 2026 release closed 14 issues. Here are the most severe by their "CVSS" score (an international standard that rates a vulnerability's danger from 0 to 10). A higher number simply means greater risk. We also note whether each affects CE (the free Community Edition), EE (the paid Enterprise Edition), or both.

ID	What it is	What happens	Role required	Edition	Risk
CVE-2026-10086	Missing input check in analytics screen	Malicious code runs in a target's screen	Developer + target action	EE	8.7
CVE-2026-10712	Asset handling flaw in Web IDE	Code runs in the screen of who opens it	None + target action	CE/EE	8.0
CVE-2026-12053	Insufficient filtering in AI feature output	Disclosure of info that should be hidden	Sources disagree	EE	7.7-8.6
CVE-2026-12635	Destination flaw in repo mirroring	Unauthorized access to internal network	Maintainer	CE/EE	3.1

In addition to the above, 14 issues in total were fixed at once, including several smaller authorization problems. A month after publication, as of July 23, 2026, there are no reports of any vulnerability in this article being used in real attacks, and none appear on the U.S. government's Known Exploited Vulnerabilities (KEV) catalog. Most were reported by researchers through GitLab's bug bounty program. Still, once a fix ships, the location of the hole generally becomes public, so the standard move is to update before attackers finish their analysis.

A closer look at the three heaviest June 24 flaws

CVE-2026-10086: malicious code via the analytics screen

This is the highest-risk issue among the 14. GitLab's analytics dashboard (the screen that shows project status as charts) failed to properly check the text fed into it, another classic XSS. A user with Developer permissions embeds a malicious trap, and when another user opens that screen, the attacker's code runs in their browser. Depending on what is planted, it can lead to session hijacking and ultimately account takeover. The CVSS is 8.7, affecting EE from 16.4 up to 19.1.0 (excluding interim fixes). It was reported by researcher yvvdwf.

The June 10 patch had just fixed a very similar hole in the same analytics screen (CVE-2026-10087). One number apart, it means the same kind of missing check lingered at another entry point of the screen. Developer permissions are held by relatively many people inside a company, so the wide reach makes internal traps a real concern.

CVE-2026-10712: abusing file handling in the code editor

The second issue is also an XSS, but the stage is the "Web IDE," GitLab's in-browser code editor. A flaw in how this editor handles files (assets) means that getting someone to open crafted content runs the attacker's code in their screen. The CVSS is 8.0, it affects both the free CE and paid EE, and the range is 18.10 up to 19.1.0. It was reported by researcher joaxcar.

This flaw is rated as requiring no login of its own, but exploitation still depends on a target opening a prepared location. It is not a one-sided break-in, yet in collaborative development people routinely open branches and files prepared by others, so it cannot be dismissed. Teams running the free edition internally are affected too.

CVE-2026-12053: information leaking from the AI feature

The third issue is an information disclosure tied to GitLab's AI assistant feature, "Duo Workflows." Because the AI's output was not filtered thoroughly enough, under certain conditions a user may be able to pull out sensitive information they should not see. It affects the paid EE, specifically 19.1.0. It was reported by GitLab team members (3nvz and Dennis Appelt). It is one example of how, as AI assistance moves deeper into development, deciding "how much of the output may be shown" becomes a new weak point.

Note that the severity rating for this one differs by source. We cover that in the next box.

? Worth confirming (sources rate it differently)

?The severity of CVE-2026-12053 differs between sources: the U.S. NVD rates it 8.6, while GitLab itself rates it 7.7. The gap comes mainly from whether the attack needs a login: NVD leans toward "no," GitLab toward "yes." We present both. Either way, it is fixed in 19.1.1 and later.
?Per GitLab's practice, detailed write-ups of each CVE (such as reproduction conditions) are disclosed on the issue tracker about 30 days after release. For the June 24 batch, that window arrives in late July 2026, so deeper technical detail becomes readable over time.

Who targets these flaws, and why

When you hear "GitLab vulnerability," the first image may be an anonymous hacker forcing their way in from outside. But most of the serious holes in this series start with someone who already has an account on your company's GitLab, and who has been granted a degree of permission as a developer or a manager. That is exactly why no amount of outward-facing wall fully stops this class of flaw.

Realistic actors include an engineer unhappy with their treatment before resigning, a contract developer near the end of their term, a partner brought into a shared project, or an outsider who slipped in by stealing one set of login credentials through phishing. What they want is the source code that is the product's blueprint, the keys to enter production servers, passwords for external services and cloud, customer lists, and the contents of unreleased features. By planting a single trap in the analytics or code-editing screen and getting another user to open it, they can hijack that person's session and pull out everything that person is allowed to see.

What makes it frightening is that GitLab is not just a warehouse; it holds the "pipeline" that automatically tests code and ships it to production. If an attacker pulls a production deployment key from a hijacked account, the damage does not stay within one company. A path opens for poisoned programs to flow on to other products and services that consume that code, reaching partners and end users (a supply-chain attack). In practice, intrusions that use a development platform as a foothold typically lurk quietly inside, scout repeatedly, and move laterally toward the real target.

A CVSS number is only a gauge of technical severity. What a development team truly loses is the source code it built over years and the trust that protected it. If the blueprint and the keys are taken at the same time, recovery is no longer "change the password" but checking line by line what was seen and what was altered. Because the attack begins with one insider who holds permissions, a delayed update is itself the entry point for damage.

The 12 flaws fixed in 19.0.2 / 18.11.5 / 18.10.8 (June 10, 2026)

Going further back, on June 10, 2026 GitLab also fixed 12 vulnerabilities at once. If you have already moved to 19.1.2 or another current fixed release, every round is covered, but installations that went a while without updating may still be exposed to this batch as well. The most serious three in that release (fixed in 19.0.2 / 18.11.5 / 18.10.8) were the following.

ID	What it is	What happens	Role required	Edition	Risk
CVE-2026-6552	Permission flaw in external login link	Takeover of another member's account	Group Owner	EE	8.7
CVE-2026-10087	Missing input check in analytics screen	Malicious code runs in a target's screen	Developer + target action	EE	8.7
CVE-2026-7250	Data-parsing flaw in the API	Service taken offline with no login	None (unauthenticated)	CE/EE	7.5

CVE-2026-6552: taking over another member's account

This was the issue to watch most closely in that release. GitLab has a feature that links a company's shared login system (SAML, single sign-on) to each member's account. A flaw in the permission check for managing that link let a person with the Group Owner role take over another member's account in the same group. No password was needed. The CVSS is 8.7, affecting EE from 15.5 up to 19.0.1. It was reported by security researcher cyberjoker. Impersonating the victim allows access to code in other groups only they could reach, and even commits under their name (forged tampering).

CVE-2026-10087: malicious code via the analytics screen

GitLab's analytics dashboard had a missing input check (XSS). A user with Developer permissions embeds a malicious trap, and when another user opens it, the attacker's code runs in their browser. The CVSS is 8.7, affecting EE from 17.1 up to 19.0.1. It was reported by yvvdwf. It is the sibling, one number apart, of CVE-2026-10086 fixed on June 24, showing that several similar entry points existed.

CVE-2026-7250: knocking the service offline without a login

This one is not about stealing data but about taking the service down (denial of service, DoS). A flaw in how GitLab's API (the window that exchanges data with external programs) handles incoming data means that simply sending crafted data can overload and stop GitLab. It can be done by someone not logged in, and the free CE is affected too. The CVSS is 7.5, the range is very wide at 12.10 up to 19.0.1, and it was reported by svalkanov.

Does your GitLab need updating? (version quick-reference)

You can check your current version in GitLab's admin area, on the /help page, or with the gitlab-rake gitlab:env:info command. Match your number in the table below. As of July 23, 2026, the fixed releases are 19.1.2 / 19.0.4 / 18.11.7; moving to one of these applies all three rounds (June 10, June 24, and July 8) at once. A new major version, 19.2, also shipped on July 16, 2026, and jumping to it is another option since 19.2 includes every fix in this article.

Version you run	Status	Upgrade to	Priority
19.2.0 or later	All flaws in this article fixed	None	—
19.1.0 - 19.1.1	Affected	19.1.2	High
19.0.0 - 19.0.3	Affected	19.0.4	High
18.11.0 - 18.11.6	Affected	18.11.7	High
12.10 - 18.10	Some flaws apply (check individually)	Step up to a supported release	High
GitLab.com / Dedicated	Already patched	None	—

The update itself follows GitLab's official upgrade procedure. Large jumps may need to pass through intermediate versions, so the older your number, the more planning it takes. If you cannot upgrade the core right away, and your GitLab is internet-facing, a practical stopgap is to restrict where access comes from and to tighten monitoring.

Technically, why self-managed installs get targeted

The cloud GitLab.com is kept on the latest version automatically by GitLab. By contrast, installations on your own servers leave the responsibility to update with the operating company. A time lag forms here, and "the fix exists, but our GitLab is still old" is a state that often lingers. When fixes arrive at short intervals, as they did in June and July 2026, update work can fall behind and pile up unaddressed. Even after attackers analyze the fix and pinpoint the hole, unpatched installs remain all over the world.

A development platform is a "vault" where source code and production keys gather in one place, and in recent years it has repeatedly been targeted as an entry point for intrusions. Using Git or CI/CD (automated testing and release) as a foothold to spread poison to dependent software is of a piece with the problem of programs running on their own at package install time. The mindset of continuously checking where development components come from and what they execute rests on the same concern as efforts to watch the safety of software pulled in from outside.

It also matters that many of these holes start from "a logged-in internal user." A defense that relies on the perimeter wall (firewall) alone is powerless against someone with a legitimate account, or against one hijacked account. Reviewing who holds which permissions, and whether the count of developers and owners has grown too large, is the realistic preparation for flaws like these.

What to do now

If you run GitLab on your own servers, first check your version, and if it is older than 19.1.2 / 19.0.4 / 18.11.7, update to one of those (or to the latest 19.2). This is the only root fix, and moving here applies all 34 fixes from the June and July 2026 rounds together. Users of GitLab.com or GitLab Dedicated need do nothing, as the fix is already applied.

If upgrading the core will take time, run stopgaps in parallel: restrict access to an internet-facing GitLab to your internal network or VPN, review the number of developers and owners down to the minimum necessary, and tighten monitoring for suspicious logins and setting changes. No real attacks had been confirmed as of July 23, 2026, but once a fix is public the location of the hole is easier to find, so deferring the update is itself an accumulation of risk. GitLab will keep shipping security fixes on a regular rhythm, so subscribing to its official patch announcements and setting aside one update day a month keeps the next round from catching you off guard.