CVE-2026-120263 in Gitea
Summary
by MITRE • 11/01/2026
When `[oauth2_client].ACCOUNT_LINKING` is set to `auto` (not the default) and registration is enabled, the link-account sign-up form looked up the existing account to link by the user name or email submitted in the form instead of the identity asserted by the OAuth2 provider. An attacker with an account on a configured OAuth2 provider could submit another user's name, link their external identity to that Gitea account and be signed in as it without its password, including as an administrator. The link persisted for later sign-ins. Automatic linking now only happens when the existing account matches the provider's email or provider-derived user name; otherwise the account password is required.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/01/2026
This vulnerability represents a critical identity management flaw within Gitea’s OAuth2 integration, specifically affecting the automatic account linking feature. The core issue stems from an insecure direct object reference pattern where the system relies on user-supplied input rather than provider-asserted claims to associate external identities with local accounts. When the configuration parameter oauth2_client.ACCOUNT_LINKING is set to auto and registration is enabled, the application attempts to streamline the login process by automatically linking a new OAuth2 identity to an existing Gitea account if one appears to match based on provided credentials. However, the implementation flaw lies in the lookup mechanism used during this linkage phase. Instead of validating that the local account corresponds strictly to the email address or username asserted as authoritative by the external OAuth2 provider, the system performs a search using the name or email entered manually into the link-account sign-up form. This discrepancy creates a significant trust boundary violation, allowing an attacker to bypass authentication controls for accounts they do not own.
The operational impact of this vulnerability is severe, particularly in environments where administrative privileges are granted through standard user accounts rather than strictly separated service accounts. An authenticated attacker who possesses a valid account on any configured OAuth2 provider can exploit this logic error by initiating the link-account process and manually entering the username or email address associated with another victim’s Gitea account. Because the system accepts these manual inputs as sufficient for matching, it will successfully bind the attacker’s external identity to the victim’s local profile. Upon successful linking, the attacker is granted immediate access to the victim’s account without needing to know its password. This effectively circumvents all traditional authentication mechanisms protected by passwords or multi-factor authentication tied to that specific Gitea instance. The persistence of this link means that subsequent login attempts via OAuth2 will automatically authenticate as the victim, providing sustained unauthorized access until the linkage is manually removed or the vulnerability is patched.
From a security standards perspective, this flaw aligns with CWE-287, which describes Improper Authentication, specifically involving misinterpretation of input data leading to authentication bypass. It also relates closely to CWE-601, URL Redirection to Untrusted Site, in the context of identity assertion trust, although more accurately it reflects a failure in binding user identities across different security domains. In terms of MITRE ATT&CK mapping, this vulnerability facilitates Account Manipulation techniques where an adversary gains persistent access by modifying account properties or credentials. The attack vector is primarily remote and requires initial authentication to the OAuth2 provider, which lowers the barrier for exploitation compared to unauthenticated attacks but remains highly dangerous due to the privilege escalation potential if administrative accounts are targeted.
The mitigation strategy implemented in subsequent versions addresses this root cause by enforcing strict validation of identity assertions. Automatic linking now occurs exclusively when there is a direct match between the existing local account and the email address or provider-derived username explicitly asserted by the OAuth2 provider. This ensures that the linkage decision is based on trusted, cryptographically signed claims from the identity provider rather than mutable user input. For organizations running affected versions, immediate remediation involves upgrading to a patched release where this logic has been corrected. In interim scenarios where an upgrade is not immediately feasible, administrators should disable automatic account linking by setting oauth2_client.ACCOUNT_LINKING to its default value or disabling registration entirely if external OAuth2 login is required but auto-linking poses too high a risk. Additionally, auditing existing linked accounts for anomalies and requiring password verification during the link process can help mitigate exposure until the patch is applied.