CVE-2021-22175

What it actually does

This vulnerability allows unauthenticated server-side request forgery in GitLab when the instance permits webhook requests to internal or local network addresses. An attacker can cause the GitLab server to initiate outbound HTTP requests to attacker-chosen destinations that are normally unreachable from the public internet, including internal services, loopback interfaces, cloud metadata endpoints, and other private network resources. The primary impact is confidentiality loss: internal service responses, metadata, or network reachability information may be exposed or used to map protected infrastructure. The CVSS scope change reflects that the vulnerable GitLab application can be abused as a pivot into separate internal trust zones.

Why it matters to the business

A vulnerable internet-facing GitLab instance can be abused as a bridge into private infrastructure, potentially exposing sensitive internal data, cloud credentials, service metadata, or network topology. Because this issue is listed in CISA KEV, has active exploitation in the wild, and has a high EPSS score of 0.53372, organizations should treat exposure as urgent even though the CVSS score is moderate. The CISA remediation due date is 2026-03-11 for covered organizations, but internet-exposed instances should be remediated as soon as possible.

How an attack unfolds

An attacker first identifies a GitLab instance running an affected version where outbound webhook requests to local or internal networks are enabled. Even if public user registration is disabled, the flaw allows an unauthenticated attacker to reach functionality that causes GitLab to process a crafted webhook-related request. The attacker supplies a URL pointing to an internal address, loopback service, cloud metadata endpoint, or controlled redirect destination. GitLab then performs the request from the server side, using the GitLab server’s network position and trust relationships. The attacker observes response behavior, timing, errors, or returned content to enumerate internal services or retrieve sensitive data. In cloud-hosted deployments, a high-value target is instance metadata; in self-hosted environments, attackers may target internal admin panels, source control adjacent services, package registries, CI/CD infrastructure, or secrets endpoints.

How to fix it

Upgrade GitLab to a fixed, vendor-supported release. For source-based deployments, ensure the fix containing commit 1bb1e6153d6e19ee17a73d50050cf45cc56eb9f4 is present. Prefer upgrading to the latest supported GitLab version rather than applying only an isolated patch, because later releases include additional SSRF hardening and security fixes. If immediate upgrade is not possible, disable the setting that allows webhooks and integrations to make requests to local or internal network addresses, restrict outbound network egress from the GitLab application to only required destinations, block access from GitLab hosts to cloud metadata endpoints unless explicitly needed, and place network controls between GitLab and sensitive internal services. Review webhook, integration, and service configuration for URLs pointing to loopback, link-local, private RFC1918, IPv6 local, or metadata addresses.

How to confirm the fix worked

Confirm the running GitLab version is a fixed release or that commit 1bb1e6153d6e19ee17a73d50050cf45cc56eb9f4 is included in the deployed build. In the GitLab admin settings, verify that local/internal network requests for webhooks and integrations are disabled unless there is a documented business requirement. Test from a controlled security validation host by configuring or attempting a webhook-style request to loopback, RFC1918, link-local, and cloud metadata addresses; the request should be blocked by GitLab and by network egress controls. Validate that the GitLab host cannot reach 169.254.169.254 or other environment-specific metadata endpoints unless required. Review outbound firewall, proxy, and DNS logs to ensure GitLab egress is limited to expected destinations.

Typical attack path

1. Find an internet-accessible GitLab instance and fingerprint its version or behavior.
2. Determine whether local/internal network requests for webhooks are enabled or can be reached through the vulnerable code path.
3. Send a crafted unauthenticated request that causes GitLab to initiate a server-side request to an attacker-selected URL.
4. Use internal IP ranges, loopback addresses, DNS rebinding, redirects, or cloud metadata hostnames to reach resources not exposed externally.
5. Analyze response bodies, status codes, redirects, timing, or error messages to confirm internal reachability and enumerate services.
6. Attempt to retrieve sensitive metadata, credentials, tokens, configuration data, or internal application responses.
7. Use any recovered credentials or internal knowledge for follow-on access, lateral movement, or source-code and CI/CD compromise.

How to detect it

Investigate whether the GitLab server made unusual outbound requests to internal, loopback, link-local, metadata, or nonstandard destinations around suspicious unauthenticated web activity. Review GitLab Rails logs such as production_json.log, production.log, api_json.log, application_json.log, and Sidekiq logs for webhook or integration activity involving private URLs, validation failures, blocked local requests, redirects, or unauthenticated request patterns. Review GitLab NGINX access logs for requests around webhook, project, import, service, and integration endpoints followed by outbound connections from the GitLab host. Correlate with firewall, proxy, DNS, VPC flow, EDR network telemetry, and cloud metadata service logs to identify GitLab-originated connections to 127.0.0.1, RFC1918 ranges, 169.254.169.254, IPv6 loopback/local addresses, or internal-only hostnames. Pay special attention to repeated probing of different ports, requests with URL parameters containing internal addresses, requests that trigger 500/422 errors, and GitLab-originated HTTP requests to cloud metadata paths. If possible, compare historical outbound GitLab traffic before and after patching to identify anomalous destinations.

• 169.254.169.254
• 169.254.169.254/latest/meta-data/
• 169.254.169.254/metadata/instance
• metadata.google.internal
• metadata/computeMetadata/v1
• 100.100.100.200
• 127.0.0.1
• localhost
• [::1]
• 0.0.0.0
• 10.
• 172.16.
• 172.17.
• 172.18.
• 172.19.
• 172.20.
• 172.21.
• 172.22.
• 172.23.
• 172.24.
• 172.25.
• 172.26.
• 172.27.
• 172.28.
• 172.29.
• 172.30.
• 172.31.
• 192.168.
• file://
• gopher://
• dict://
• ftp://
• UrlBlocker
• Requests to the local network are not allowed
• allow_local_requests_from_web_hooks_and_services
• /var/log/gitlab/gitlab-rails/production_json.log
• /var/log/gitlab/gitlab-rails/production.log
• /var/log/gitlab/gitlab-rails/api_json.log
• /var/log/gitlab/gitlab-rails/application_json.log
• /var/log/gitlab/nginx/gitlab_access.log
• /var/log/gitlab/sidekiq/current

What your security team should do

• Immediately inventory all internet-facing and internally accessible GitLab instances and identify versions affected since 10.5.
• Prioritize patching because the vulnerability is in CISA KEV and has documented active exploitation in the wild.
• Upgrade to a supported fixed GitLab release or verify the presence of commit 1bb1e6153d6e19ee17a73d50050cf45cc56eb9f4 for source deployments.
• Disable local/internal network access for webhooks and integrations unless explicitly required.
• Enforce outbound egress filtering from GitLab application nodes, including blocking link-local metadata addresses and sensitive internal subnets.
• Hunt historical GitLab, proxy, DNS, firewall, and cloud metadata access logs for SSRF attempts and unusual GitLab-originated connections.
• Review configured webhooks and integrations for private IPs, localhost, link-local addresses, unusual hostnames, redirects, or recently added destinations.
• If exploitation is suspected, rotate credentials that could have been exposed through metadata services, internal endpoints, CI/CD variables, deploy tokens, runners, or adjacent services.