CVE-2024-9870: GitLab SSRF Vulnerability

CVE-2024-9870 Overview

CVE-2024-9870 is a Server-Side Request Forgery (SSRF) vulnerability in GitLab Enterprise Edition (EE). The flaw allows an authenticated attacker to coerce the GitLab server into sending requests to unintended internal or external services. It affects all versions from 15.11 prior to 17.6.5, 17.7 prior to 17.7.4, and 17.8 prior to 17.8.2. The issue is tracked under [CWE-441] (Unintended Proxy or Intermediary) and [CWE-918] (Server-Side Request Forgery). GitLab addressed the vulnerability across three release branches.

Critical Impact
An authenticated attacker can pivot from the GitLab server to reach internal services, cloud metadata endpoints, or arbitrary external hosts, compromising confidentiality, integrity, and availability.

Affected Products

GitLab Enterprise Edition versions 15.11 through 17.6.4
GitLab Enterprise Edition versions 17.7 through 17.7.3
GitLab Enterprise Edition versions 17.8 through 17.8.1

Discovery Timeline

2025-02-12 - CVE-2024-9870 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-9870

Vulnerability Analysis

The vulnerability is a Server-Side Request Forgery (SSRF) issue in GitLab EE. The GitLab server accepts attacker-controlled input that determines the destination of outbound HTTP requests. Insufficient validation of the target URL allows the server to issue requests to hosts and ports the attacker chooses. This includes internal network resources that are not exposed to the public internet.

SSRF vulnerabilities in DevOps platforms are particularly consequential because the application server typically holds network-level trust. Attackers can use the GitLab instance as a proxy to reach cloud instance metadata services, internal APIs, or administrative interfaces bound to loopback addresses. Successful exploitation can expose credentials, tokens, and service configuration data.

Root Cause

The root cause is missing or insufficient allowlist-based URL validation on an integration or fetch feature that accepts a user-supplied destination. GitLab did not adequately restrict the outbound destination to prevent requests to internal address ranges, link-local addresses, or non-approved hostnames. The [CWE-441] and [CWE-918] mappings confirm the server functions as an unintended intermediary.

Attack Vector

An authenticated attacker with a low-privileged account sends a crafted request to the vulnerable endpoint. The endpoint parses the supplied URL and issues an HTTP request from the GitLab server context. Because the request originates from the trusted GitLab host, network segmentation controls that block external attackers do not apply. See the GitLab Issue Report and the HackerOne Vulnerability Report for background on the disclosure.

Detection Methods for CVE-2024-9870

Indicators of Compromise

Outbound HTTP requests from the GitLab server to internal RFC1918 address ranges or cloud metadata endpoints such as 169.254.169.254
GitLab application logs showing integration or webhook requests with unusual destination hosts, non-standard ports, or loopback addresses
Unexpected spikes in outbound connections originating from the GitLab application user

Detection Strategies

Inspect GitLab production_json.log and integrations_json.log for URL fields containing internal IP ranges, localhost, or metadata service hostnames
Correlate authenticated user activity with outbound network flows from the GitLab host to identify anomalous request destinations
Alert on any HTTP request from the GitLab server to cloud provider metadata IPs, which should never occur under normal operation

Monitoring Recommendations

Deploy egress filtering at the network layer and log all blocked outbound requests from the GitLab server for review
Monitor authentication and API activity for low-privileged accounts issuing repeated integration configuration changes
Retain GitLab audit and webhook logs for at least 90 days to support incident investigation

How to Mitigate CVE-2024-9870

Immediate Actions Required

Upgrade GitLab EE to version 17.6.5, 17.7.4, or 17.8.2 or later depending on your release branch
Audit recent integration configurations, webhooks, and imports for suspicious destination URLs
Rotate any credentials or tokens accessible from the GitLab server that may have been exposed via metadata endpoints

Patch Information

GitLab released fixed versions 17.6.5, 17.7.4, and 17.8.2 that remediate the SSRF flaw. Details are available in the GitLab Issue Report. Self-managed instances should upgrade immediately; GitLab.com is patched by the vendor.

Workarounds

Restrict outbound network access from the GitLab server using host-based or network firewalls to block traffic to internal address ranges and metadata IPs
Enable GitLab's built-in outbound request restrictions under Admin Area to deny requests to the local network and loopback addresses
Limit account creation and reduce the number of low-privileged users on internet-facing GitLab instances until patching is complete

bash

# Configuration example: restrict outbound requests via GitLab Admin API
# Requires an administrator personal access token
curl --request PUT \
  --header "PRIVATE-TOKEN: <admin_token>" \
  "https://gitlab.example.com/api/v4/application/settings?outbound_local_requests_whitelist=&allow_local_requests_from_web_hooks_and_services=false&allow_local_requests_from_system_hooks=false"