CVE-2021-39935: Unauthenticated SSRF in GitLab CI Lint API Exposes Internal Services

CVE ID: CVE-2021-39935 Affected Products: GitLab Community Edition (CE) and Enterprise Edition (EE) Vulnerability Type: Server-Side Request Forgery (SSRF) Attack Vector: Network, No Authentication Required CISA KEV Patch Deadline: February 24, 2026


Vulnerability Details

CVE-2021-39935 is a server-side request forgery (SSRF) vulnerability present in the CI Lint API of GitLab Community and Enterprise Editions. An unauthenticated external attacker can send crafted HTTP requests to the /api/v4/projects/:id/ci/lint endpoint and cause the GitLab server to issue arbitrary outbound HTTP requests on the attacker's behalf.

The flaw requires no valid credentials and no authenticated session. Any external party with network access to the GitLab instance can trigger the vulnerability directly.


Technical Breakdown

The CI Lint API endpoint exists to validate .gitlab-ci.yml pipeline configurations. Under normal operation, GitLab processes user-supplied YAML content to check syntax and structure. The SSRF vulnerability arises because the API fails to adequately validate or restrict URLs or resource references embedded within that input before the server acts on them.

An attacker submits a malicious payload to the CI Lint endpoint. The GitLab server then initiates HTTP requests to attacker-controlled or attacker-specified targets — including internal network addresses, loopback interfaces, and cloud provider metadata endpoints such as http://169.254.169.254 (AWS EC2 instance metadata service) or equivalent GCP and Azure endpoints.

Because the request originates from the GitLab server itself, it bypasses perimeter controls that block direct external access to internal resources. The attacker receives responses routed back through the GitLab application, effectively using the server as a proxy into the internal environment.

Key characteristics:

  • Authentication required: None
  • User interaction required: None
  • Attack complexity: Low
  • Privileges required: None
  • Network access: Remote

Real-World Impact

The practical consequences of successful exploitation depend on the network architecture surrounding the GitLab instance, but the attack surface is broad.

Internal service enumeration: Attackers can probe internal IP ranges and identify services running on ports not exposed externally — databases, internal APIs, administrative dashboards, and monitoring infrastructure.

Cloud metadata exposure: GitLab instances deployed on AWS, GCP, or Azure are particularly at risk. Requests to instance metadata endpoints can return IAM role credentials, access tokens, SSH keys, and environment variables. A single metadata endpoint query can hand an attacker valid cloud credentials with the permissions attached to the GitLab host's IAM role or service account.

Credential harvesting: Internal services that rely on network-level trust rather than authentication — such as unauthenticated Redis instances, internal CI/CD tooling, or artifact registries — can be queried or manipulated through the forged requests.

Lateral movement enablement: SSRF vulnerabilities function as a pivot point. Once an attacker maps internal infrastructure and retrieves credentials or tokens, they can chain the access into broader network compromise without ever establishing a direct foothold on a server.

GitLab is widely deployed in enterprise, government, and critical infrastructure environments. Self-hosted instances frequently sit behind corporate firewalls with direct access to internal developer tooling, source code repositories, secrets management systems, and deployment pipelines. An unauthenticated SSRF at the CI layer creates a direct path to these assets.

CISA has added CVE-2021-39935 to the Known Exploited Vulnerabilities (KEV) catalog and mandates that federal agencies remediate by February 24, 2026. The inclusion in KEV reflects confirmed exploitation activity against this vulnerability in the wild.


Affected Versions

GitLab Community Edition and Enterprise Edition versions prior to 14.3.2 are vulnerable. Both self-managed deployments and any organizations running unpatched versions of the CE or EE packages are exposed.

GitLab.com (SaaS) was patched by GitLab directly and does not require action from end users.


Patching and Mitigation

Primary remediation: Upgrade GitLab CE or EE to version 14.3.2 or later. This release contains the fix that prevents the CI Lint API from issuing arbitrary server-side requests.

Upgrade documentation and packages are available through the official GitLab releases page at https://about.gitlab.com/releases/.

If immediate patching is not possible, implement the following compensating controls:

  1. Block or restrict the CI Lint API endpoint at the reverse proxy or WAF layer. Deny external access to /api/v4/projects/:id/ci/lint and limit access to authenticated internal users only where the endpoint must remain available.

  2. Restrict outbound HTTP from the GitLab server using host-based firewall rules (iptables, nftables, or equivalent). Deny outbound connections to RFC 1918 address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and cloud metadata endpoints (169.254.169.254, fd00:ec2::254) from the GitLab host.

  3. Enforce IMDSv2 on AWS instances running GitLab. IMDSv2 requires a session-oriented token for metadata API access, which mitigates straightforward metadata credential theft via SSRF.

  4. Audit outbound network logs for anomalous requests originating from the GitLab server to internal IP ranges or metadata endpoints. These may indicate active exploitation prior to patching.

SOC teams should add detection rules for requests from GitLab server IPs targeting internal RFC 1918 subnets or cloud metadata services. Any such traffic outside established CI/CD workflows warrants immediate investigation.

Organizations running GitLab in environments subject to CISA BOD 22-01 must meet the February 24, 2026 remediation deadline. Given the low attack complexity and lack of authentication requirement, patching should be treated as urgent regardless of regulatory obligation.