GitLab Pages EUVD-2026-98210

Exploitation requires that the GitLab Pages feature is in use and that sensitive request data has actually been written to Pages log files or forwarded to error-tracking events ('under certain conditions'), plus the attacker must be an authenticated user who already holds access to that Pages log data - this privileged log access is the key limiting factor (reflected as PR:H). It is not remotely exploitable against default configurations by an anonymous user: an attacker without log-data access cannot reach the leaked secrets. Impact is confined to disclosure of whatever tokens/secrets happened to be logged; it depends on affected versions (before 19.2.8 / 19.3.5 / 19.4.2) and on logging/error-tracking being configured to capture request data.

This is a moderate-severity information disclosure (CVSS 6.2) rather than a top-tier emergency. The provided CVSS vector (CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N) establishes that exploitation requires high privileges (PR:H) and adjacent-network positioning (AV:A), with impact limited to confidentiality (C:H, I:N, A:N) - meaning no data tampering or service disruption, only secret leakage. No EPSS score, KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the issue was self-reported and remediated by GitLab. The scope change (S:C) is significant: the leaked access tokens and secrets can grant access to resources beyond the vulnerable logging component, amplifying the real impact of what is otherwise a passive disclosure. The PR:H requirement sharply limits the threat population to users who already hold privileged access to GitLab Pages log data, so this is best treated as a defense-in-depth / insider-and-lateral-movement concern rather than a mass-exploitable perimeter flaw. One note of caution: the AV:A (adjacent) designation is unusual for a log-file disclosure (CWE-532), which is typically local or logical access to logs - this metric should be verified against GitLab's advisory, as it may reflect assumptions about how log/error-tracking data is accessed.

An authenticated user who already has access to GitLab Pages log data (or the connected error-tracking system) reviews log files or error events and finds access tokens and other secrets that were inadvertently written into logged request data. The attacker harvests these tokens and reuses them to access GitLab resources or downstream systems beyond their own authorization scope. No public exploit code is required or known; exploitation is essentially reading logs one already has privileged access to.