GPU VulnDB

Database/Control plane, storage & DevOps

GitLab: improper redirect validation in the Kubernetes proxy sends cluster auth tokens to an attacker-chosen server

CVSS 5.8CVE-2026-7767Control plane, storage & DevOpscurated

Impact

GitLab's Kubernetes proxy follows redirects without validating the target, so a user who controls a registered Kubernetes agent can cause GitLab to forward sensitive authentication tokens to a server of their choosing. In a GPU estate where GitLab drives cluster access - agent-based deployments onto the training or inference clusters - the leaked token is a credential against the cluster or against GitLab itself, in the hands of whoever registered the agent. Scope is marked changed because the token belongs to a different trust domain than the agent that triggers the leak. Exploitation requires user interaction and the advisory rates attack complexity high, so this is credential hygiene work rather than an emergency.

Who can reach it

An authenticated GitLab user who controls a Kubernetes agent connected to the instance, plus interaction from the victim whose token is proxied.

What to do

Upgrade self-managed GitLab to 19.4.2, 19.3.5 or 19.2.8 and restart the instance - a maintenance window on the GitLab application tier, no GPU node drain. After patching, rotate Kubernetes agent tokens and any cluster credentials that could have been proxied, and review which users can register agents.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.