CVE-2021-22175

Think of GitLab like a receptionist that can forward messages to other services. This bug lets a stranger trick the receptionist into making calls to “private doors” inside your organization—doors that are not meant to be reachable from the outside—when a specific webhook forwarding option is turned on.

This matters if you run GitLab (debian-hosted GitLab included) and your GitLab instance has internal-network webhook requests enabled. Because the issue is exploitable without authentication, even someone who can’t create an account may still be able to trigger it. It’s only a risk when that webhook-related internal network feature is reachable from the outside (for example, your GitLab web interface is accessible) and the “internal network for webhooks” option is explicitly turned on.

This is RED because confirmed real-world exploitation has been associated with this vulnerability and it’s listed in CISA KEV. The practical risk for a typical small business is high when GitLab is reachable from the internet and the internal-webhook setting is enabled, because attackers can force internal requests without logging in.

1. Confirm whether the feature is enabled

   • In GitLab, identify whether “requests to the internal network for webhooks” (internal-network webhook requests) is enabled. The findings state it must be explicitly enabled for the SSRF to be possible.

2. Confirm whether your version is in scope

   • The flaw affects GitLab versions starting from 10.5. Check your current GitLab version.

3. Determine the correct fix path

   • The findings specify: GitLab is fixed in 13.6.7.
   • Upgrade to GitLab 13.6.7 (or a newer fixed release available for your upgrade track) following GitLab’s upgrade procedure.
   • If you are on an older branch or constrained by maintenance windows, engage your vendor/support channel to pick the safest upgrade route.

4. If patching will be delayed

   • Immediately disable the “requests to the internal network for webhooks” capability if it’s enabled.
   • Follow GitLab’s mitigation guidance referenced in the vendor remediation materials.

5. After changes

   • Verify the setting remains disabled (if you deferred upgrading) and that GitLab is running the fixed version if you upgraded.
   • Monitor web/app access logs and webhook activity for unusual internal request patterns (e.g., unexpected internal destinations), and alert IT if you observe suspicious webhook-triggered behavior.

CVE-2021-22175 is a server-side request forgery weakness (CWE-918) in GitLab. The mechanism is SSRF: an unauthenticated attacker can cause GitLab to initiate requests to internal network targets that are normally not exposed externally, specifically when requests to the internal network for webhooks are enabled.

Exposure is driven by two conditions from the findings: (1) the internal-network webhook request capability must be explicitly enabled, and (2) the GitLab server must be reachable for the attacker to send triggering requests. The findings also state “reachable in default config: Yes,” meaning the overall configuration is not inherently safe by default.

KEV status: Listed in CISA KEV, with remediation due by 2026-03-11, and required action is to apply mitigations per vendor instructions or discontinue use if mitigations are unavailable. Exploit maturity signals include “press attention: sustained” and a traffic indicator consistent with active concern; no dated CVE-2021-22175-specific incident reports were provided in the supplied news findings.

Fix: GitLab is fixed in 13.6.7. Easiest mitigation when patching is not immediate is to disable internal-network webhook requests, then upgrade to the fixed version.