CVE-2026-2745: GitLab WebAuthn Auth Bypass Vulnerability

CVE-2026-2745 Overview

GitLab disclosed an authentication bypass vulnerability affecting GitLab Community Edition (CE) and Enterprise Edition (EE). The flaw affects all versions from 7.11 before 18.8.7, 18.9 before 18.9.3, and 18.10 before 18.10.1. Attackers can bypass WebAuthn two-factor authentication (2FA) and gain unauthorized access to user accounts. The root cause is inconsistent input validation in the authentication process [CWE-288]. GitLab released patched versions on March 25, 2026 to address the issue.

Critical Impact

An attacker with valid primary credentials can bypass the WebAuthn 2FA layer entirely, compromising account confidentiality and integrity even when hardware-backed second factors are enforced.

Affected Products

• GitLab Community Edition (CE) versions 7.11 through 18.8.6
• GitLab Enterprise Edition (EE) versions 18.9 through 18.9.2
• GitLab CE/EE version 18.10.0

Discovery Timeline

• 2026-03-25 - GitLab releases patch versions 18.8.7, 18.9.3, and 18.10.1
• 2026-03-25 - CVE-2026-2745 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-2745

Vulnerability Analysis

The vulnerability resides in the WebAuthn authentication flow used by GitLab to enforce two-factor authentication. WebAuthn is a W3C standard that allows users to authenticate using hardware security keys or platform authenticators. GitLab implements WebAuthn as one of several supported second-factor methods, alongside time-based one-time passwords (TOTP) and recovery codes.

The issue is categorized under Authentication Bypass Using an Alternate Path or Channel [CWE-288]. The authentication process applies inconsistent input validation across different code paths handling WebAuthn assertions. An attacker with credentials for the first authentication step can craft requests that traverse a validation path that does not properly verify the WebAuthn assertion, allowing the second factor check to be skipped.

The attack vector is network-based and requires low privileges, reflecting that the attacker must possess valid first-factor credentials (typically a username and password). No user interaction is required from the victim, and exploitation impacts both confidentiality and integrity of the targeted account.

Root Cause

The root cause is inconsistent enforcement of WebAuthn assertion validation across authentication endpoints. When validation logic differs between code paths handling the same authentication step, an attacker can select the path with weaker checks. This allows the second-factor requirement to be bypassed despite the user having WebAuthn configured.

Attack Vector

An attacker who has obtained or compromised a victim's primary credentials—through phishing, credential stuffing, or prior data breaches—initiates authentication against a vulnerable GitLab instance. By manipulating the request flow to the authentication endpoint with inconsistent validation, the attacker bypasses the WebAuthn challenge entirely and gains a fully authenticated session for the targeted account.

The vulnerability mechanism is described in the HackerOne Report #3557844 and tracked internally in GitLab Work Item #590810. Public proof-of-concept code is not currently available.

Detection Methods for CVE-2026-2745

Indicators of Compromise

• Successful authentication events for accounts with WebAuthn enabled where no WebAuthn assertion appears in audit logs.
• Logins from new geolocations or user-agents for accounts that historically required hardware key authentication.
• Sudden bursts of authentication attempts followed by successful logins against accounts with 2FA configured.

Detection Strategies

• Review GitLab production_json.log and audit_json.log for authentication events missing the expected WebAuthn challenge-response sequence.
• Correlate primary credential validation events with second-factor completion events; flag sessions where the latter is absent for 2FA-enrolled users.
• Monitor for session creation immediately following password validation without an intervening WebAuthn assertion record.

Monitoring Recommendations

• Forward GitLab authentication and audit logs to a centralized analytics platform for retrospective review across the exposure window.
• Alert on any privileged account (Owner, Maintainer, Admin) login that occurs without a recorded second-factor event.
• Track changes to SSH keys, personal access tokens, and pipeline secrets following suspicious authentication events.

How to Mitigate CVE-2026-2745

Immediate Actions Required

• Upgrade GitLab CE/EE to version 18.8.7, 18.9.3, or 18.10.1 depending on your deployment branch.
• Audit authentication and admin activity logs for the period preceding the upgrade to identify any anomalous logins.
• Rotate personal access tokens, SSH keys, and pipeline secrets for accounts that show suspicious activity.
• Force re-authentication for all active sessions after applying the patch.

Patch Information

GitLab published patched releases on March 25, 2026. Administrators should apply 18.10.1, 18.9.3, or 18.8.7 as appropriate. Details are available in the GitLab Patch Release Announcement. GitLab.com SaaS instances are patched by GitLab; self-managed instances must be upgraded by the operator.

Workarounds

• Restrict network access to the GitLab web interface using IP allowlists or VPN-gated access until the patch is applied.
• Enforce SSO with an external identity provider that applies its own MFA enforcement in front of GitLab.
• Temporarily disable accounts with elevated privileges that cannot be patched immediately.
• Monitor authentication endpoints with a web application firewall to detect anomalous request patterns targeting the WebAuthn flow.

# Upgrade example for Omnibus GitLab on Debian/Ubuntu
sudo apt-get update
sudo apt-get install gitlab-ee=18.10.1-ee.0
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

# Verify installed version
sudo gitlab-rake gitlab:env:info | grep "GitLab information"