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

When analytics dashboards become a client-side execution surface

GitLab is not just a source-code hosting platform. For many organizations, it is the central place where development, CI/CD, security workflows, project management, deployments, and collaboration all converge.

That is why even a vulnerability in a dashboard feature can become important. Dashboards are not passive pages. They render project data, user-controlled values, configuration fields, charts, labels, filters, and metadata. If one of those values is not handled correctly before reaching the browser, the dashboard itself can become an attack surface.

CVE-2026–10087 is a Cross-Site Scripting vulnerability affecting GitLab Enterprise Edition. Under certain conditions, an authenticated user with Developer-role permissions could execute arbitrary client-side code on behalf of a targeted user because of improper input sanitization in the Analytics Dashboard.

The issue was fixed in GitLab EE versions 18.10.8, 18.11.5, and 19.0.2.

Vulnerability summary

CVE: CVE-2026–10087 Product: GitLab Enterprise Edition Affected component: Analytics Dashboard Vulnerability type: Cross-Site Scripting CWE: CWE-79 — Improper Neutralization of Input During Web Page Generation Severity: High CVSS 3.1: 8.7 Vector: AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N

Affected versions:

GitLab EE from 17.1 before 18.10.8
GitLab EE 18.11 before 18.11.5
GitLab EE 19.0 before 19.0.2

Fixed versions:

GitLab EE 18.10.8
GitLab EE 18.11.5
GitLab EE 19.0.2

The vulnerability requires an authenticated attacker with Developer-role permissions and user interaction from the targeted user.

What is the issue?

The core problem is improper input sanitization in the Analytics Dashboard.

In a secure application, user-controlled values must be neutralized before being rendered in a browser-executed context. This is especially important when the application renders dynamic data into HTML, JavaScript, attributes, markdown, charts, widgets, or dashboard components.

In this case, a Developer-level user could influence input that later reaches the Analytics Dashboard. When the targeted user views the affected dashboard, the attacker-controlled content may execute as client-side code in the victim's browser session.

The simplified flow is:

The attacker has authenticated access with Developer-role permissions.
The attacker influences data used by the Analytics Dashboard.
The dashboard does not sanitize or neutralize that input correctly.
A targeted user opens the affected dashboard.
JavaScript executes in the context of the targeted user's GitLab session.

This is the important part: the attacker does not need administrator privileges. Developer access can be enough to cross the expected boundary between "contributing to a project" and "executing code in another user's browser."

Why this matters

Cross-Site Scripting in GitLab is not equivalent to XSS on a simple marketing page.

GitLab sessions often carry access to sensitive workflows:

repositories;
issues;
merge requests;
CI/CD pipelines;
project variables;
security reports;
deployment environments;
group and project settings;
analytics data;
internal documentation;
access-controlled project metadata.

If JavaScript runs in another user's authenticated GitLab session, the impact depends on what that user can see or do.

A Developer targeting another Developer may have limited impact. But a Developer targeting a Maintainer, Owner, security engineer, or administrator can become much more serious.

That is why the CVSS vector includes high confidentiality and integrity impact. The issue is not about crashing GitLab. It is about abusing the victim's trusted browser context.

Why Developer-role access is still dangerous

A common mistake is to dismiss authenticated vulnerabilities because they require an account.

In collaborative platforms, authenticated access is not a strong barrier by itself. Many organizations have large GitLab groups with many Developers. Contractors, temporary collaborators, external contributors, internal teams, and automated accounts may all have Developer-level permissions in some projects.

Developer permissions are supposed to allow contribution. They are not supposed to allow client-side code execution against other users.

CVE-2026–10087 breaks that expectation.

The vulnerability shows that even a "normal" project role can become a security boundary problem when user-controlled data is rendered inside shared interfaces.

Understanding the CVSS vector

The GitLab CNA score is 8.7 HIGH.

The vector is:

AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N

This means:

Attack Vector: Network The vulnerability can be exploited remotely over the network.

Attack Complexity: Low The exploitation conditions are not considered highly complex once the required permissions and conditions are present.

Privileges Required: Low The attacker needs authenticated access, but not high-level administrative privileges.

User Interaction: Required A targeted user must view the affected dashboard or interact with the affected page.

Scope: Changed The vulnerability allows impact beyond the original security context. This is common in serious XSS cases because attacker-controlled content can execute in another user's browser session.

Confidentiality: High The attacker may gain access to sensitive information visible to the victim.

Integrity: High The attacker may perform or influence actions in the victim's context.

Availability: None The issue is not primarily about service disruption.

The key takeaway is simple: this is not a denial-of-service bug. It is a trust-boundary bug between users and roles inside GitLab.

Why analytics dashboards are risky

Analytics dashboards are attractive targets because they aggregate data from many sources.

They often include:

project names;
group names;
labels;
issue metadata;
merge request metadata;
saved filters;
chart labels;
descriptions;
custom values;
user-generated content;
imported or computed data.

Each displayed value may look harmless alone. But when dashboard components combine, transform, and render that data, the final browser context becomes critical.

A value that is safe as plain text may become dangerous when inserted into HTML. A value that is safe in a database may become dangerous in a JavaScript context. A value that is safe in one component may become dangerous after being passed into another rendering layer.

That is why XSS prevention cannot rely only on input filtering. It must also include strict, context-aware output encoding.

Potential impact scenarios

The public description does not require exploit details to understand the risk.

At a high level, successful exploitation could allow malicious JavaScript to run in the targeted user's GitLab session. Depending on the victim's permissions and available protections, this could lead to:

reading sensitive project data visible to the victim;
modifying project-visible content;
abusing authenticated browser actions;
interacting with endpoints as the victim;
changing dashboard-related data;
targeting higher-privileged users through normal GitLab workflows;
escalating the practical impact from project access to session abuse.

The most dangerous scenario is a lower-privileged Developer targeting a more privileged user who opens the affected Analytics Dashboard.

This is exactly the kind of bug that becomes serious in real enterprise environments, where shared dashboards are part of normal daily collaboration.

Remediation

Self-managed GitLab administrators should upgrade to a fixed version immediately.

Upgrade to one of the following versions:

GitLab EE 18.10.8
GitLab EE 18.11.5
GitLab EE 19.0.2

Administrators should also review whether affected GitLab instances are internet-facing or accessible to a large internal user base. The broader the user base, the more important it becomes to patch quickly.

Recommended defensive actions:

Identify all self-managed GitLab EE instances.
Check the installed GitLab version.
Upgrade affected versions to a patched release.
Review Developer-role assignments in sensitive projects.
Monitor suspicious activity around Analytics Dashboard usage.
Apply least privilege for project and group permissions.
Encourage users with high privileges to be cautious when reviewing shared dashboards until patching is complete.

Lessons for developers

CVE-2026–10087 reinforces a security lesson that appears again and again in modern web applications:

Every dashboard is an output surface.

It is not enough to secure forms, APIs, and authentication logic. Any feature that renders user-influenced data must be treated as security-sensitive.

Developers should pay special attention to:

analytics dashboards;
reporting views;
admin panels;
saved filters;
chart components;
markdown renderers;
issue and merge request metadata;
group and project settings;
custom labels;
imported data;
user-defined configuration fields.

The safest approach is to assume that every value reaching the browser is untrusted until it is encoded for the exact context where it appears.

Difference from a "normal" XSS

The most interesting part of this vulnerability is not simply that JavaScript can execute.

The interesting part is the role boundary.

A Developer should be able to contribute code, interact with issues, work with merge requests, and participate in project workflows. But that role should not allow arbitrary client-side code execution against another user.

When an XSS appears in a shared GitLab feature, the attack is not just technical. It becomes social and workflow-based. The attacker can place malicious data in a legitimate area of the product and wait for another user to view it.

That makes dashboard-based XSS particularly dangerous in collaborative platforms.

Final thoughts

CVE-2026–10087 is a strong reminder that security boundaries in developer platforms are complex.

The vulnerable component was an Analytics Dashboard, but the real issue was trust: GitLab trusted user-influenced data too much before rendering it in another user's browser.

For defenders, the action is straightforward: upgrade GitLab EE to 18.10.8, 18.11.5, 19.0.2, or later.

For developers, the lesson is broader: dashboards, charts, labels, filters, and analytics components must be treated as untrusted rendering surfaces.

If user-controlled data reaches the browser, it must be sanitized and escaped correctly.

The browser is not just displaying data. In an authenticated application like GitLab, it is acting with the user's permissions.

Contents