In June 2024, a critical vulnerability was reported in GitLab, the popular DevOps platform. CVE-2024-6446 is an "Open Redirect" issue affecting multiple versions of GitLab. By cleverly crafting a URL, an attacker can trick users into trusting a malicious application that looks like a legitimate GitLab page. This flaw could pave the way for powerful phishing scams and session hijacking.

Let’s break down the issue, see how the exploit works, and understand how to stay safe. If you use GitLab versions 17.1. to 17.1.7, 17.2. to 17.2.4, or 17.3. to 17.3.1, this post is a must-read.

17.3. → 17.3.1

This bug allows attackers to craft a special link. If a victim clicks this link, their browser will be redirected to an attacker-controlled site—or even worse, the attacker may design a site that resembles the actual GitLab login page.

Sensitive data, such as authentication tokens, could be exposed.

GitLab is used by tech teams, open source maintainers, and companies everywhere. A compromise could have serious consequences.

How the Exploit Works (Step by Step)

Suppose you’re sending someone a link to your GitLab project. An attacker can modify the URL and slip in a malicious redirect, so the user unknowingly visits any website the attacker wants.

https://gitlab.example.com/users/sign_in?redirect_to=https://attacker.com/malicious

When a victim clicks that link, instead of being taken to their GitLab dashboard after logging in, they’re quietly redirected to attacker.com/malicious—where a fake GitLab login form could harvest credentials.

Imagine an email

> Please log in to approve your merge request:
> https://gitlab.yourcompany.com/users/sign_in?redirect_to=https://evil.phisher.com/fake_login

After logging in (or sometimes even before), the victim is sent to the attacker’s site.

Vulnerable Code Snippet (Hypothetical)

The actual vulnerable code exists deep inside GitLab’s source, but the problem is similar to this simple Python/Flask example:

from flask import Flask, request, redirect

app = Flask(__name__)

@app.route('/login')
def login():
    next_url = request.args.get('redirect_to', '/')
    # BAD: Directly redirecting to user-controlled link
    return redirect(next_url)

What’s wrong here?
There is no validation of the redirect_to parameter. If an attacker supplies their own URL, users can be sent anywhere after login.

Safer Version (with Allowlist)

from urllib.parse import urlparse

def is_safe_url(target):
    # Only allow redirects to local paths (not full URLs)
    ref_url = urlparse(request.host_url)
    test_url = urlparse(urlparse(target).path)
    return test_url.scheme in ('', 'http', 'https') and \
           ref_url.netloc == test_url.netloc

@app.route('/login')
def login():
    next_url = request.args.get('redirect_to', '/')
    if not is_safe_url(next_url):
        next_url = '/'
    return redirect(next_url)

`

https://badguy.com/fake" rel="nofollow">https://your.gitlab.site/users/sign_in?redirect_to=https://badguy.com/fake

Victim sees the normal GitLab login page (if not logged in).

- On login, or even after, they are bounced to https://badguy.com/fake.

Real-World Scenarios

- Corporate GitLab: Employees are lured with “priority bug fix” emails, leading to credential theft and possibly source code leaks or ransomware implants.

Fixed in: 17.1.8, 17.2.5, 17.3.2+

- See: GitLab Security Release Blog
- Official security notes: GitLab HackerOne disclosure (Replace XXXXXX when disclosed)

References

- GitLab CVE-2024-6446 Advisory
- NVD Details for CVE-2024-6446
- OWASP: Open Redirects and Forwards

Conclusion

CVE-2024-6446 proves that even tech-savvy users and admins are at risk if platforms they trust let attackers control redirects. Always keep GitLab updated and remind your teams about spoofed login attempts. With simple awareness and patching, you can stay a step ahead of attackers hoping to use open redirects to their advantage.

Timeline

Published on: 09/12/2024 17:15:05 UTC
Last modified on: 09/14/2024 15:17:11 UTC