CVE-2026-73278 in Gitea
Summary
by MITRE • 10/06/2026
Gitea's OAuth2 and OpenID Connect sign-in paths do not require a WebAuthn challenge when WebAuthn is the account's only configured second factor. A party able to authenticate through the affected external identity flow can obtain a full session without the passkey verification enforced during password login. One affected path can also persist an external identity link, extending the compromise beyond the initial session; accounts with TOTP configured are outside the reported WebAuthn-only scenario.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability in Gitea represents a critical authentication bypass within its OAuth2 and OpenID Connect integration mechanisms, specifically targeting scenarios where WebAuthn is configured as the sole second factor for user account security. In a properly secured multi-factor authentication environment, every distinct sign-in path should enforce all required verification steps regardless of the initial entry point. However, in this specific implementation flaw, when an external identity provider such as GitHub or Google is used to initiate login via OAuth2 or OpenID Connect, Gitea fails to trigger the WebAuthn challenge that would normally be mandatory for account access. This creates a significant security gap where the integrity of the second factor is effectively nullified during federated authentication flows, allowing an attacker who has compromised external credentials to bypass local multi-factor protections entirely.
From a technical perspective, this flaw stems from inconsistent enforcement logic between different authentication endpoints within the application. While password-based logins correctly invoke the WebAuthn verification process as required by the account's security policy, the federated identity flow skips this step under certain conditions. The vulnerability is particularly severe because it allows for session establishment without passkey verification. This means that if an attacker obtains valid credentials from a linked external service or exploits a weakness in the OAuth2/OpenID Connect provider, they can authenticate directly into Gitea with full administrative privileges associated with that account. Furthermore, one of the affected paths includes functionality to persistently link the external identity to the local Gitea account. This persistence feature exacerbates the impact by ensuring that even after the initial session expires or is terminated, the attacker retains a persistent foothold through the linked external credential, making remediation more difficult as it requires unlinking identities rather than just changing passwords.
The operational impact of this vulnerability extends beyond immediate unauthorized access to long-term account compromise and potential lateral movement within systems integrated with Gitea. Since WebAuthn is often deployed for high-security environments requiring strong cryptographic proof of identity, bypassing it reduces the security posture significantly. An attacker leveraging this flaw can not only gain full session control but also establish a permanent link between their compromised external identity and the victim's account. This persistence mechanism means that future access attempts will automatically succeed without further verification if the linked provider is used again. It is important to note that accounts configured with Time-based One-Time Passwords (TOTP) as an additional factor are not affected by this specific vulnerability, indicating that the flaw is isolated to configurations relying exclusively on WebAuthn for second-factor authentication.
To mitigate this risk, administrators should immediately apply available patches from Gitea maintainers that address the inconsistent enforcement of multi-factor requirements in federated login flows. Until patching is complete, organizations can implement compensating controls such as restricting OAuth2 and OpenID Connect providers to trusted domains or disabling external identity linking for high-privilege accounts. Additionally, enforcing WebAuthn-only policies should be reviewed to ensure that no single factor bypasses the intended security model; if possible, requiring at least two distinct types of second factors can reduce reliance on any single mechanism. Monitoring logs for unusual authentication patterns from external providers may also help detect exploitation attempts in real-time. This vulnerability is classified under CWE-287 Improper Authentication and aligns with MITRE ATT&CK technique T1078 Valid Accounts, specifically highlighting the abuse of legitimate credentials through federated identity chains to bypass local security controls.