CVE-2023-1204
Description
An issue has been discovered in GitLab CE/EE affecting all versions starting from 10.1 before 15.10.8, all versions starting from 15.11 before 15.11.7, all versions starting from 16.0 before 16.0.2. A user could use an unverified email as a public email and commit email by sending a specifically crafted request on user update settings.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab users can bypass email verification to set unverified emails as public or commit email, enabling impersonation.
Vulnerability
An issue in GitLab CE/EE allows a user to set an unverified email address as their public email or commit email. This affects all versions from 10.1 before 15.10.8, 15.11 before 15.11.7, and 16.0 before 16.0.2 [1]. The vulnerability arises because the backend only checks if the public_email and commit_email fields match the user's primary email (user[email]), but does not verify that the email address has been confirmed. By changing the primary email to an unverified address simultaneously with the public and commit email fields, the server accepts the unverified email for those fields [1].
Exploitation
To exploit, an attacker must have a GitLab account and the ability to modify their profile settings. The attacker first adds an unverified email (e.g., a target's email) to their account via /profile/emails. Then, they send a crafted request to update their profile, changing their primary email to that same unverified address, and also setting user[public_email] and user[commit_email] to that address. The server accepts the change because the primary email matches the other fields, but the email has not been verified [1]. This requires no special privileges beyond user-level access to their own profile.
Impact
Successful exploitation allows the attacker to impersonate another user by displaying an unverified email as their public email or commit email. This can lead to social engineering, phishing, or reputational damage, as other users may believe the attacker's account is associated with the spoofed domain or identity [1]. The confidentiality and integrity of user information are affected, as unverified emails are trusted by other users and GitLab features.
Mitigation
GitLab has fixed this issue in versions 15.10.8, 15.11.7, and 16.0.2 [1]. Users running earlier versions should upgrade to a patched release. No workaround is available for affected versions. The vulnerability was reported via HackerOne and is not listed on CISA's Known Exploited Vulnerabilities catalog as of the publication date [1].
AI Insight generated on May 25, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=10.1, <15.10.8 || >=15.11, <15.11.7 || >=16.0, <16.0.2
- Range: >=10.0, <12.9.8
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing verification check for public_email and commit_email fields allows setting them to an unverified email address."
Attack vector
An attacker first adds an unowned email address (e.g., a target company domain) to their account via /profile/emails. They then craft a single PUT request to /-/profile that simultaneously changes user[email] (primary email), user[public_email], and user[commit_email] to that unverified address [ref_id=1]. The backend checks only that public_email and commit_email match the primary email, but because the primary email is changed in the same request, the check passes before the new primary email has been verified [ref_id=1]. This allows the attacker to impersonate a company employee by displaying the unverified email as their public email and to commit under that email without verification.
Affected code
The vulnerability affects the user profile update endpoint (/-/profile) which processes the user[public_email] and user[commit_email] parameters [ref_id=1]. The backend logic that validates these fields only checks if they match the current user[email] value, without verifying that the email address has been confirmed by the user [ref_id=1].
What the fix does
The advisory does not include a patch diff, but the expected fix is described: the backend must validate that public_email and commit_email are checked against verified email addresses, not merely against the current primary email [ref_id=1]. The vulnerability was a regression of a previously fixed issue (GitLab issue #219745) [ref_id=1]. The fix should ensure that when a user updates their public or commit email, the system confirms the email has been verified before accepting the change, preventing bypass via simultaneous primary email change.
Preconditions
- authAttacker must have a valid GitLab account
- inputAttacker must add an unverified email address to their account (e.g., via /profile/emails)
- networkAttacker must be able to send a crafted multipart PUT request to /-/profile
Reproduction
1. Create a GitLab account with your email address. 2. Go to /profile/emails and add an email address you do not own (e.g., target@company.com). 3. Visit /profile and change your primary email to the unowned address, capturing the PUT request. 4. Modify the captured request so that user[email], user[public_email], and user[commit_email] are all set to the unowned address. 5. Forward the request. 6. Visit /profile/emails to confirm the unverified email is now set as public and commit email [ref_id=1].
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
1- GitLab Security Release: 16.0.2, 15.11.7, and 15.10.8GitLab Security Releases · Jun 5, 2023