GitLab CVE-2026-92883

Exploitation requires an authenticated GitLab CE/EE user (PR:L) who can create or control a repository, and a victim user who must view the attacker-controlled, syntax-highlighted file in the GitLab web UI (UI:R) - the XSS triggers through improper sanitization of HTML attributes in syntax-highlighted output. The description notes it applies only 'under certain conditions,' indicating the flaw is not universally triggerable across all content; the exact conditions are not detailed in the available data. Limiting factors: an attacker needs a valid account and repository write/creation ability, and no impact occurs without a second user rendering the malicious content, so pure drive-by or unauthenticated exploitation is not possible. Affected deployments are GitLab CE/EE 19.1-19.2.7, 19.3-19.3.4, and 19.4-19.4.1.

This is a credible, actionable priority rather than a CVSS-inflated non-issue. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N, 8.7) describes a network-reachable, low-complexity stored cross-site scripting flaw (CWE-79) requiring only a low-privileged authenticated account plus victim interaction, with a scope change reflecting that the attacker's JavaScript executes in OTHER users' browser sessions - the defining risk of stored XSS in a collaborative platform. POC status is confirmed publicly available (HackerOne report #3936831), which materially raises near-term exploitation likelihood, though POC availability is NOT the same as active exploitation. No CISA KEV listing and no EPSS score were provided in the input, so there is no signal of confirmed in-the-wild exploitation or a quantified exploitation probability; the absence of these is a data gap, not evidence of low risk. SSVC-style reasoning: exploitation is PROOF-OF-CONCEPT, technical impact is partial-to-total (code execution in victim sessions can lead to account/session compromise), but the attack is NOT automatable in the usual sense because it depends on a target user viewing the malicious repository. Net: a high-value, self-hostable developer platform plus a published POC and low privilege barrier justifies prompt patching, tempered by the required user interaction and need for an authenticated foothold.

An attacker with a low-privileged GitLab account crafts a repository whose file content abuses improperly sanitized HTML attributes in GitLab's syntax-highlighted code rendering. When another user (e.g., a reviewer or maintainer) views that file in the GitLab web UI, the injected JavaScript executes in their authenticated browser session, enabling session/token theft or actions on their behalf. A public proof-of-concept exists (HackerOne #3936831), lowering the effort to reproduce.