⚠ Reference material — not professional advice. Test in staging, back up first, verify against your specific version. Use your own judgment for your environment.
● Critical · CVSS 10.0 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2023-7028: GitLab Account Takeover via Password Reset

*By Sai Kiran Pandrala*

⚡ At a glance
SeverityCVSS 10.0, Critical
Actively exploited?Yes, listed in CISA KEV (added 2024-05-01)
AffectedGitLab CE/EE 16.1.0 → 16.1.5, 16.2.0 → 16.2.8, 16.3.0 → 16.3.6, 16.4.0 → 16.4.4, 16.5.0 → 16.5.5, 16.6.0 → 16.6.3, 16.7.0 → 16.7.1
Fixed in16.7.2, 16.6.4, 16.5.6, 16.4.5, 16.3.7, 16.2.9, 16.1.6 (and 16.7.2+ on all newer trains)
Type (CWE)CWE-640: Weak Password Recovery Mechanism

⚠️ Patch immediately and audit. CISA added this to KEV on May 1, 2024. The exploitation pattern is dead simple, runs unauthenticated, and bypasses email-confirmation entirely.

What is CVE-2023-7028?

GitLab's password-reset flow accepts a list of email addresses for the target user. Before the patch, GitLab would send the password reset email to all addresses in the list, not just verified ones belonging to the target. An attacker initiating a password reset for any account could append their own attacker-controlled email address, receive the reset link, and take over the account.

If the target account has 2FA enabled, the password reset alone doesn't bypass it, but the attacker still has the password, which is enough use in many real-world attack chains (SSH key upload, personal access token creation, organization-wide enumeration). For accounts without 2FA, takeover is complete.

The most painful real-world impact: any administrator account on a vulnerable self-managed GitLab instance can be taken over by anyone on the internet that can reach the login page.

Am I affected?

You are affected if you run self-managed GitLab Community Edition or Enterprise Edition at any of these versions:

GitLab.com (the SaaS) was patched by GitLab Inc. on the disclosure date. If you use GitLab.com only, you do not need to act, but check your account login audit log for unexpected entries dated December 2023 to January 2024.

Check your version:


# Vendor advisory: https://gitlab.com/gitlab-org/gitlab/-/issues/436084
# GitLab Omnibus / package install
sudo gitlab-rake gitlab:env:info | grep "GitLab information"

# Docker
docker exec -it <gitlab-container> gitlab-rake gitlab:env:info | grep Version

# Helm
kubectl exec -n gitlab <gitlab-webservice-pod> -- gitlab-rake gitlab:env:info | grep Version

Or browse to https://<your-gitlab>/help while logged in as admin, the version is on the page.

How to fix CVE-2023-7028

  1. Upgrade to a patched version. The minimum versions are: 16.7.2, 16.6.4, 16.5.6, 16.4.5, 16.3.7, 16.2.9, or 16.1.6, pick the one matching your current train. Newer releases (16.8+, 16.9+, all 17.x, all 18.x) include the fix.
  1. Omnibus package upgrade (Debian/Ubuntu/RHEL):

   sudo apt-get update && sudo apt-get install gitlab-ee=16.7.2-ee.0
   # or
   sudo yum install gitlab-ee-16.7.2-ee.0.el8

Pin the exact patched version to avoid jumping to a newer major that may have unrelated breaking changes.

  1. Docker upgrade: pull the new image, stop the running container, start the new one with the same volume mounts:

   docker pull gitlab/gitlab-ee:16.7.2-ee.0
   docker stop gitlab && docker rm gitlab
   docker run -d --name gitlab -v /srv/gitlab/config:/etc/gitlab -v /srv/gitlab/data:/var/opt/gitlab gitlab/gitlab-ee:16.7.2-ee.0
  1. Helm chart upgrade:

   helm repo update
   helm upgrade gitlab gitlab/gitlab --version <chart-version-for-16.7.2>
  1. After upgrade, force a password reset for every administrator and any account flagged in audit logs. See verification section below for the audit query.

If you can't patch immediately

GitLab's advisory does not list a feature-toggle workaround for CVE-2023-7028. The vulnerable code path is in the core password reset controller. To reduce exposure if patching has to wait:

How to verify the fix worked

After upgrade, confirm the running version:


gitlab-rake gitlab:env:info | grep Version

The Version line must be at or above the patched build for your train.

Now run the audit GitLab recommends:


-- via gitlab-rails dbconsole
SELECT id, email, created_at FROM user_emails WHERE created_at > '2023-12-01';

Look for email addresses on admin accounts that you don't recognize. Cross-reference against audit_events for the same period:


SELECT * FROM audit_events
WHERE created_at > '2023-12-01'
  AND details ILIKE '%password%'
ORDER BY created_at DESC;

If you find suspicious entries, force-reset the affected accounts, rotate any personal access tokens they created, and check their SSH keys.

Frequently asked questions

Other vulnerabilities in the same area that are worth patching alongside this one:

Was CVE-2023-7028 actually exploited?

Yes. CISA's KEV listing on May 1, 2024 documents confirmed in-the-wild exploitation. The exploit is trivial, so any unpatched public-facing GitLab from January 2024 onward should be assumed compromised until proven otherwise.

Does 2FA protect against this?

2FA does not block the initial password reset. The attacker still gets the new password. 2FA does prevent them from logging in directly with just that password, but they can still craft phishing payloads or attempt session-stealing using the credential.

Is GitLab.com affected?

GitLab Inc. patched the SaaS environment on the disclosure date. CVE-2023-7028 is a vulnerability in the GitLab codebase, so any unpatched self-managed instance is affected; SaaS users are not.

References

*This guide was assembled from the official GitLab security release, the NVD record, and CISA KEV listing on 2026-05-25. Always confirm against GitLab's advisory before applying changes in production.*