CVE-2021-22175 is a server-side request forgery (SSRF) vulnerability in GitLab GitLab. CISA added it to the Known Exploited Vulnerabilities catalogue on 18 February 2026, which means attackers have used it in real attacks. GitLab contains a server-side request forgery (SSRF) vulnerability when requests to the internal network for webhooks are enabled.
What this vulnerability means in GitLab
Server-side request forgery in a web application means the application can be induced to make requests on the attacker’s behalf, including to internal hosts that are not normally reachable from the internet. In GitLab, that matters because webhook-related request handling can become a path from an external trigger to internal network access.
The security problem is not just that an outbound request is made. The danger is that the server, not the attacker’s browser, becomes the trusted network caller. That can expose internal metadata, internal admin interfaces, local services, or other restricted endpoints that were never meant to be reachable through the application layer.
Why SSRF is dangerous in a source-code and DevOps platform
Platforms like GitLab often sit close to repositories, integrations, runners, deployment pipelines, and internal service endpoints. If an SSRF flaw allows controlled requests into that environment, the application can be turned into a bridge between an untrusted external input and a higher-trust network zone.
That is especially risky when the application can reach link-local, loopback, RFC1918, or otherwise internal addresses, because the attacker may not need direct network access to the target at all. The exploit path depends on the application’s own reachability, DNS resolution, redirect handling, and any network egress rules that still permit internal destinations.
For a practical explanation of the attack class itself, see Web Application Attacks Guide, which places SSRF alongside other request-manipulation patterns that abuse server-side trust.
How organisations assess exposure and reduce blast radius
Exposure assessment starts with asset inventory and network path mapping: which GitLab instances are internet-facing, which versions are present, and whether webhook or URL-fetching features can reach internal networks. Vendor advisories and the CVE Program are the authoritative places to confirm the exact vulnerability record and remediation guidance, while the NIST National Vulnerability Database helps with record lookups and vulnerability context.
Where immediate patching is not yet possible, compensating controls should focus on restricting outbound requests from the application, denying access to internal address ranges, limiting redirects, and reducing what the GitLab host can reach on the network. Vulnerability Management Guide is useful here because exposure review, prioritisation, exceptions, and verification are all part of the remediation loop.
Detection and post-exploitation review
After a suspected exploit or patch application, defenders should review logs for unusual webhook activity, unexpected outbound requests, DNS lookups to internal names, and traffic aimed at metadata or service endpoints. SSRF often leaves small but telling traces: repeated request failures, strange URL parameters, or outbound connections to destinations that should never be reachable from the application tier.
Because SSRF can be used to pivot deeper into a network, post-patch review should also look for secondary compromise indicators such as newly created tokens, altered integrations, unusual repository access, or follow-on requests from the same source system. In incident-response terms, the question is not only whether the flaw was touched, but whether the application was used as an internal foothold.
GitLab-specific compromise patterns are well illustrated by Capital One breach 2019, which shows how SSRF can be used to reach internal credential sources and turn application access into broader environment access.
Other GitLab exposure and credential-theft patterns are covered in Internet Archive breach 2024 and Sisense breach 2024, both of which reinforce the need to treat exposed tokens and post-compromise access as part of the review, not an afterthought.
Risk and Threat Considerations
SSRF becomes especially dangerous when the vulnerable application can reach internal services, cloud metadata endpoints, or authenticated internal APIs. In a platform like GitLab, that can expose secrets, internal-only services, and privileged trust relationships that were assumed to be inaccessible from outside.
Failure mechanism: The attacker supplies a URL or request target that causes GitLab to fetch attacker-chosen internal resources, then uses the resulting network position to probe, extract data from, or pivot through trusted infrastructure.
Impact: Successful exploitation can lead to internal reconnaissance, credential or token exposure, lateral movement, and broader compromise of adjacent systems that trust traffic originating from the GitLab host.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | SSRF is a web-service request handling flaw in the application layer. |
| V15 — Secure Coding and Architecture | The vulnerability stems from unsafe request construction and trust-boundary design. | |
| Recommendation — Validate server-side request targets and block attacker-controlled internal destinations. Design outbound-fetch features so untrusted input cannot steer internal network access. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | SSRF exploits weak control over traffic crossing trust boundaries. |
| SI-10 — Information Input Validation | The flaw depends on accepting attacker-controlled URL or request data. | |
| AU-2 — Event Logging | Detection depends on preserving logs of outbound request behavior and anomalies. | |
| Recommendation — Restrict application egress paths and prevent access to internal-only endpoints. Validate and normalize request targets before any server-side fetch occurs. Log outbound request targets, redirects, and failures for SSRF detection and review. | ||
Practitioner Guidance
What to watch for: Treat webhook and URL-fetching features as high-risk inputs whenever they can influence server-side network access. The main governance question is whether the application can reach anything that a normal user cannot, because that difference is what turns a request feature into a trust-boundary problem.
Common misunderstanding: Blocking obvious private IP literals is not enough on its own. Effective handling usually also requires redirect controls, hostname resolution checks, egress filtering, and review of any internal services reachable from the application tier.
Practitioner takeaway: If a GitLab instance can make outbound requests, assume it can be abused until the reachable destinations, redirect behavior, and egress policy have been explicitly constrained and verified.
Related resources from NHI Mgmt Group
- CVE-2026-20230 (Cisco Unified Communications Manager Server-Side Request Forgery (SSRF))
- CVE-2021-22054 (Omnissa Workspace ONE Server-Side Request Forgery)
- What is the difference between server-side request forgery and unsafe consumption of APIs?
- What are the signs that an unauthenticated server-side request forgery issue is present in a map styling or catalog tool?