CVE-2024-1539 - How a GitLab API Info Leak Let Banned Group Members See Issue Updates

---

Intro: What is CVE-2024-1539?

CVE-2024-1539 is a newly discovered vulnerability in GitLab's Enterprise Edition (EE) that impacts a wide range of versions:

16.11 up to 16.11.1

If you’re running any of these, your system was (or may be) at risk.

This vulnerability allowed *banned group members*—users who were supposed to lose all access—to still access updates to issues using the GitLab API. Basically, if someone got banned from a group, they could still see what was happening with issues, despite being locked out. That’s a big deal for teams handling sensitive data, internal discussions, or planning in private repositories.

How Did It Happen? (The Simple Version)

When an admin *banned* a member from a group, the web interface made sure they couldn’t see group content any more. But the API didn’t have proper access controls in some places. Specifically, the API would sometimes still treat a banned group member as legit—letting them pull updates to issues (like new comments or status changes), even though they shouldn’t see anything.

The vulnerability made it possible for bad actors (for example, former employees or kicked-out collaborators) to still follow private development or company discussions.

Who Is Impacted

The bug affects GitLab EE only, not the free Community Edition (CE).

If you’re unsure of your version, run

gitlab-rake gitlab:env:info

The leak happens through GitLab’s REST API, especially endpoints like

- GET /groups/:id/issues
- GET /projects/:id/issues
- GET /projects/:id/issues/:issue_iid/notes

...and possibly others that expose issue-related events

If a banned user still has a valid personal access token (PAT), they could send requests directly to the API and keep reading updates.

What the Exploit Looks Like

A banned user (say with user_id=123) gets banned from group_id=456. They retain their access token.

With a simple curl command, they can still get issue updates

curl --header "PRIVATE-TOKEN: <their_token>" \
  https://<gitlab-instance>/api/v4/groups/456/issues

Despite being banned, GitLab would return a JSON list of recent issues and updates. With more calls, they could view issue details or comments.

Sample Response

[
  {
    "id": 789,
    "iid": 12,
    "title": "Deploy staging environment",
    "updated_at": "2024-05-12T15:47:00Z"
    // ...more fields
  }
]

The GitLab team documented and fixed the issue

- GitLab Security Release 16.11.2, 16.10.5, and 16.9.7
- The CVE page on GitLab advisory

Their notes: It’s rated as a medium* severity, but could be higher if you have sensitive projects.

Look for users with lingering personal access tokens among banned group members.

3. Test your API by creating a banned account and seeing if it can still access group issue endpoints.

16.9.7 or later (if you’re still on 16.9.x branch)

Instructions: GitLab Upgrading Documentation

Consider also rotating personal access tokens for accounts belonging to banned members.

Exploit Reproduction Example

> Here is a step-by-step you can test on a non-production (test) GitLab EE instance.

curl --header "PRIVATE-TOKEN:" \

https://gitlab.example.com/api/v4/groups//issues

`

5. Expected: No access (HTTP 403/FORBIDDEN).

More Resources

- GitLab’s full security advisory for CVE-2024-1539
- GitLab EE Documentation
- Official Release Notes

Final Notes

This vulnerability is a reminder that APIs need the same (or even stricter) access controls as web UIs. Banning or deleting a user isn’t always simple—tokens and other credentials can linger. Always test, monitor, and review permissions, and keep your critical platforms like GitLab up to date.

If you operate a GitLab EE instance, upgrade now! Otherwise, a former user—even if banned—could be spying on your progress.


*Written exclusively for this request. Share only with proper credit.*

Timeline

Published on: 02/05/2025 10:15:22 UTC