CVE-2026-0723: GitLab 2FA Authentication Bypass Vulnerability

CVE-2026-0723 Overview

A significant authentication bypass vulnerability has been identified in GitLab CE/EE that allows attackers to circumvent two-factor authentication (2FA) protections. The vulnerability affects all versions from 18.6 before 18.6.4, 18.7 before 18.7.2, and 18.8 before 18.8.2. An attacker with existing knowledge of a victim's credential ID can bypass two-factor authentication by submitting forged device responses, potentially gaining unauthorized access to protected user accounts.

Critical Impact

Attackers who obtain a victim's credential ID can completely bypass 2FA security controls, compromising accounts that should be protected by multi-factor authentication. This undermines a critical security layer for GitLab instances.

Affected Products

• GitLab CE/EE versions 18.6 to 18.6.3
• GitLab CE/EE versions 18.7 to 18.7.1
• GitLab CE/EE versions 18.8 to 18.8.1

Discovery Timeline

• 2026-01-21 - GitLab releases security patch addressing the vulnerability
• 2026-01-22 - CVE CVE-2026-0723 published to NVD
• 2026-01-22 - Last updated in NVD database

Technical Details for CVE-2026-0723

Vulnerability Analysis

This vulnerability is classified under CWE-252 (Unchecked Return Value), indicating that the underlying issue stems from improper validation of return values during the two-factor authentication process. The flaw allows an attacker who has already obtained knowledge of a victim's credential ID to craft and submit forged device responses that the system incorrectly accepts as valid authentication attempts.

The attack exploits weaknesses in how GitLab validates WebAuthn or similar device-based authentication responses. When the authentication system fails to properly verify the integrity and origin of device responses, an attacker can forge responses that appear legitimate to the server. This effectively neutralizes the security benefit of two-factor authentication, which is designed to protect accounts even when primary credentials are compromised.

Root Cause

The root cause of this vulnerability is the failure to properly check return values during the 2FA device response validation process (CWE-252). GitLab's authentication module did not adequately verify that device responses originated from legitimate enrolled authenticators, allowing forged responses to be accepted when combined with knowledge of the victim's credential ID.

Attack Vector

The attack requires network access and follows these general steps:

1. The attacker must first obtain the victim's credential ID through some means (enumeration, data breach, or other information disclosure)
2. With the credential ID, the attacker initiates an authentication session for the target account
3. Instead of providing a legitimate device response, the attacker crafts a forged response
4. Due to insufficient validation, GitLab accepts the forged response as valid
5. The attacker gains access to the victim's account, bypassing 2FA entirely

The vulnerability mechanism involves improper validation of authentication device responses. When a user attempts to authenticate with 2FA, the server should verify that the response cryptographically proves possession of the registered authenticator device. In vulnerable versions, this validation was insufficient, allowing attackers who knew the credential ID to forge acceptable responses without access to the actual authentication device.

For detailed technical information, see the GitLab Issue Discussion and the HackerOne Report #3476052.

Detection Methods for CVE-2026-0723

Indicators of Compromise

• Multiple failed 2FA authentication attempts followed by a successful login from unusual IP addresses or geolocations
• Authentication logs showing successful 2FA validation without corresponding device challenge completion
• Account access from new devices without legitimate device registration events
• Anomalous patterns in WebAuthn authentication flows with unusual response characteristics

Detection Strategies

• Implement monitoring for authentication events that show successful 2FA completion with abnormal timing patterns
• Review GitLab audit logs for accounts with sudden access from previously unseen locations or devices
• Deploy anomaly detection rules targeting the authentication endpoint for unusual request patterns
• Cross-reference successful authentications with device fingerprinting data to identify inconsistencies

Monitoring Recommendations

• Enable comprehensive logging of all authentication events including 2FA challenges and responses
• Set up alerts for accounts exhibiting multiple authentication failures followed by successful access
• Monitor for bulk authentication attempts targeting multiple accounts which may indicate exploitation
• Implement real-time correlation between authentication events and user behavioral baselines

How to Mitigate CVE-2026-0723

Immediate Actions Required

• Upgrade GitLab CE/EE to patched versions 18.6.4, 18.7.2, or 18.8.2 immediately
• Review authentication logs for any signs of 2FA bypass attempts during the vulnerable period
• Force password resets for high-privilege accounts as a precautionary measure
• Consider temporarily restricting administrative access until patches are applied

Patch Information

GitLab has released patched versions that address this vulnerability. Organizations should upgrade to the following versions:

• GitLab 18.6.4 (for the 18.6 branch)
• GitLab 18.7.2 (for the 18.7 branch)
• GitLab 18.8.2 (for the 18.8 branch)

Detailed patch information is available in the GitLab Patch Release Announcement.

Workarounds

• Implement additional network-level access controls to restrict GitLab access to trusted networks
• Enable IP-based access restrictions for administrative and high-privilege accounts
• Deploy a Web Application Firewall (WAF) with rules to detect anomalous authentication patterns
• Consider implementing additional authentication layers such as VPN requirements for sensitive operations

# Configuration example - Restrict GitLab access by IP (gitlab.rb)
# Add trusted IP ranges to limit authentication attempts
gitlab_rails['rack_attack_git_basic_auth'] = {
  'enabled' => true,
  'ip_whitelist' => ["127.0.0.1", "10.0.0.0/8", "192.168.0.0/16"],
  'maxretry' => 5,
  'findtime' => 60,
  'bantime' => 3600
}