---
title: "GitLab Password Reset Flaw Enables Account Takeover"
url: https://erroneo.us/security/briefs/gitlab-password-reset-account-takeover/
description: "CVE-2023-7028: GitLab CE/EE 16.1-16.7 sent reset emails to unverified addresses. Fixed in 16.7.2 and backports. Exploited, in CISA KEV. Act now if unpatched."
type: security-brief
section: "Security Digest"
date_published: 2024-01-11
date_modified: 2026-10-21
publisher: erroneo.us
author: erroneo.us Security Desk
verdict: "Act now"
cves: ["CVE-2023-7028"]
severity: "critical"
exploited: "in-the-wild"
kev: true
license: All rights reserved. Quote with attribution and a link.
---

# GitLab Password Reset Flaw Enables Account Takeover

**Verdict: Act now.** Any self-managed GitLab still on 16.1 through 16.7.1 lets anyone take over accounts without 2FA by email alone; upgrade immediately and turn on 2FA.

- **Who must act:** Admins of self-managed GitLab CE/EE instances running 16.1.0 through any version below the fixed releases, especially internet-facing ones.
- **Who can relax:** GitLab.com and GitLab Dedicated users, instances older than 16.1 or already upgraded, and accounts protected by 2FA (takeover via this bug requires the password step).
- **Affected:** GitLab CE/EE 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; 16.7 before 16.7.2
- **Fixed:** 16.1.6; 16.2.9; 16.3.7; 16.4.5; 16.5.6; 16.6.4; 16.7.2 (GitLab recommends 16.5.7, 16.6.5, 16.7.3 or newer because of a migration fix)
- **CVEs:** CVE-2023-7028
- **CISA KEV:** yes · **Exploitation:** Exploited in the wild

## 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

- 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](https://docs.gitlab.com/releases/patches/patch-release-gitlab-16-7-2-released/) 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](https://www.bleepingcomputer.com/news/security/over-5-300-gitlab-servers-exposed-to-zero-click-account-takeover-attacks/). On May 1, 2024, CISA [added it to the Known Exploited Vulnerabilities catalog](https://www.cisa.gov/news-events/alerts/2024/05/01/cisa-adds-one-known-exploited-vulnerability-catalog) based on evidence of active exploitation. It remains in the [KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-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](https://nvd.nist.gov/vuln/detail/CVE-2023-7028), 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.

## Sources

1. [GitLab — GitLab Critical Security Release: 16.7.2, 16.6.4, 16.5.6](https://docs.gitlab.com/releases/patches/patch-release-gitlab-16-7-2-released/)
2. [NVD — CVE-2023-7028](https://nvd.nist.gov/vuln/detail/CVE-2023-7028)
3. [CISA — CISA Adds One Known Exploited Vulnerability to Catalog (May 1, 2024)](https://www.cisa.gov/news-events/alerts/2024/05/01/cisa-adds-one-known-exploited-vulnerability-catalog)
4. [CISA — Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
5. [BleepingComputer — Over 5,300 GitLab servers exposed to zero-click account takeover attacks](https://www.bleepingcomputer.com/news/security/over-5-300-gitlab-servers-exposed-to-zero-click-account-takeover-attacks/)

---
Source page: https://erroneo.us/security/briefs/gitlab-password-reset-account-takeover/ · Security Digest: https://erroneo.us/security/ · More: https://erroneo.us/llms.txt