CVE-2024-8635 Overview
A server-side request forgery (SSRF) vulnerability has been discovered in GitLab Enterprise Edition (EE) affecting multiple versions. This vulnerability allows an authenticated attacker to make unauthorized requests to internal resources by abusing the custom Maven Dependency Proxy URL functionality. The flaw enables attackers to potentially access internal services, metadata endpoints, and other resources that should not be externally accessible.
Critical Impact
Authenticated attackers can leverage the Maven Dependency Proxy URL feature to send crafted requests to internal network resources, potentially exposing sensitive configuration data, internal service endpoints, and cloud metadata services.
Affected Products
- GitLab Enterprise Edition versions 16.8 prior to 17.1.7
- GitLab Enterprise Edition versions 17.2 prior to 17.2.5
- GitLab Enterprise Edition versions 17.3 prior to 17.3.2
Discovery Timeline
- 2024-09-11 - GitLab releases security patch (versions 17.3.2, 17.2.5, 17.1.7)
- 2024-09-12 - CVE-2024-8635 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2024-8635
Vulnerability Analysis
This SSRF vulnerability (CWE-918) exists within GitLab EE's Maven Dependency Proxy feature. The Maven Dependency Proxy is designed to cache Maven packages from external repositories to improve build performance and reliability. However, the implementation fails to properly validate and restrict the URLs that can be specified as custom proxy endpoints.
When a user configures a custom Maven Dependency Proxy URL, the GitLab server processes requests to that URL on behalf of the user. The vulnerability arises because the URL validation does not adequately prevent requests to internal network addresses, localhost, or cloud metadata endpoints. An authenticated attacker with access to configure package settings can exploit this to make the GitLab server send HTTP requests to arbitrary internal resources.
The attack could potentially expose sensitive information such as internal API responses, cloud instance metadata (including credentials on cloud platforms), and other internal service data that is accessible from the GitLab server's network position.
Root Cause
The root cause of this vulnerability is insufficient URL validation in the Maven Dependency Proxy feature. The application does not implement proper allowlist-based URL filtering or adequately block requests to internal network ranges (such as 127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and cloud metadata endpoints like 169.254.169.254). This allows an attacker to specify internal URLs that the server will then access, effectively using the GitLab server as a proxy to reach internal resources.
Attack Vector
The attack requires an authenticated user with permissions to configure Maven Dependency Proxy settings within GitLab EE. The attacker would configure a malicious URL pointing to internal resources as the custom Maven Dependency Proxy endpoint.
When GitLab attempts to proxy Maven requests through this configured URL, it sends HTTP requests to the attacker-specified internal target. The responses from these internal resources may then be returned to the attacker or leaked through error messages, enabling information disclosure from otherwise inaccessible internal services.
The vulnerability is exploited over the network and requires low privilege (authenticated user access), with no user interaction needed beyond the initial configuration. The primary impact is confidentiality breach through unauthorized access to internal data.
Detection Methods for CVE-2024-8635
Indicators of Compromise
- Unusual Maven Dependency Proxy URL configurations pointing to internal IP addresses (e.g., 127.0.0.1, 10.x.x.x, 172.16.x.x, 192.168.x.x)
- Configuration entries referencing cloud metadata endpoints such as 169.254.169.254
- Unexpected outbound requests from the GitLab server to internal services
- Audit log entries showing repeated modification of Maven Dependency Proxy settings
Detection Strategies
- Review GitLab audit logs for changes to package registry and dependency proxy configurations
- Monitor network traffic from GitLab servers for requests to internal IP ranges that are not expected
- Implement network segmentation monitoring to detect GitLab instances attempting to access restricted internal services
- Deploy web application firewall (WAF) rules to detect and alert on SSRF patterns in configuration inputs
Monitoring Recommendations
- Enable comprehensive audit logging in GitLab to track all configuration changes to package management features
- Set up alerts for any Maven Dependency Proxy URL configurations containing RFC 1918 private addresses or localhost references
- Monitor GitLab server egress traffic for anomalous requests to internal network segments
- Regularly review dependency proxy configurations across all projects for suspicious entries
How to Mitigate CVE-2024-8635
Immediate Actions Required
- Upgrade GitLab EE to patched versions: 17.3.2, 17.2.5, or 17.1.7 depending on your current version branch
- Audit all existing Maven Dependency Proxy URL configurations for potentially malicious entries
- Review access controls and limit which users can modify package registry settings
- Implement network-level restrictions on outbound connections from GitLab servers where possible
Patch Information
GitLab has released patched versions that address this SSRF vulnerability. Organizations should upgrade to the following versions based on their current deployment:
- For GitLab 17.3.x: Upgrade to version 17.3.2 or later
- For GitLab 17.2.x: Upgrade to version 17.2.5 or later
- For GitLab 17.1.x: Upgrade to version 17.1.7 or later
For detailed release information, see the GitLab Patch Release Announcement and the GitLab Issue #455273 for technical details.
Workarounds
- If immediate patching is not possible, restrict access to Maven Dependency Proxy configuration to only trusted administrators
- Implement network-level egress filtering to prevent the GitLab server from accessing internal metadata endpoints and sensitive internal services
- Use a reverse proxy or WAF in front of GitLab to inspect and block requests containing internal IP addresses in proxy configurations
- Consider temporarily disabling the Maven Dependency Proxy feature if it is not critical to your workflows until the patch can be applied
# Network-level mitigation: Block GitLab from accessing cloud metadata endpoint
# Example iptables rule for Linux-based GitLab installations
iptables -A OUTPUT -d 169.254.169.254 -j DROP
# Verify GitLab version to confirm patch status
gitlab-rake gitlab:env:info | grep "GitLab version"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


