Summary
Gitea's OAuth2 and OpenID Connect sign-in paths may omit the WebAuthn challenge when WebAuthn is the account's only configured second factor. An actor who can authenticate through an affected external identity flow could receive a full session without passkey verification, and one path may also preserve an external identity link for continued access.
Gitea's OAuth2 and OpenID Connect sign-in paths may omit the WebAuthn challenge when WebAuthn is the account's only configured second factor. An actor who can authenticate through an affected external identity flow could receive a full session without passkey verification, and one path may also preserve an external identity link for continued access.
Affected context
The issue occurs in Gitea deployments that:
- Enable OAuth2 or OpenID Connect authentication
- Allow accounts to use WebAuthn as their only configured second factor
- Permit the affected external identity sign-in path to establish a full session
The reported WebAuthn-only scenario does not apply to accounts that also have TOTP configured. One affected flow may persist an external identity association after sign-in.
The issue occurs in Gitea deployments that:
- Enable OAuth2 or OpenID Connect authentication
- Allow accounts to use WebAuthn as their only configured second factor
- Permit the affected external identity sign-in path to establish a full session
The reported WebAuthn-only scenario does not apply to accounts that also have TOTP configured. One affected flow may persist an external identity association after sign-in.
Exploit preconditions
- Attack surface: Gitea OAuth2 and OpenID Connect sign-in endpoints
- Required access: Ability to authenticate through an affected external identity provider flow
- Account condition: The target account relies on WebAuthn as its only configured second factor
- Trigger point: External identity authentication followed by session establishment
- Why exploitation is possible: The external sign-in path does not consistently enforce the WebAuthn challenge required by the password-login path
- Attack surface: Gitea OAuth2 and OpenID Connect sign-in endpoints
- Required access: Ability to authenticate through an affected external identity provider flow
- Account condition: The target account relies on WebAuthn as its only configured second factor
- Trigger point: External identity authentication followed by session establishment
- Why exploitation is possible: The external sign-in path does not consistently enforce the WebAuthn challenge required by the password-login path
Why this happens
The underlying flaw is inconsistent enforcement of authentication assurance across alternative sign-in paths. A session can be created after OAuth2 or OpenID Connect authentication without requiring the WebAuthn factor that protects the account during password-based login. This behavior maps to CWE-287: Improper Authentication, because a protected account may be treated as fully authenticated without verifying all required authentication factors.
The underlying flaw is inconsistent enforcement of authentication assurance across alternative sign-in paths. A session can be created after OAuth2 or OpenID Connect authentication without requiring the WebAuthn factor that protects the account during password-based login. This behavior maps to CWE-287: Improper Authentication, because a protected account may be treated as fully authenticated without verifying all required authentication factors.
Potential impact
- An attacker may obtain an authenticated Gitea session without completing the required passkey challenge.
- The attacker could access repositories, organization resources, or other functions available to the account.
- An affected flow may allow an external identity link to persist, potentially extending access beyond the initial session.
- Repository contents, credentials, or project integrity could be exposed or altered.
- An attacker may obtain an authenticated Gitea session without completing the required passkey challenge.
- The attacker could access repositories, organization resources, or other functions available to the account.
- An affected flow may allow an external identity link to persist, potentially extending access beyond the initial session.
- Repository contents, credentials, or project integrity could be exposed or altered.
General mitigation guidance
Mitigation generally focuses on applying consistent authentication assurance requirements to every login and account-linking path.
Common defensive patterns include:
- Requiring the configured WebAuthn challenge before establishing a fully privileged session, regardless of the selected sign-in method.
- Applying equivalent step-up authentication to OAuth2, OpenID Connect, password, recovery, and identity-linking workflows.
- Treating external-provider authentication as insufficient to bypass locally configured factors unless an explicit, trusted assurance policy permits it.
- Requiring fresh multifactor verification before creating or changing persistent external identity links.
- Limiting session privileges until all account-specific authentication requirements are satisfied.
- Monitoring and reviewing external identity associations and enforcing least privilege for authenticated accounts.
Mitigation generally focuses on applying consistent authentication assurance requirements to every login and account-linking path.
Common defensive patterns include:
- Requiring the configured WebAuthn challenge before establishing a fully privileged session, regardless of the selected sign-in method.
- Applying equivalent step-up authentication to OAuth2, OpenID Connect, password, recovery, and identity-linking workflows.
- Treating external-provider authentication as insufficient to bypass locally configured factors unless an explicit, trusted assurance policy permits it.
- Requiring fresh multifactor verification before creating or changing persistent external identity links.
- Limiting session privileges until all account-specific authentication requirements are satisfied.
- Monitoring and reviewing external identity associations and enforcing least privilege for authenticated accounts.
How teams detect issues like this
Organizations can assess for this class of issue through:
- Static and behavioral tests that compare factor enforcement across password, OAuth2, OpenID Connect, recovery, and account-linking paths.
- Code review checks for session creation or identity-link persistence that occurs before local MFA verification.
- Integration tests covering accounts with WebAuthn as the sole second factor and confirming that every authentication route requires a challenge.
- Policy checks that require consistent authentication assurance before granting full sessions or modifying identity bindings.
- Audit-log monitoring for external sign-ins, unusual session creation, and unexpected identity-link changes.
Automated security review tools may help identify authentication branches that establish sessions without invoking the expected second-factor checks.
Organizations can assess for this class of issue through:
- Static and behavioral tests that compare factor enforcement across password, OAuth2, OpenID Connect, recovery, and account-linking paths.
- Code review checks for session creation or identity-link persistence that occurs before local MFA verification.
- Integration tests covering accounts with WebAuthn as the sole second factor and confirming that every authentication route requires a challenge.
- Policy checks that require consistent authentication assurance before granting full sessions or modifying identity bindings.
- Audit-log monitoring for external sign-ins, unusual session creation, and unexpected identity-link changes.
Automated security review tools may help identify authentication branches that establish sessions without invoking the expected second-factor checks.
Sources
| Source | Link |
|---|---|
| blog. | blog.gitea.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
