CVE-2021-39935

What is GitLab CI Lint?

GitLab's CI Lint API is a feature that allows users and tools to validate .gitlab-ci.yml pipeline configuration files — checking whether a CI/CD configuration is syntactically valid and correctly structured before committing it. The CI Lint API processes YAML configuration that may include remote includes (include: directives pointing to URLs or other repositories) which GitLab resolves by making outbound HTTP/HTTPS requests. When the API processes an include URL without restricting target addresses to external/permitted hosts, it can be abused as an SSRF vector: an attacker crafts a CI Lint request with an internal network URL, causing the GitLab server to make an outbound request to that internal address and return the response.

Overview

CVE-2021-39935 is a Server-Side Request Forgery vulnerability (CWE-918) in GitLab Community and Enterprise Editions (11.8 through 14.5.1) that allows external unauthenticated users to perform SSRF via the CI Lint API. By submitting a crafted .gitlab-ci.yml with an internal-network include URL, an attacker can cause the GitLab server to make HTTP requests to internal network addresses — reaching cloud metadata services, internal APIs, Kubernetes cluster APIs, or other services not directly accessible from the internet. The Scope: Changed (S:C) with Confidentiality: High (C:H) reflects that SSRF can reach sensitive internal resources across a security boundary. Patched in GitLab 14.3.6, 14.4.4, and 14.5.2 (December 2021). CISA added this to KEV in February 2026 — four years after the patch — reflecting active exploitation of unpatched GitLab instances.

Affected Versions

Technical Details

• Root cause: SSRF (CWE-918) via the CI Lint API — GitLab's /api/v4/ci/lint endpoint processes CI configuration files that include include: directives pointing to URLs; the server fetches these URLs to validate the included configuration; without blocking private IP ranges, the attacker can specify include: http://169.254.169.254/latest/meta-data/ or internal network addresses, causing the GitLab server to fetch and return the response
• Unauthenticated access: PR:N/UI:N — the CI Lint API is accessible without authentication in affected versions; any external user can submit a CI configuration to validate, triggering the SSRF without credentials
• High complexity (AC:H): The SSRF is conditional on the CI Lint API processing the include URL before internal validation blocks it — successful exploitation requires understanding the specific URL format and response handling to extract internal service data
• Scope: Changed / C:H: By reaching cloud instance metadata APIs (169.254.169.254) via SSRF, an attacker can retrieve IAM role credentials granting cloud API access — a security boundary crossing from the GitLab host's network to cloud control plane resources; this makes the confidentiality impact High despite the SSRF itself being limited
• Four-year KEV delay: CISA's February 2026 KEV addition comes four years after the December 2021 patch — indicating persistent exploitation of legacy GitLab installations that have not received updates, common in self-hosted enterprise GitLab deployments

Discovery

Identified and reported to GitLab, patched in the December 6, 2021 GitLab security release covering versions 14.5.2, 14.4.4, and 14.3.6. CISA's February 2026 KEV addition reflects confirmed active exploitation of unpatched GitLab instances — indicating that many organizations running self-hosted GitLab had not applied the 2021 security updates over the subsequent four years.

Exploitation Context

GitLab self-hosted instances are common in enterprise development environments, particularly in organizations that prefer on-premises code hosting for security or compliance reasons. The SSRF via CI Lint is particularly impactful in cloud-hosted GitLab deployments where the instance metadata service is accessible at 169.254.169.254 — an attacker who retrieves IAM credentials from the cloud metadata endpoint can move laterally to cloud resources far beyond the GitLab server itself. For on-premises GitLab instances, the SSRF enables probing of internal network services: internal APIs, Kubernetes management endpoints, database connections, or other services that GitLab's network position can reach. The combination of unauthenticated access and high confidentiality impact makes this a high-value initial access or reconnaissance tool for attackers targeting organizations with unpatched GitLab.

Remediation

1. Upgrade GitLab to 14.3.6, 14.4.4, 14.5.2, or any later version — all patch the CI Lint SSRF
2. Enable GitLab's outbound request restrictions: Admin area → Settings → Network → Outbound requests → Block requests to the local network from system hooks; configure an IP allowlist for external services GitLab is permitted to reach
3. In cloud environments: enable IMDSv2 (Instance Metadata Service v2) which requires a session token that SSRF cannot obtain, preventing CVE-2021-39935 from leaking cloud IAM credentials
4. Restrict the CI Lint API to authenticated users if self-hosted GitLab is internet-accessible — apply API authentication requirements via GitLab's application settings
5. Apply network egress controls to the GitLab server: block outbound connections to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16) from the GitLab host
6. Audit GitLab version and security patch level; self-hosted GitLab instances frequently lag significantly behind current releases — implement a regular update cadence and monitor GitLab security advisories