July 2, 2026

CVE-2026–10086: Cross-Site Scripting in GitLab EE Analytics Dashboard

When developer permissions become enough to attack another user’s session

By CyberPodcast

6 min read

When developer permissions become enough to attack another user's session

GitLab is one of the most widely used platforms for software development, CI/CD automation, source code management, DevSecOps workflows, and team collaboration.

Because of this, vulnerabilities affecting GitLab are rarely isolated to a single feature. A weakness in one dashboard, workflow, or project component can become security-relevant because GitLab is where developers, maintainers, security teams, and administrators manage code, secrets, pipelines, issues, merge requests, releases, and deployment processes.

CVE-2026–10086 is a Cross-Site Scripting vulnerability affecting GitLab Enterprise Edition. The issue was remediated in GitLab EE versions 18.11.6, 19.0.3, and 19.1.1.

The vulnerability affects the Analytics Dashboard and, under certain conditions, could allow an authenticated user with Developer-role permissions to execute arbitrary client-side code in the context of another user's session.

This is important because the attacker does not need administrator privileges. A lower-privileged authenticated user can potentially influence content that is later rendered in another user's browser.

Vulnerability summary

CVE: CVE-2026–10086 Product: GitLab Enterprise Edition Affected component: Analytics Dashboard Vulnerability type: Cross-Site Scripting CWE: CWE-79 — Improper Neutralization of Input During Web Page Generation Affected versions:

  • GitLab EE from 16.4 before 18.11.6
  • GitLab EE 19.0 before 19.0.3
  • GitLab EE 19.1 before 19.1.1

Fixed versions:

  • 18.11.6
  • 19.0.3
  • 19.1.1

GitLab CNA CVSS 3.1: 8.7 HIGH Vector: AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N

NVD also lists a separate NIST assessment of 5.4 MEDIUM, with lower confidentiality and integrity impact. This difference is worth noting because the vendor assessment considers the issue High, while NVD's own enrichment gives it a Medium score.

What happened?

The root cause is improper sanitization of user-supplied input.

In a secure web application, user-controlled data must not be trusted when it is later rendered into HTML, JavaScript, attributes, URLs, markdown previews, dashboards, widgets, or any other browser-executed context.

CVE-2026–10086 appears in the Analytics Dashboard area of GitLab EE. Under specific conditions, an authenticated user with Developer permissions could provide input that is later rendered in a way that allows arbitrary client-side JavaScript execution in another user's session.

In simple terms:

  1. An authenticated Developer-level user controls or influences some input.
  2. That input reaches the Analytics Dashboard.
  3. The input is not sanitized or neutralized correctly.
  4. Another user views the affected dashboard.
  5. JavaScript executes in that user's browser session.

This is a Cross-Site Scripting issue, but not the trivial kind. The interesting part is the permission model: the attacker is authenticated, but does not need high-level administrative access.

Why this matters in GitLab

A Cross-Site Scripting vulnerability inside GitLab can be more dangerous than a normal XSS in a generic web page.

GitLab is not just a content management system or a static dashboard. It is a development and operations platform. Users interact with repositories, merge requests, CI/CD pipelines, project settings, security dashboards, package registries, deployment environments, access tokens, and sensitive project metadata.

If JavaScript executes inside another user's GitLab session, the impact depends heavily on the victim's privileges and the available browser-side actions.

A successful attack could potentially affect:

  • confidentiality of project data;
  • integrity of user-visible project content;
  • authenticated actions performed through the victim's browser;
  • access to sensitive information visible to the victim;
  • project or group workflows;
  • trust relationships inside the development platform.

The vulnerability requires user interaction because another user must visit the affected page. However, in collaborative platforms like GitLab, this condition is not unrealistic. Dashboards are meant to be viewed by teams.

That is what makes this class of bug dangerous: the malicious input can wait inside a legitimate workflow until a more privileged or more trusted user opens the affected interface.

Developer role does not mean harmless

A key detail of CVE-2026–10086 is that the attacker needs Developer-role permissions.

At first, this may sound like a strong limitation. In reality, Developer access is common in GitLab projects. Many teams assign Developer permissions to contributors who need to push code, interact with merge requests, run pipelines, or collaborate on project features.

A Developer is not supposed to be able to execute JavaScript in another user's browser session.

This is where the vulnerability breaks the expected boundary. GitLab's permission model allows Developers to contribute to a project, but it should not allow them to affect the browser execution context of other users.

When an XSS crosses that boundary, the role becomes a stepping stone.

The attacker may start with legitimate project access and then attempt to influence users with broader permissions, such as Maintainers, Owners, security engineers, or administrators.

Scope change and why CVSS is high

The GitLab CVSS vector includes S:C, which means "Scope: Changed."

This is important.

In CVSS terminology, scope changes when exploiting a vulnerability in one security authority can affect a different security authority or context. For XSS, this often reflects the fact that the vulnerable application allows attacker-controlled script execution inside another user's browser session.

The GitLab CNA score is 8.7 HIGH, with high impact on confidentiality and integrity, but no direct availability impact.

That assessment makes sense for this kind of vulnerability:

  • the attacker may not crash the system;
  • the attacker may not directly take the server offline;
  • but the attacker may execute code in another user's session;
  • and that can expose or modify sensitive information depending on the victim's privileges.

NVD's own enrichment gives the issue a lower 5.4 MEDIUM score. This kind of difference is not unusual when different parties interpret the practical impact differently. For defenders, the safer position is to follow the vendor's remediation guidance and treat the issue as high priority.

Root cause: improper sanitization

The vulnerability is mapped to CWE-79, which is the classic weakness category for Cross-Site Scripting.

The underlying problem is improper neutralization of input during web page generation.

This usually happens when user-controlled data is inserted into a page without the correct context-aware handling.

For example, a value may be safe in one context but dangerous in another:

  • safe as plain text, dangerous inside HTML;
  • safe as text, dangerous inside an attribute;
  • safe in markdown, dangerous after markdown rendering;
  • safe in a JSON structure, dangerous if embedded into a script block;
  • safe in backend storage, dangerous when displayed in a dashboard.

Modern applications often transform the same value multiple times before it reaches the browser. That makes XSS prevention more difficult, because developers must consider the final rendering context, not only the original input source.

For GitLab's Analytics Dashboard, the lesson is clear: dashboard data is still untrusted data if any part of it can be influenced by users.

Why dashboards are a common XSS surface

Dashboards often combine different types of data:

  • user-generated labels;
  • project names;
  • issue titles;
  • merge request metadata;
  • chart labels;
  • descriptions;
  • filters;
  • analytics widgets;
  • custom fields;
  • saved views;
  • URLs;
  • imported or generated content.

This makes dashboards complex from a security perspective. They are visual components, but they are also data aggregation surfaces.

The risk increases when dashboards are shared across roles. A Developer may create or influence data that is later viewed by a Maintainer, security engineer, project Owner, or administrator.

That is the core danger: the attacker controls the input, but the victim owns the session where the script executes.

Impact scenarios

The exact exploitation details are not necessary to understand the risk.

At a high level, a successful XSS in GitLab could allow an attacker to perform actions in the victim's browser context. Depending on the victim's permissions and GitLab's protections, this may lead to:

  • reading data visible to the victim;
  • modifying project-visible content;
  • interacting with authenticated endpoints;
  • abusing UI workflows;
  • changing dashboard or project-related settings;
  • targeting maintainers or owners through normal collaboration flows;
  • pivoting from project-level access toward more sensitive areas.

The most serious scenario involves a lower-privileged user targeting a higher-privileged user who views the affected Analytics Dashboard.

This is why XSS in developer platforms must be treated seriously. The browser is not just rendering content; it is connected to an authenticated workflow with real permissions.

Remediation

Administrators of self-managed GitLab instances should upgrade to one of the patched versions:

  • GitLab EE 18.11.6
  • GitLab EE 19.0.3
  • GitLab EE 19.1.1

GitLab stated that GitLab.com was already running the patched version at the time of the advisory. GitLab Dedicated customers did not need to take action according to the vendor advisory.

For self-managed environments, the recommended action is to upgrade affected installations as soon as possible.

Security teams should also consider:

  • reviewing GitLab version exposure;
  • identifying instances running affected EE versions;
  • prioritizing internet-facing or widely used internal GitLab deployments;
  • monitoring for suspicious activity around Analytics Dashboard usage;
  • reviewing recent changes made by lower-privileged project users if exploitation is suspected;
  • ensuring least-privilege access to sensitive projects.

Defensive lessons

CVE-2026–10086 reinforces several important security lessons.

First, authenticated does not mean safe. Many severe vulnerabilities require authentication, especially in collaboration platforms.

Second, Developer-level access is still a meaningful attack position. In GitLab, Developers often have enough interaction capability to influence project data and workflows.

Third, dashboards are not passive views. They are rendering surfaces. If they display user-influenced content, they must apply strict sanitization and escaping.

Fourth, XSS is not only about stealing cookies. In modern applications, the real impact often comes from executing actions inside a trusted session.

Finally, security controls must be context-aware. Sanitizing input at storage time is useful, but it does not replace proper output encoding at render time.

Final thoughts

CVE-2026–10086 is not just another XSS entry in a vulnerability database. It is a reminder that collaborative development platforms have complex trust boundaries.

A Developer should be able to contribute to a project. A Developer should not be able to execute JavaScript in another user's session.

When that boundary fails, the impact can extend beyond a single dashboard and into the broader security model of the platform.

For defenders, the action is straightforward: upgrade GitLab EE to a fixed version immediately.

For developers, the lesson is broader: every dashboard, analytics view, widget, and rendered data point must be treated as a potential output sink. If user-controlled data reaches the browser, it must be handled as untrusted until the last rendering step.