GitLab CVE-2026-7767

Exploitation requires an authenticated user who controls a GitLab Kubernetes agent, and depends specifically on the GitLab Kubernetes proxy feature performing a redirect that is not properly validated (CWE-601 open redirect). The advisory explicitly scopes this to 'certain conditions,' consistent with CVSS AC:H. Limiting factors that reduce realistic risk: the attacker must already hold valid low-privileged credentials (PR:L) and control over a Kubernetes agent, the attack requires user interaction (UI:R), and only deployments that actually use the GitLab Kubernetes agent/proxy integration are exposed - instances without Kubernetes integration are not affected. The payoff is leakage of sensitive authentication tokens to an attacker-chosen server rather than direct code execution or data modification.

This is a genuine but moderate-priority issue, not a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:N/A:N = 5.8 Medium) tempers the network attack vector with three significant brakes: high attack complexity (the advisory itself says 'under certain conditions'), a requirement that the attacker already hold low-privileged authenticated access AND control a Kubernetes agent (PR:L), and required user interaction (UI:R). The scope change (S:C) and high confidentiality impact (C:H) reflect that the real damage is the leakage of sensitive authentication tokens to an unintended server - a meaningful secret-exposure outcome rather than code execution (I:N/A:N). Signals are mostly aligned and relatively low-urgency: POC/exploit code is publicly available (a HackerOne report), which raises practical likelihood, but there is NO CISA KEV listing and no EPSS score was provided in the input, so there is no evidence of active or widespread exploitation. The combination of public POC + high preconditions + no KEV points to a targeted, opportunistic risk against GitLab instances that use the Kubernetes agent integration, rather than mass exploitation. EPSS is absent from the input and should be checked separately before final prioritization.

An authenticated GitLab user who controls a Kubernetes agent configures or triggers the Kubernetes proxy so that an improperly validated redirect points to an attacker-controlled server; when the proxy follows the redirect it forwards sensitive authentication tokens to that unintended destination. A public proof-of-concept exists (HackerOne report #3597095), but the required control over a Kubernetes agent and the 'certain conditions' (reflected in CVSS AC:H and UI:R) limit this to attackers who already have a foothold in the GitLab/Kubernetes integration.