GitLab Password Reset Flaw Enables Account Takeover

What to do

1. Check your version (Admin Area > Dashboard, or `sudo gitlab-rake gitlab:env:info`) and upgrade to a fixed release or any current supported version.
2. Enforce two-factor authentication for all users, starting with administrators.
3. If you use an external identity provider, disable password authentication in sign-in restrictions, which also disables password reset.
4. Search production_json.log and audit_json.log for multi-address password reset requests since May 2023.
5. For any account that was reset unexpectedly, rotate the password, review SSH keys, personal access tokens and recent pushes, and rotate CI/CD secrets it could reach.

How to check if you are affected or compromised

• In gitlab-rails/production_json.log, look for requests to /users/password where params.value.email is a JSON array with multiple addresses.
• In gitlab-rails/audit_json.log, look for meta.caller_id PasswordsController#create with target_details containing an array of multiple addresses.
• Review unexpected password-reset emails, new email addresses or new access tokens on admin accounts.

What happened#

On January 11, 2024, GitLab shipped a critical security release fixing CVE-2023-7028: password reset emails could be delivered to an email address the account had never verified. An attacker who knows a target's account email can submit a reset request that also lists an address they control, receive the reset link, set a new password and log in. GitLab rated it CVSS 10.0. The flaw was introduced in 16.1.0 on May 1, 2023, so it was present for about eight months.

No interaction from the victim is needed, which is why press called it "zero-click." Around 13 days after the patch, Shadowserver counted 5,379 vulnerable instances still online, BleepingComputer reported. On May 1, 2024, CISA added it to the Known Exploited Vulnerabilities catalog based on evidence of active exploitation. It remains in the KEV catalog as of October 21, 2026; its ransomware-use field reads "Unknown."

Who is affected#

Self-managed GitLab Community and Enterprise Edition from 16.1 through 16.7.1. Per the NVD record, vulnerable ranges are 16.1 before 16.1.6, 16.2 before 16.2.9, 16.3 before 16.3.7, 16.4 before 16.4.5, 16.5 before 16.5.6, 16.6 before 16.6.4 and 16.7 before 16.7.2. GitLab said it found no abuse on GitLab.com or GitLab Dedicated. Versions before 16.1 never had the bug.

Scores differ by source: GitLab rates it 10.0 (scope changed), while NVD's own assessment is 9.8. Either way, it is critical.

Do you really need to act?#

If you run an affected version, yes, immediately. Exploitation is trivial, needs no credentials, and a GitLab admin account typically controls source code, CI/CD variables and deploy keys, which makes this a supply-chain entry point and not just a single-account problem.

Two things limit the damage. First, two-factor authentication stops the takeover: the attacker can reset the password but cannot complete login without the second factor. Second, instances that use an external identity provider and have disabled password authentication are not exposed, because that setting also disables password reset. If you are on a supported release from the last two years, you already have the fix.

What to do now#

1. Confirm your version in Admin Area, or run sudo gitlab-rake gitlab:env:info. Upgrade to a fixed version or any current release. GitLab later advised 16.7.3, 16.6.5, 16.5.7 or newer because of a database migration issue in the first patch set.
2. Enforce 2FA for all users, administrators first.
3. If SSO is your only intended login path, disable password authentication in sign-in restrictions.
4. Hunt in logs (below) for any time since May 2023 that the instance ran an affected version.
5. For any account reset unexpectedly: rotate its password, review SSH keys, personal access tokens and recent commits, and rotate any CI/CD secrets that account could read.

How to tell if you were hit#

GitLab published two log indicators for self-managed instances. In gitlab-rails/production_json.log, look for requests to /users/password whose params.value.email is a JSON array with more than one address. In gitlab-rails/audit_json.log, look for meta.caller_id of PasswordsController#create where target_details is an array of multiple addresses. For example: sudo grep '/users/password' /var/log/gitlab/gitlab-rails/production_json.log | grep -E '"email":\["[^]]*","'. Also check for new emails, tokens or SSH keys added to privileged accounts.

Timeline#

• May 1, 2023 — Bug introduced in GitLab 16.1.0.
• Jan 11, 2024 — GitLab releases 16.7.2, 16.6.4, 16.5.6 and backports.
• Jan 24, 2024 — Shadowserver reports 5,379 exposed vulnerable instances.
• May 1, 2024 — CISA adds CVE-2023-7028 to KEV, with a May 22 deadline for federal agencies.
• Oct 21, 2026 — Still listed in KEV; brief updated.

Vulnerability records

• CVE-2023-7028 · KEV 2024-05-01 · An issue has been discovered in GitLab CE/EE affecting all versions from 16.1 prior to 16.1.6, 16.2 prior to 16.2.9, 16.3 prior to 16.3.7, 16.4 prior to…

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. GitLab — GitLab Critical Security Release: 16.7.2, 16.6.4, 16.5.6 docs.gitlab.com
2. NVD — CVE-2023-7028 nvd.nist.gov
3. CISA — CISA Adds One Known Exploited Vulnerability to Catalog (May 1, 2024) cisa.gov
4. CISA — Known Exploited Vulnerabilities Catalog cisa.gov

Coverage and analysis

1. BleepingComputer — Over 5,300 GitLab servers exposed to zero-click account takeover attacks bleepingcomputer.com