CVE-2023-5117 - Unauthorized File Access in GitLab CE/EE through Confidential Issue Uploads

Published: June 2024

Summary

If you’re using GitLab Community Edition (CE) or Enterprise Edition (EE) before version 17.6., you could be affected by a major file access vulnerability. This security issue, tracked as CVE-2023-5117, lets anyone with a direct file link access files uploaded to comments on confidential issues and epics in public projects — *no login required.*

This post explains what the vulnerability is, how it works, gives code examples, and shows how it can be exploited, all in clear, simple language.

What Is CVE-2023-5117?

CVE-2023-5117 is a security flaw that exposes private files uploaded to otherwise ‘confidential’ discussion threads in public GitLab projects. When you upload a file (like a screenshot or document) to a comment in a confidential issue or epic, GitLab is supposed to keep it private. But in affected versions, anyone who has the direct link to the file can access it — even if they aren’t logged in.

When you upload a file in a confidential issue or epic, GitLab gives it a unique URL like this

https://gitlab.example.com/uploads/ef/21/randomstring/secret.docx

In the affected GitLab versions, the server doesn't check if the person requesting the file is allowed to see the confidential item it’s attached to. If the person knows (or guesses) the URL, the file gets served to them — even if they’re not logged in.

Exploit Example

Let’s say Alice reports a security bug through a confidential issue and uploads a file secret_screenshot.png. Now, someone (Bob) who’s not part of the project somehow gets the direct URL (maybe from browser history, logs, or a leaked link). Even without logging in, Bob can load the file in his browser.

Here’s a Python example showing how to "exploit" this

import requests

# Direct URL to the uploaded confidential file
file_url = 'https://gitlab.example.com/uploads/ef/21/randomstring/secret_screenshot.png';

# No authentication used
response = requests.get(file_url)

if response.status_code == 200:
    print("File content:")
    print(response.content)
else:
    print(f"Failed! Status code: {response.status_code}")

Result: If the GitLab server is vulnerable, Bob gets the file contents.

Responsible Disclosure & Patch

This bug was responsibly reported to GitLab, and a fix shipped in version 17.6.. You should upgrade your GitLab instance immediately if you haven’t already.

Upgrade guide:
- GitLab 17.6. release notes

Patched behavior: The system now properly checks permissions before serving uploaded files. Unauthorized users (including not-logged-in visitors) will get a 404 error if they try to access a confidential issue file.

References

- GitLab Security Advisory for CVE-2023-5117
- About GitLab - Security Releases
- Mitre CVE page for CVE-2023-5117

Conclusion

CVE-2023-5117 is a serious oversight that could risk leaking your most private attachments if you’re not running an up-to-date GitLab installation. Make sure you’re on 17.6. or later. If in doubt, test with a dummy confidential issue, upload a file, and try to view it in a private/incognito browser window (without being logged in).

Stay safe and keep your code secure!

*Did this help? Share your experience or questions in the comments!*

Timeline

Published on: 12/25/2024 15:15:05 UTC