CVE-2024-4024 is a high severity account takeover flaw in GitLab CE and EE, scored 7.3 by NVD. Under certain conditions an attacker with their own Bitbucket credentials may take over a GitLab account linked to another user's Bitbucket account. Upgrade to 16.9.6, 16.10.4 or 16.11.1, or later.
What's affected
The record gives three affected ranges: all versions from 7.8 before 16.9.6, all versions from 16.10 before 16.10.4, and all versions from 16.11 before 16.11.1. The fixed versions are therefore 16.9.6, 16.10.4 and 16.11.1. The record applies to both Community and Enterprise editions.
The description limits the flaw to instances where Bitbucket is used as an OAuth 2.0 provider on GitLab. If you never enabled Bitbucket sign in, the scenario does not apply, though the upgrade is still worth doing. The record links a GitLab issue, which this write-up did not fetch, so read GitLab's own release post for any extra detail.
The vector needs low privileges and user interaction. The KEV flag is false and the record reports no exploitation.
The NVD record is dated 2024-04-25 and carries the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N, a score of 7.3 (High). Weakness class: CWE-302, CWE-287.
How to check if you're exposed
Find your GitLab version in the Help page of the web interface, or on the host.
sudo gitlab-rake gitlab:env:info
Compare it with the three fixed versions for your release line. Then check whether Bitbucket is enabled as a sign in provider. An administrator can look under the OmniAuth settings in the Admin area, or in the omniauth section of the configuration file.
sudo grep -n "bitbucket" /etc/gitlab/gitlab.rb
If Bitbucket appears as an enabled provider, treat the instance as in scope.
What to do now
- Find the version of every self managed GitLab instance.
- Upgrade to 16.9.6, 16.10.4, 16.11.1 or later, matching your release line.
- Check whether Bitbucket OAuth sign in is enabled, and disable it if you do not need it.
- Review recently linked external identities and look for accounts whose Bitbucket link changed unexpectedly.
- Require two factor authentication and review active sessions for sensitive accounts.
Why it matters
The record lists improper authentication, CWE-287, and the related CWE-302, which is an authentication bypass by assumed immutable data. In an OAuth sign in flow, the identity provided by the external service has to be bound firmly to one local account. When that link can be confused, a person who controls one identity might land in another person's account.
A source code platform holds repositories, pipeline secrets and deploy keys, so an account takeover there can reach production. Keep self managed GitLab on a supported release and review which external sign in providers you really use.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Am I affected if I do not use Bitbucket sign in?
The description limits the flaw to instances that use Bitbucket as an OAuth 2.0 provider. Upgrading is still sensible.
Which version fixes it?
16.9.6, 16.10.4 or 16.11.1, depending on your release line.
Sources
Last reviewed: 19 October 2026.
