CVE-2021-39935

What it actually does

This is a server-side request forgery vulnerability in GitLab Community Edition and Enterprise Edition CI Lint functionality. In affected versions, an unauthenticated external user can submit crafted CI lint input that causes the GitLab server to make outbound HTTP requests on the attacker’s behalf. Because the request originates from the GitLab application server, the attacker may be able to reach internal services, cloud instance metadata endpoints, loopback-only services, or network locations that are not directly exposed to the internet. The CVSS scope change and high confidentiality impact reflect the risk of reading sensitive internal responses, although exploitation requires specific conditions and does not directly provide code execution by itself.

Why it matters to the business

A vulnerable internet-facing GitLab instance can be abused as a network pivot to probe or retrieve data from internal systems that trust the GitLab server’s network position. Potential consequences include exposure of cloud credentials from metadata services, leakage of internal service data, reconnaissance of private infrastructure, and follow-on compromise using any secrets obtained. This issue is listed in the CISA Known Exploited Vulnerabilities catalog, has active in-the-wild exploitation, and has a CISA remediation due date of 2026-02-24, so remediation should be treated as a compliance and risk-priority item even though the CVSS score is moderate.

How an attack unfolds

An attacker identifies a GitLab CE/EE instance running an affected release: 10.5 through versions before 14.3.6, 14.4 before 14.4.4, or 14.5 before 14.5.2. The attacker then sends crafted requests to the CI Lint API, commonly using CI configuration content that instructs GitLab to retrieve remote resources. Because vulnerable GitLab versions insufficiently restrict this behavior for unauthorized external users, the application server performs the outbound request. The attacker targets internal URLs such as loopback services, RFC1918 addresses, link-local cloud metadata endpoints, or internal hostnames. If the response is returned through the linting workflow or otherwise influences the API response, the attacker can extract sensitive data or confirm internal network reachability. Successful exploitation may then be used for cloud credential theft, internal reconnaissance, or staging additional attacks against services only reachable from the GitLab server.

How to fix it

Upgrade GitLab CE/EE to a fixed release immediately. Affected version ranges are all versions from 10.5 before 14.3.6, all versions from 14.4 before 14.4.4, and all versions from 14.5 before 14.5.2. Fixed release targets are 14.3.6, 14.4.4, 14.5.2, or any later supported GitLab release. The upstream gitlab-org/gitlab fix is associated with commit a1175384df48e74899d664520601823016d81084. If immediate upgrade is not possible, restrict public access to GitLab and especially CI lint endpoints, require authentication at an upstream reverse proxy where feasible, block outbound traffic from GitLab servers to cloud metadata endpoints and internal management networks, enforce egress allow-listing, and ensure cloud metadata services require session tokens where supported, such as IMDSv2 on AWS.

How to confirm the fix worked

Confirm the installed GitLab version is not in an affected range and is at least 14.3.6, 14.4.4, 14.5.2, or a later supported version. Validate from the GitLab admin interface, package manager, container image tag, or `gitlab-rake gitlab:env:info` output. Review reverse proxy and GitLab access logs to ensure CI Lint API endpoints are not publicly reachable without intended controls. From a controlled test environment, verify that unauthenticated requests to CI lint endpoints cannot trigger outbound requests to a collaborator-controlled URL. Also confirm network-level controls prevent the GitLab server from reaching link-local metadata addresses, loopback-only services, and sensitive internal ranges except where explicitly required.

Typical attack path

1. Discover an internet-facing GitLab CE/EE instance and determine or infer that it is within an affected version range.
2. Send unauthenticated or externally accessible requests to the CI Lint API endpoint.
3. Embed a crafted CI configuration that causes GitLab to fetch a remote URL during lint processing.
4. Direct the server-side request toward internal IP ranges, localhost, internal DNS names, or cloud metadata services.
5. Observe API responses, timing, error messages, DNS callbacks, or outbound network telemetry to confirm SSRF behavior.
6. Use any disclosed metadata, tokens, service banners, or internal responses for privilege escalation, lateral movement, or further reconnaissance.

How to detect it

Look for evidence that CI Lint endpoints were accessed by unauthenticated or unexpected external clients, especially requests containing remote includes or URLs pointing to internal infrastructure. Primary log sources include GitLab NGINX access logs such as `gitlab_access.log` and `gitlab_access_json.log`, GitLab Rails logs such as `production.log` and `production_json.log`, reverse proxy or load balancer logs, WAF logs, DNS resolver logs, egress proxy logs, firewall flow logs, and cloud metadata access telemetry where available. Correlate inbound POST requests to `/api/v4/ci/lint`, project CI lint endpoints, or `/-/ci/lint` with outbound HTTP, HTTPS, or DNS requests initiated by the GitLab server shortly afterward. Suspicious destinations include 169.254.169.254, metadata.google.internal, localhost, 127.0.0.1, ::1, RFC1918 ranges, internal DNS suffixes, Kubernetes service IP ranges, and administrative service ports. Investigate responses with unusual status codes, long response times, repeated probing across internal IP ranges, or payloads containing `include: remote:`. If DNS callback domains or attacker-controlled canary domains appear in lint requests, treat that as strong evidence of SSRF testing. Because this issue has been exploited in the wild, absence of obvious errors in GitLab application logs is not sufficient; egress network telemetry is often the most reliable source for confirming attempted or successful exploitation.

• /api/v4/ci/lint
• /-/ci/lint
• /projects/*/ci/lint
• POST /api/v4/ci/lint
• POST /-/ci/lint
• include:
• remote:
• http://169.254.169.254
• https://169.254.169.254
• /latest/meta-data
• /latest/user-data
• metadata.google.internal
• 169.254.169.254/metadata/instance
• http://127.0.0.1
• http://localhost
• http://[::1]
• http://10.
• http://172.16.
• http://172.17.
• http://172.18.
• http://172.19.
• http://172.20.
• http://172.21.
• http://172.22.
• http://172.23.
• http://172.24.
• http://172.25.
• http://172.26.
• http://172.27.
• http://172.28.
• http://172.29.
• http://172.30.
• http://172.31.
• http://192.168.

What your security team should do

• Prioritize upgrade or compensating controls because this vulnerability is in the CISA Known Exploited Vulnerabilities catalog and has documented active exploitation.
• Inventory all self-managed GitLab CE/EE instances, including internet-facing, internal, containerized, and appliance-based deployments.
• Upgrade affected instances to 14.3.6, 14.4.4, 14.5.2, or a later supported release; do not rely only on WAF filtering as a permanent fix.
• Restrict access to CI Lint API endpoints from untrusted networks until remediation is complete.
• Implement egress filtering for GitLab servers, explicitly blocking access to 169.254.169.254, localhost, RFC1918 management networks, and internal-only services unless required.
• Review historical GitLab access logs, application logs, DNS logs, proxy logs, and firewall logs for CI Lint requests followed by unusual outbound HTTP/DNS activity.
• Harden cloud metadata access for GitLab hosts, including IMDSv2 enforcement on AWS and equivalent metadata protections on other cloud platforms.
• Rotate credentials or tokens that may have been accessible from the GitLab server if evidence of SSRF to metadata or secret-bearing internal services is found.