GPU VulnDB

Database/Control plane, storage & DevOps

GitLab: unauthenticated SSRF through webhooks reaches the internal network

CVSS 9.8CVE-2021-22175Control plane, storage & DevOpsKnown exploitedcurated

Impact

An attacker with no account - on an instance where registration is closed - makes the GitLab server issue HTTP requests of their choosing to hosts it can reach. For a GPU operator that matters because the CI/CD server usually sits inside the management network with a line of sight to things that trust the network rather than the caller: cloud metadata endpoints, BMC and Redfish interfaces, the scheduler API, internal registries, secret stores. CISA lists this as known exploited, so it is being used in the wild and not a theoretical path. Affects all versions from 10.5 onward where requests to the local network from webhooks are permitted.

Who can reach it

Anyone who can reach the GitLab HTTP interface, unauthenticated. Exposure depends on whether the instance's webhook settings allow requests to the local network, and on what the server itself can route to.

What to do

Upgrade GitLab to a release that carries the fix per the vendor advisory - the record does not name a fixed version, so take it from the GitLab CVE entry linked below - then restart the GitLab services. The configuration mitigation is to disable "Allow requests to the local network from webhooks" in admin settings, which takes effect without a restart and is the right first move if a maintenance window is not available. Also treat anything the GitLab host can reach as having been exposed: rotate credentials fetched from metadata or secret endpoints if you find evidence of exploitation.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.