CVE-2021-22175: GitLab Webhook SSRF Allows Internal Network Access via Malicious Requests

CVE ID: CVE-2021-22175 Vendor: GitLab Affected Product: GitLab (multiple versions with webhook functionality enabled) CISA KEV Patch Deadline: March 11, 2026

Vulnerability Overview

CVE-2021-22175 is a Server-Side Request Forgery (SSRF) vulnerability in GitLab's webhook functionality. When webhook requests to internal network targets are permitted, an authenticated attacker with webhook creation privileges can force the GitLab server to issue HTTP requests to internal network resources that are otherwise inaccessible from external networks.

The flaw exists because GitLab fails to adequately validate or restrict the destinations of outbound webhook requests. By supplying a crafted URL pointing to an internal host or IP range, an attacker abuses the GitLab server itself as a proxy to reach internal infrastructure.

Technical Details

Vulnerability Type: Server-Side Request Forgery (SSRF) Attack Vector: Network Authentication Required: Yes — the attacker must hold an account with webhook creation permissions (e.g., project Maintainer or Owner role) User Interaction: None

A malicious webhook payload targets internal IP addresses — including RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) — as well as loopback addresses and cloud provider metadata endpoints such as 169.254.169.254. The GitLab application server initiates the outbound request from its own network context, bypassing firewall rules and network segmentation controls that assume external users cannot reach internal services directly.

Services at particular risk include:

  • Databases: MySQL (3306), PostgreSQL (5432)
  • Cache layers: Redis (6379)
  • Administrative interfaces: Internal dashboards, CI/CD runners, Kubernetes API servers
  • Cloud metadata endpoints: AWS/GCP/Azure instance metadata services that may expose IAM credentials or environment configuration

An attacker can use response timing, error codes, or reflected content to map internal network topology, identify open ports on internal hosts, and in some configurations exfiltrate data from services that respond to HTTP or respond with readable error messages.

Real-World Impact

Organizations that run self-managed GitLab instances — particularly those where GitLab sits inside a trusted network segment alongside databases, internal APIs, or cloud-hosted infrastructure — face meaningful exposure. An authenticated attacker who has been granted project Maintainer access (a common permission level for developers and contractors) can leverage this flaw without requiring administrative privileges.

In environments using GitLab alongside AWS EC2, GCP Compute, or Azure VMs, the cloud metadata endpoint at 169.254.169.254 is reachable from the instance. A successful SSRF request to this endpoint can return instance metadata, including IAM role credentials with attached permissions — potentially enabling privilege escalation far beyond the GitLab environment itself.

In on-premises deployments, the same attack vector permits lateral movement reconnaissance against internal services that developers themselves may not have direct access to, but the GitLab application server does.

CISA has added CVE-2021-22175 to the Known Exploited Vulnerabilities (KEV) catalog, requiring all U.S. federal civilian executive branch agencies to remediate by March 11, 2026. The KEV listing reflects confirmed exploitation activity against this vulnerability.

Affected Versions

All GitLab Community Edition (CE) and Enterprise Edition (EE) versions with internal webhook requests enabled are affected. Confirmed patched versions by branch:

| Branch | Patched Version | |--------|-----------------| | 12.9.x | 12.9.1+ | | 12.10.x | 12.10.5+ | | 13.0.x | 13.0.1+ |

Instances running versions below these thresholds with webhook functionality enabled are vulnerable.

Patching and Mitigation

1. Upgrade immediately. Apply the patched versions listed above. GitLab releases are available at packages.gitlab.com. Organizations running GitLab.com (SaaS) are not affected — this applies to self-managed deployments only.

2. Disable outbound requests to internal addresses. In GitLab Admin Area, navigate to Settings > Network > Outbound requests and ensure that Allow requests to the local network from webhooks and integrations is disabled unless explicitly required. This is the primary configuration control.

3. Restrict webhook creation permissions. Limit webhook creation to trusted administrators. Audit all existing projects for webhooks created by non-admin users. Revoke webhook permissions from Maintainer roles where operationally feasible.

4. Implement network-level egress controls. Configure host-based firewall rules or network policies to block the GitLab application server from initiating connections to internal IP ranges, RFC 1918 addresses, and cloud metadata endpoints. GitLab should only be permitted to reach the external destinations operationally required for its function.

5. Review webhook audit logs. Search GitLab logs and network flow data for outbound requests from the GitLab server to internal IP ranges or non-standard service ports (3306, 5432, 6379, 8080, 2379, and similar). Requests to 169.254.169.254 in logs should be treated as high-severity indicators.

6. Rotate credentials exposed to the metadata service. If GitLab runs on a cloud instance and outbound requests to 169.254.169.254 appear in logs, rotate all IAM credentials associated with the instance profile and audit associated CloudTrail or equivalent access logs for unauthorized API calls.

References