CVE-2022-4335 - Blind SSRF in GitLab EE Let Attackers Connect to localhost (Explained)

---

GitLab is one of the most popular tools for source code management and DevOps workflows, used widely by development teams and enterprises. Unfortunately, even robust software can have dangerous bugs. One of those critical issues surfaced at the end of 2022: CVE-2022-4335, a blind SSRF (Server-Side Request Forgery) vulnerability affecting all versions of GitLab EE (Enterprise Edition) prior to 15.4.6, 15.5 before 15.5.5, and 15.6 before 15.6.1.

In this article, we break down what the bug is, how it can be exploited, what attackers could do with it, and how it was fixed. Whether you run GitLab at work or just want to understand SSRF risks in modern platforms, this is a must-read.

What is CVE-2022-4335? The Vulnerability in Simple Terms

CVE-2022-4335 is a blind SSRF vulnerability in GitLab EE. With SSRF, attackers can trick the application into making HTTP / web requests on its own server’s behalf — potentially exposing internal services (think: databases, metadata endpoints, things not usually accessible from the internet).

Blind SSRF means the attacker can’t see the response directly, but they can control where GitLab makes the request.

Where Does it Happen in GitLab?

The vulnerable part was in a feature allowing users to validate URLs — for instance, when configuring integrations or providing webhooks.

The input URL was not properly filtered: GitLab did not block access to protected destinations like localhost (127...1), internal network IPs, or cloud instance metadata endpoints. As a result, if an attacker could input a URL into the functionality, GitLab would connect from the server to wherever the attacker specified.

- Information Disclosure: An attacker might trigger requests to internal company applications or metadata endpoints (think AWS, Google Cloud, Azure) and harvest sensitive information.
- Pivot to RCE: If the localhost service accepts requests (like a debug server, Redis, or Jenkins instance), SSRF can sometimes be uprated into Remote Code Execution or internal DoS.
- Lateral Movement: Once SSRF inside the server is possible, attackers often try to access additional protected resources, mapping the environment from the inside.

The Exploit: How an Attacker Could Use It

This attack requires the attacker to be logged in and able to access a feature that makes backend requests using a user-supplied URL. In the case of GitLab, that was as simple as configuring integration endpoints.

1. Attacker Crafts a Malicious Integration

Suppose there is a webhook configuration in GitLab where the user sets the destination URL for an integration.

The attacker enters

http://127...1:631/

This points GitLab’s internal validation to the server’s own local port 631 (on many Linux systems, this is the CUPS print service). The attacker could try different internal IPs and ports, like http://169.254.169.254/ to reach cloud instance metadata.

2. What actually happens in code (simplified)

require 'net/http'

def validate_integration_url(url)
  # GitLab (pre-patch) tried a simple GET request without any filtering
  uri = URI.parse(url)
  response = Net::HTTP.get_response(uri)
  return response.code == '200'
end

There is no block on localhost, internal, or cloud metadata IPs!

Even though attackers couldn’t see the actual web service response, they could infer results based on:

If the integration was created or failed validation.

This is why it's called blind SSRF: direct response is not returned, but indirect signals can often be enough.

This allowed any attacker with low privileges (just enough to add a webhook or integration) to

- Probe for open ports and services on the internal server and network — finding possible new attack surfaces.

What did the fix do?

It added server-side filtering and validation to prevent requests to localhost, private IP ranges, and well-known metadata endpoints. Any attempt to input such a URL now returns an error.

Reference to Patch

- GitLab release notes: 15.4.6
- CVE-2022-4335 on GitLab Advisory

Update ASAP: If you’re running a vulnerable version, upgrade NOW.

2. Input Filtering: Always validate and restrict input URLs server-side, blocking outbound requests to sensitive endpoints.

Final Thoughts

CVE-2022-4335 is a classic example of how even small validation oversights can lead to dangerous security holes in powerful enterprise tools. If in doubt, patch early and review how your app lets users enter URLs. Blind SSRF can be used as a stepping stone for much bigger attacks, and shouldn’t be underestimated.

Timeline

Published on: 01/27/2023 18:15:00 UTC
Last modified on: 02/06/2023 18:37:00 UTC