CVE-2021-22175 in GitLab
Summary
by MITRE • 06/11/2021
When requests to the internal network for webhooks are enabled, a server-side request forgery vulnerability in GitLab affecting all versions starting from 10.5 was possible to exploit for an unauthenticated attacker even on a GitLab instance where registration is disabled
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 02/18/2026
The vulnerability identified as CVE-2021-22175 represents a critical server-side request forgery flaw within GitLab's webhook functionality that undermines the security boundaries of the platform. This vulnerability exists in GitLab instances where internal network requests for webhooks are enabled, creating a pathway for attackers to manipulate the system's behavior through crafted requests that bypass normal authentication mechanisms. The flaw affects all versions of GitLab starting from version 10.5, indicating a long-standing issue that has persisted across multiple releases and potentially exposed countless organizations to risk.
The technical implementation of this vulnerability stems from inadequate validation of URLs and endpoints that webhook requests can target within the internal network. When GitLab processes webhook notifications and is configured to make requests to internal services, the system fails to properly sanitize or restrict the destinations of these requests. This allows an unauthenticated attacker to craft webhook configurations that point to internal network resources, enabling them to perform requests that would normally be restricted to authenticated users or internal system processes. The vulnerability specifically exploits the trust relationship that GitLab establishes with internal services when processing webhook events, creating an attack vector that can be leveraged without requiring any valid credentials or user authentication.
The operational impact of CVE-2021-22175 is severe and multifaceted, as it allows attackers to potentially access internal network resources that should remain protected from external access. Even in GitLab instances where user registration is disabled, the vulnerability maintains its exploitable nature, demonstrating that the flaw exists at a fundamental architectural level rather than being dependent on user access controls. Attackers can leverage this vulnerability to perform reconnaissance activities by scanning internal network services, potentially identifying additional vulnerabilities or sensitive information. The impact extends beyond simple information disclosure to include the possibility of privilege escalation, data exfiltration, or further exploitation of internal systems that may be accessible through the webhook mechanism.
Organizations should immediately implement mitigations that include disabling internal network webhook requests when such functionality is not required for business operations. The most effective approach involves configuring GitLab to restrict webhook destinations to external, trusted endpoints only, and implementing network-level controls that prevent internal network access from webhook processing components. This vulnerability aligns with CWE-918, which describes server-side request forgery vulnerabilities, and maps to attack patterns in the MITRE ATT&CK framework under the T1190 technique for exploitation of remote services. Security teams should also consider implementing network segmentation and firewall rules that specifically block internal network access from GitLab webhook processing services, ensuring that even if the vulnerability is not patched, the attack surface is minimized and the potential for successful exploitation is reduced.