Two GitLab server-side request forgery vulnerabilities, both confirmed exploited and both entering CISA's KEV catalogue within two weeks of each other in February 2026, are an additional finding for a vendor already covered elsewhere in this series for a different CVE — these two are new and distinct from that earlier entry.
| CVE | CVSS | Vector | Added to KEV |
|---|---|---|---|
| CVE-2021-22175 | 6.8 | Webhooks to internal network | 18 Feb 2026 |
| CVE-2021-39935 | 6.8 | CI Lint API | 3 Feb 2026 |
Why two SSRF bugs in the same product, four years apart in disclosure, matter together
Both vulnerabilities in this cluster affect GitLab Community and Enterprise Editions, both carry an identical CVSS score of 6.8, and both are the same fundamental bug class — server-side request forgery — reached through two different features. CVE-2021-22175 requires webhooks to internal networks to be enabled, and NVD specifically notes it was exploitable by an unauthenticated attacker even on instances where registration itself is disabled — meaning the standard mitigation of closing off self-registration does nothing to close this hole. CVE-2021-39935 reaches the same class of internal-network request forgery through the CI Lint API instead, allowing unauthorized external users to perform server-side requests through a completely different code path.
Two independent SSRF vulnerabilities in the same product, surfaced through unrelated features, both confirmed exploited roughly four and a half years after their original 2021 disclosure, describes a pattern rather than a one-off oversight: GitLab's webhook and CI/CD tooling both accept a URL or configuration value from a user and then have the server itself make a network request based on that input, and any feature built this way in a self-hosted GitLab instance is a candidate for the same underlying flaw until proven otherwise.
What to check this week
Patch to GitLab versions beyond 14.5.2 and 14.4.4 at minimum, the fixed-version thresholds NVD lists for CVE-2021-39935, and confirm the webhook-related fix for CVE-2021-22175 is also applied — these are two distinct patches, not one.
Audit whether webhooks to the internal network are enabled at all, since CVE-2021-22175 specifically requires that configuration; disabling it where it isn't operationally necessary removes the vulnerability's precondition entirely.
Review CI Lint API accessibility and any other GitLab features that accept user-supplied URLs, since CVE-2021-39935 demonstrates the CI/CD tooling itself is a viable SSRF path independent of the webhook feature.
Don't rely on disabled self-registration as a mitigation, given that NVD explicitly notes CVE-2021-22175 was exploitable by unauthenticated attackers even with registration disabled.
Why self-hosted GitLab's internal network reach is the real risk here
The danger in both of these vulnerabilities isn't that an attacker can make GitLab issue an HTTP request — it's where that request can go. A self-hosted GitLab instance typically runs inside an organization's internal network, alongside internal APIs, cloud metadata endpoints, and other services never meant to be internet-reachable. An SSRF vulnerability turns the GitLab server itself into a pivot point that can reach those internal services on the attacker's behalf, using GitLab's own network position as the launching point. That's a materially different risk than an SSRF bug in a purely external-facing service with no privileged network position of its own — GitLab instances often sit closer to an organization's crown-jewel infrastructure than almost any other internet-facing service they run, given their role hosting source code and CI/CD pipelines with credentials to production systems.
A closing note on GitLab as recurring KEV subject matter
This is the second distinct set of GitLab CVEs covered across this series, and taken together they describe a vendor whose core platform — a piece of infrastructure explicitly designed to sit at the center of software development and deployment, with privileged access by design — has produced multiple confirmed-exploited vulnerabilities across different feature areas. Organizations running self-hosted GitLab should treat it with the same tiered patch-priority discipline applied to any other piece of centralized, privileged infrastructure, rather than assuming a source-control platform is lower risk than a network appliance or public web application simply because its primary function is internal-facing.
How Safeguard helps
Safeguard's continuous inventory tracks self-hosted GitLab deployments and flags version drift against known-exploited CVEs like these two SSRF bugs, recognizing that a source-control and CI/CD platform's internal network position makes even a "medium"-scored vulnerability worth prioritized attention.
