CVE-2026-10712

Cross-site scripting is like leaving a “plug-in” slot on a website where an attacker can insert their own JavaScript. In this case, the attacker doesn’t need a GitLab account, but they must get a user to open a crafted page—then the attacker’s script can run inside that user’s browser.

This matters if you run GitLab (self-managed) and users log into it through a browser, because the flaw can let an attacker run JavaScript inside a user’s browser session. The issue is specifically reachable in certain cases and requires user interaction (a user opening a crafted link/page), so it’s not a blanket “instant take over” for every install. Only proceed to treat it as a real risk if your GitLab version is in the affected ranges and an attacker can reach the vulnerable web functionality (e.g., via the normal web interface paths) and lure users to the crafted content.

This is an AMBER issue because the vulnerability allows JavaScript to run in a user’s browser session, which can lead to account/session compromise. There are no confirmed reports of exploitation in the provided material, but it is still appropriate to upgrade because the fix is available and the impact is high if it’s reached.

1. Confirm exposure
   • Determine your GitLab version (from the GitLab admin area or server “About”/version page).
   • Consider yourself exposed if your version is:
     • 18.10 up to (but not including) 18.11.6, or
     • 19.0 up to (but not including) 19.0.3, or
     • 19.1 up to (but not including) 19.1.1.
2. Upgrade to a fixed release
   • Upgrade to one of the fixed versions (or newer on your branch):
     • 18.11.6
     • 19.0.3
     • 19.1.1
   • The vendor’s guidance for 19.1.1 is referenced here: https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-1-1-released/
3. Validate after upgrade
   • Re-check the running version matches the upgraded target.
   • Exercise common web UI paths used by staff (project pages, issue/merge request pages) to ensure the site behaves normally.
4. If you can’t upgrade immediately (temporary workaround)
   • Reduce risk by limiting where users can be lured to open untrusted links (internal user guidance), and monitor for suspicious browser behavior reports (unexpected redirects, login prompts, odd pop-ups).
   • If your deployment supports it, restrict or review exposure of GitLab web endpoints to the public Internet until you can patch (since the attacker is unauthenticated and the real-world impact depends on reachability).
5. What to monitor
   • Review GitLab web/app logs around the time window after any suspicious emails/links were sent.
   • Look for unusual request patterns and errors related to web page generation, especially on paths that handle user-controlled input.

Severity is high (CVSS 8) primarily because the flaw enables Cross-site Scripting, allowing impact to confidentiality and integrity in the victim’s browser context. The weakness is CWE-79: improper neutralization of input during web page generation. The mechanism is unauthenticated JavaScript execution in a user’s browser session, but it requires user interaction and depends on specific conditions (including improper path validation under certain conditions). No KEV listing was provided, and no dated exploitation reports or public exploit code were included in the provided findings; there’s also no patch KEV confirmation. A patch is available and GitLab fixed this in 18.11.6, 19.0.3, and 19.1.1.