GitLab CVE-2026-3855

Exploitation requires an authenticated GitLab account holding project-level permissions sufficient to write to the Terraform state backend (GitLab's Developer role and above can push state to a project's state endpoint; CVSS PR:L confirms authenticated, non-admin access). The target project must actually use the Terraform state upload feature - projects that never push Terraform state expose no reachable attack surface. The attacker must additionally craft parameters that resolve to restricted server-side files or a corruptible state resource, which is why AC:H is assigned: naive payloads will simply fail validation or create an error, not disclose data. What LIMITS exploitation: unauthenticated users cannot trigger it (a valid session and project membership are mandatory); the impact is bounded to low confidentiality (C:L) with no integrity or availability impact recorded in the CVSS vector despite the description's DoS claim; and no KEV listing indicates no observed mass exploitation.

Signals conflict and should be read carefully. CVSS 3.1 places this at 3.1 (LOW): network attack vector but high complexity (AC:H), privileges required (PR:L), no user interaction, and limited confidentiality impact only - the vector explicitly sets A:N even though the description mentions denial of service, so the DoS claim is not corroborated by the scoring body and should be treated as unverified. The high attack complexity reflects the difficulty of crafting parameters that successfully resolve to restricted server paths. A public proof of concept (HackerOne report 3575167) is confirmed by the input, which raises practical exploitability above what a 3.1 score implies, but this is not confirmed actively exploited - no CISA KEV entry. EPSS was not supplied, so exploitation probability cannot be quantified and the SSVC exploitation status is best classified as 'PoC exists, no observed exploitation'. Net assessment: low-priority patching for most organizations (no RCE, no privilege escalation, requires an authenticated project member), but higher priority for multi-tenant GitLab instances where untrusted or external contributors have Developer-level access to projects using Terraform state.

An attacker with a Developer-level account on a GitLab project that uses the Terraform state backend (or a compromised low-privileged account) sends a crafted state upload request in which the state identifier or associated parameters are manipulated rather than the expected value. The unvalidated parameter is resolved server-side against the file/resource layer, letting the attacker read files that should be restricted to the GitLab host, or produce malformed state that degrades the service. Public exploit detail is available through the referenced HackerOne report, lowering the skill barrier despite the high attack complexity rating.