Is CVE-2021-22175 (GitLab Server-Side Request Forgery (SSRF)) being exploited in the wild?

Yes. CISA added CVE-2021-22175 to its Known Exploited Vulnerabilities catalogue on 18 February 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. GitLab contains a server-side request forgery (SSRF) vulnerability when requests to the internal network for webhooks are enabled. Any organisation running the affected product should treat remediation as urgent.

How to tell whether this GitLab SSRF matters operationally

For this CVE, the practical question is not whether SSRF is theoretically bad, but whether your GitLab instance can be made to fetch attacker-controlled URLs from inside your network. That is what turns a web-layer flaw into an internal reachability problem. If webhooks can trigger internal requests, assume the vulnerable path can be used for discovery, metadata access, or proxying toward internal services.

If you operate GitLab as part of a software delivery path, the exposure is usually broader than one application server. Any reachable internal endpoint that trusts source location, network position, or default allowlists becomes part of the blast radius. That is why this class of issue often shows up in CI/CD and platform environments, not just in public-facing web tiers. The SSRF Prevention Guide is useful here because it focuses on the actual control problem: outbound request control, URL validation, and metadata-service abuse.

For exposure checking, confirm whether the affected GitLab feature set is enabled, whether the instance can reach internal RFC 1918 or link-local targets, and whether outbound requests are filtered or observed. If internal egress is broad, the vulnerability is more than an application bug, it is a network trust boundary problem.

Why CISA KEV changes the response

CISA KEV inclusion is a strong operational signal that the issue should move from normal backlog handling to urgent remediation planning. For this case, the response should be driven by confirmed exploitation risk rather than by abstract severity labels alone. CISA’s KEV catalogue and the vendor advisory should be treated as the authoritative sources for current remediation guidance and version specifics.

When a flaw is listed in KEV, prioritisation should shift to exposed instances, internet-facing management planes, and systems with lateral reach into sensitive internal services. The CISA Known Exploited Vulnerabilities Catalog exists for exactly this kind of decision. For vulnerability triage, pair that with the NIST National Vulnerability Database and the CVE Program so your team can confirm the canonical record and tracking data.

The useful practitioner judgement is to treat KEV status as an escalation trigger, not as a substitute for local validation. You still need to confirm whether the vulnerable path exists in your deployment, whether compensating controls are active, and whether the instance has been reachable by untrusted users.

What to do if patching or upgrade has to wait

If immediate remediation is not possible, reduce the exploit path rather than waiting passively. The most effective temporary controls are the ones that narrow what the application can reach and what it can request. That means constraining outbound traffic from the GitLab host or container, blocking link-local and internal metadata targets where feasible, and disabling or limiting the webhook behaviour that creates the internal fetch path.

For GitLab-related web exposure, this is also where adjacent application-security controls matter. The Web Application Attacks Guide helps frame SSRF alongside other server-side request handling flaws, while the Vulnerability Management Guide is the right reference for how to record exceptions, define remediation SLAs, and verify closure after change.

Do not rely on “it is internal only” as a mitigation. SSRF often becomes dangerous precisely because the target is internal. If you must defer the fix, document the exception, add detection for unusual outbound destinations, and restrict any service accounts or tokens that the GitLab environment can reach from the same trust zone.

Risk and Threat Considerations

SSRF in a platform like GitLab can turn the application into a stepping stone into the internal network. The main risk is not just data exposure from the web request itself, but abuse of the server as a trusted proxy toward services that were never meant to be externally reachable. That can expose metadata, internal APIs, or other hosts behind network controls.

Failure mechanism: An attacker supplies a webhook or similar request path that causes GitLab to make server-side requests to internal or link-local destinations, bypassing intended trust boundaries and access assumptions.

Impact: The result can be internal reconnaissance, access to metadata or internal services, and a larger compromise path if the platform can reach privileged endpoints or sensitive infrastructure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-16 — Application Software Security	SSRF is an application flaw requiring secure input and request handling.
Recommendation — Harden server-side request paths and validate outbound destinations before release.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	SSRF exploits unsafe handling of attacker-controlled request targets.
	SC-7 — Boundary Protection	Mitigations depend on restricting outbound reach to internal systems and metadata endpoints.
Recommendation — Validate and constrain request targets before the application fetches them. Restrict egress paths so server-side requests cannot reach sensitive internal resources.
OWASP ASVS	V4 — API and Web Service	SSRF is a web-service request handling weakness in server-side HTTP flows.
Recommendation — Review server-side request handling and block attacker-controlled internal targets.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	The CVE is exploited through a public-facing application entry point.
Recommendation — Monitor the GitLab entry point for exploitation attempts and unusual outbound fetches.

Practitioner Guidance

What to verify: Confirm whether your deployment exposes the vulnerable GitLab path, whether the instance can reach internal or metadata-style addresses, and whether outbound request restrictions are actually enforced rather than only documented.

Decision rule: If the GitLab instance can make arbitrary outbound web requests into a broad internal address space, treat the issue as a network trust-boundary exposure and prioritise containment before routine maintenance work.

Common mistake: Teams often focus only on the application patch and ignore the reachability conditions that make SSRF exploitable. If the path remains open, the same class of abuse can persist through alternate inputs or adjacent features.

Practitioner takeaway: For SSRF, the fix is only complete when the vulnerable feature is removed or patched and the reachable network surface is narrowed enough that server-side requests cannot be used as an internal pivot.