CVE‑2021‑22175: GitLab Server‑Side Request Forgery (SSRF) Vulnerability
What It Is – GitLab versions prior to the patched release allow an attacker to craft a malicious webhook payload that forces the GitLab server to issue arbitrary HTTP requests to internal network resources. This SSRF flaw can be leveraged to enumerate services, exfiltrate data, or pivot to other internal systems.
Exploitability – Public proof‑of‑concept code exists; exploitation requires the ability to submit a webhook payload (e.g., via a compromised project or CI pipeline). The CVSS v3.1 base score is 7.5 (High).
Affected Products – GitLab Community Edition and Enterprise Edition (self‑hosted) with the “internal network requests for webhooks” feature enabled.
Why It Matters for Trust & Control Assurance
- Control‑area test: The flaw highlights gaps in network‑segmentation and request‑validation controls—core to the “access control” objective that underpins many frameworks (e.g., NIST CSF 2.0).
- Evidence of due diligence: Demonstrating that you have continuous configuration monitoring and evidence of remediation (patch status, firewall rules) satisfies auditors looking for a defensible control‑assurance posture.
- Enterprise buyer expectations: Buyers now request proof that SaaS and self‑hosted tools are hardened against internal‑network abuse; a documented remediation workflow becomes a trust signal.
Recommended Actions
- Patch immediately – Apply the GitLab security update that disables the vulnerable webhook path or upgrades to the fixed version.
- Validate configuration – Review webhook settings; disable internal network requests unless explicitly required.
- Enforce network segmentation – Use firewall or service‑mesh policies to block outbound traffic from GitLab to sensitive internal endpoints.
- Capture remediation evidence – Record patch deployment timestamps, configuration snapshots, and monitoring alerts for audit trails.
Source: CISA KEV – CVE‑2021‑22175