GitLab CVE-2026-100755

Exploitation requires the GitLab instance to be running a specific (unspecified) deployment/caching configuration in which cache keys are constructed improperly - the vendor states the issue arises only 'under certain deployment configurations,' so default or non-caching deployments are likely not affected. The attacker must be an authenticated user (PR:L), and exploitation additionally requires victim user interaction (UI:R) - a target user must load the poisoned cached page for impact to occur. High attack complexity (AC:H) reflects that the attacker must align request parameters with the flawed cache-key logic. These factors - authentication, a non-default caching configuration, and required victim interaction - collectively limit realistic exploitation to targeted scenarios rather than broad, unauthenticated, default-config attacks.

This is a genuinely low-priority issue despite affecting a widely-deployed platform. The CVSS 3.1 base score of 4.6 (Medium) is consistent with the vector CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L: while network-reachable, exploitation requires an authenticated low-privileged user (PR:L), high attack complexity (AC:H - gated behind 'certain deployment configurations' per the description), AND victim user interaction (UI:R), with only Low impact across confidentiality, integrity, and availability. No EPSS score, CISA KEV listing, SSVC decision data, or POC availability was provided in the input, so exploitation status is 'no public exploit identified at time of analysis.' The combination of mandatory authentication, high complexity, required user interaction, and configuration dependency makes mass or automated exploitation impractical. The AC:H and the description's 'under certain deployment configurations' qualifier are the dominant risk-limiting signals; this is a high-footprint product but a low-real-risk flaw, not an urgent-patch situation absent an active-exploitation signal.

An authenticated low-privileged GitLab user on an instance running a vulnerable caching configuration crafts a request that, due to improper cache key construction, causes attacker-influenced content to be stored under a cache key subsequently served to other users. A victim user who then loads the affected page receives the poisoned cached content. No public exploit code was identified in the provided data, and success depends on the specific deployment/caching configuration being present.