CVE-2026-10086

This flaw lets a malicious person “hide” a script inside content that gets displayed in the web app. When another user views that page, their browser can run the script as if it came from GitLab—potentially exposing their session or actions.

This matters if you run GitLab and have users with developer-role permissions who can create or influence content that other users view in the web interface. The risk is higher when a victim user can be directed to view the attacker’s crafted content (user interaction is required). Exploitation depends on an attacker being able to interact with the vulnerable feature and, per the findings, being authenticated with developer-role permissions—reachability in the default configuration is not yet known.

This should be treated as an urgent patch because the weakness can execute code in another user’s browser session context (cross-site scripting) and involves authenticated developer-level access. While there’s no clear dated public reporting of exploitation and no public exploit code on record, GitLab has already provided fixed releases, and the most effective step is to upgrade now.

1. Confirm exposure

   • Determine your GitLab edition (GitLab EE is the affected product in the findings) and the exact version number running on your server.
   • Compare your version to the fixed versions provided by GitLab:
     • If you are on the 18.11 line: upgrade to at least 18.11.6.
     • If you are on the 19.0 line: upgrade to at least 19.0.3.
     • If you are on the 19.1 line: upgrade to at least 19.1.1.
     • Versions before these thresholds are in scope.

2. Patch / upgrade

   • Upgrade GitLab to the appropriate fixed version (or newer than it) for your currently running version line.
   • Use your normal change-management process (maintenance window, backup/snapshot if you have one, and a rollback plan).

3. Temporary workaround (if you cannot upgrade immediately)

   • Limit who can create or influence the kinds of pages/content that developers can post, especially for users who can view that content across accounts/teams.
   • Reduce the chance that attacker-supplied content is shown to other users by tightening access controls and review processes for developer-managed content.
   • (Note: these steps may reduce risk, but the findings indicate the reliable fix is upgrading to the fixed versions.)

4. Post-upgrade verification

   • Confirm GitLab is running normally after upgrade.
   • Re-test your common developer-facing pages and workflows to ensure no rendering or permission issues were introduced.

5. What to monitor

   • Review web/application logs around user-facing page requests for unusual or error patterns related to content rendering after the upgrade window.
   • Watch for reports from users about unexpected pop-ups, altered page behavior, or suspicious browser prompts (these are typical symptoms of client-side script execution).

Severity is high (CWE-79 cross-site scripting) with a cross-session impact: an attacker can run client-side code in another user’s browser in the context of their GitLab session. According to the findings, exploitation requires authenticated access with developer-role permissions and requires user interaction (a victim must view attacker-controlled content). GitLab’s remediation fixed versions are 18.11.6, 19.0.3, and 19.1.1 or above. KEV does not list this issue, and there is no clear dated press claim of exploitation; no public exploit code is on record. The EPSS is provided as a prediction (flat trend), and GitLab has released patches—so patching remains the primary mitigation. Because the issue executes in a browser, successful exploitation could lead to session compromise and actions performed as the victim user.