CVE-2022-4201 - Exploiting a Blind SSRF in GitLab Runner Configuration (Versions 11.3 to 15.6)

_CVE-2022-4201_ is a blind Server-Side Request Forgery (SSRF) vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE). Specifically, the bug can be abused when configuring a new GitLab Runner. Attackers can convince GitLab to make network requests to arbitrary addresses, including internal network resources that should never be reachable from the outside—for example, localhost.

This vulnerability affects many versions of GitLab, covering releases all the way from 11.3 up to and including 15.4.5, 15.5.4, and 15.6. (fixed in 15.4.6, 15.5.5, and 15.6.1).

Below we’ll break down how this bug works, why it’s serious, and how an attacker could exploit it.

> Official advisory:
> GitLab Critical Security Release: 15.6.1, 15.5.5, and 15.4.6

SSRF (Server-Side Request Forgery) is a vulnerability that lets an attacker make arbitrary HTTP requests from a vulnerable server. The “blind” part means the attacker doesn’t see the response, but can infer behavior from side effects (timing, system changes, etc.).

How Does CVE-2022-4201 Work in GitLab?

The issue lives in the GitLab Runner registration process. When adding a new Runner (which is used for CI/CD pipelines), GitLab tries to “verify” the provided Runner URL by making a backend request.

If an attacker is allowed to define the Runner URL, they can set it to anything—including sensitive internal addresses (127...1, localhost, 169.254.169.254, etc.).

Attacker has access to GitLab with permissions to register a Runner.

2. They go to Admin > CI/CD > Runners.
3. They start registering a new Runner and set the address to something internal, e.g., http://localhost:808.
4. GitLab (the backend server) connects out to the supplied address, even if it’s a local service, exposing internal resources.

Exploit Example

Let’s walk through a practical (and simplified) exploitation scenario.

Malicious Runner Registration

- URL: http://127...1:6379

Description: Evil SSRF test

This causes GitLab to make a backend request to its own Redis instance.

Step 2: Observe Side Effects

Because this is a _blind_ SSRF, attackers might not immediately see a response. But they could use timing, error messages, or even cause effect on the internal service.

In some setups, error messages might leak information

# Pseudocode: what the backend might log or reveal
Failed to register runner: cannot connect to Redis at 127...1:6379

Or, if the address is up (like an internal metadata service), it might log successful connections.

If GitLab is running in a cloud like AWS, attackers could probe

- http://169.254.169.254/latest/meta-data/

If the registration is successful, the runner might fetch credentials or other sensitive data. Although the data is not directly returned, it could be logged somewhere or used to aid further attacks.

Code Snippet: Simulating SSRF in GitLab Runner Registration

Below is an illustrative Python snippet of how a vulnerable backend might “verify” a runner URL without filtering internal addresses:

import requests

def register_runner(runner_url):
    # Vulnerable: no checks for internal addresses
    try:
        response = requests.get(runner_url, timeout=2)
        if response.status_code == 200:
            print("Runner registration succeeded!")
        else:
            print("Runner registration failed.")
    except Exception as e:
        print(f"Error connecting to runner: {e}")

# Attacker's URL
register_runner("http://127...1:808";)

Moral of the story: If you don't filter addresses, attackers can trick you into talking to local/internal services.

Attack internal-only APIs or admin tools.

- Access AWS/GCP metadata and potentially steal credentials.

Who's at risk?

- All GitLab CE/EE users running affected versions where untrusted users can register runners.

References

- GitLab advisory (official)
- NIST NVD entry
- GitLab bug issue tracker
- PortSwigger: What is SSRF?

Summary

_CVE-2022-4201_ is a critical blind SSRF affecting GitLab CE/EE that could let attackers probe and attack internal services. The core vulnerability is that runner registration did not prevent backend requests to internal addresses, a common and dangerous SSRF vector.

> Upgrade now. Don't wait for attackers to find your internal services before you do!

Stay safe, keep your CI/CD secure, and always restrict where user-supplied URLs can connect!

Timeline

Published on: 01/27/2023 22:15:00 UTC
Last modified on: 02/06/2023 15:23:00 UTC

Understanding SSRF and Why Blind SSRF Matters