GitLab is at the heart of many developers’ workflows, giving us a web interface to manage projects and review code. But sometimes bugs pop up that make things a bit … weird. Let’s talk about CVE-2024-6329, discovered in 2024, which made GitLab’s file diff viewer misbehave when faced with encoded paths. This bug spanned a huge range of versions and had some interesting edge-case implications you’ll want to know—especially if you build or manage CI/CD pipelines or code review processes.
This vulnerability affects
- All GitLab CE/EE versions from 8.16 up to but not including 17..6
- GitLab CE/EE 17.1 up to but not including 17.1.4
- GitLab CE/EE 17.2 up to but not including 17.2.2
The issue? If the path in a merge request diff is URL-encoded, the web interface can fail to display the diff. That can mean reviewers don’t see file changes, potentially letting malicious changes sneak past or simply disrupting teamwork.
Official GitLab Advisory:
- https://about.gitlab.com/releases/2024/06/10/security-release-gitlab-17-2-2-released/
Why Does This Matter?
Attackers could create a merge request where the path to the file is encoded in a special way (%2F instead of /, for instance). The UI would not render the diff as expected. That means two big things:
Legit errors are hard to spot.
In security-sensitive environments, that’s a recipe for missed backdoors or supply chain attacks.
Technical Dig: What’s Happening Exactly?
When you upload or change a file, GitLab normally generates a proper diff for code reviewers to inspect.
But GitLab wasn’t always decoding the file path correctly before trying to display the diff
# Pseudo-snippet (simplified)
encoded_path = request.params[:file_path]
real_path = CGI.unescape(encoded_path) # Oops: this was missing or done incorrectly!
diff = get_diff_for(real_path) # or done for the wrong path!
If attackers submit a file whose path is, say, docs/%2Fsecret.txt instead of docs/secret.txt, GitLab’s UI could get bamboozled, and the diff could break—or not show at all.
How Would Someone Exploit It?
Let’s walk through a simple “proof of concept” scenario. (Educational only!)
`sh
git mv docs/secret.txt docs/%2Fsecret.txt
In the GitLab UI, try viewing the diff for the new file.
Result: The diff fails to show—reviewers don’t see the file’s change!
You can test this locally if you’ve got a vulnerable GitLab instance
# Add or rename a file with an encoded path
touch "foo%2Fbar.txt"
git add "foo%2Fbar.txt"
git commit -m "Obfuscated diff"
git push
# Create a MR and look at the diff
Check the browser’s developer tools and examine the HTTP requests to see if the file is listed with a strange path.
Patch and Recommendations
Upgrade!
17.2.2
> Not sure if you’re affected?
> Check your GitLab version:
>
> gitlab-rake gitlab:env:info
> On hosted GitLab.com: This issue was patched promptly.
Mitigation:
Train your team: Recognize suspicious file paths in reviews.
- Automate code review quality: Set up bots to flag encoded/obfuscated file names.
Links and References
- Official GitLab Security Advisory – CVE-2024-6329
- GitLab Issue on path-encoding diff bug
- CVE Record for CVE-2024-6329
- Upgrade Guide
- SecLists – Payloads for path traversal & obfuscation
Final Thoughts
Bugs like CVE-2024-6329 show how creative attackers can be—and why even “simple” encoding errors can lead to real-world risks. The take-home? Keep your tools patched, stay curious, and always review code with a skeptical eye!
*If you’re using a vulnerable GitLab version, update right away and audit your recent merge requests for unusual file paths. It’s one small step to keep your codebase safe.*
Timeline
Published on: 08/08/2024 10:15:09 UTC
Last modified on: 08/08/2024 13:04:18 UTC