Gitea's OAuth2 sign-in callback incorrectly reactivates user accounts marked as inactive when the authentication source does not provide refresh tokens. The reactivation gate relies on detecting an empty refresh token to identify accounts disabled by the auto-sync cron, but for sources like GitHub that never issue refresh tokens, this condition is always true. Consequently, when a deactivated user signs in via such a source, Gitea sets their IsActive flag to true and grants a session, undoing the administrator's deactivation. This vulnerability affects Gitea versions before 1.27.0 and impacts any instance using GitHub or OAuth2/OIDC sources without offline_access that rely on the "Activated" toggle for account disabling. The vulnerability does not affect accounts disabled with the "Prohibit Login" hard ban. No special privileges are required beyond the ability to sign in as the deactivated user.

Deactivated user accounts can regain active status and full session access by signing in through an OAuth2 source that does not issue refresh tokens, such as GitHub. This bypasses the administrator's deactivation action, potentially restoring all prior access rights, including administrative privileges if the account was an administrator. The vulnerability does not affect accounts disabled using the "Prohibit Login" setting, which remains enforced. This undermines the effectiveness of the "Activated" toggle as a means to disable user accounts in affected configurations.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, administrators should avoid relying solely on the "Activated" toggle to disable accounts for users authenticating via OAuth2 sources without refresh tokens. Instead, use the "Prohibit Login" setting to enforce account disablement, as it is not affected by this vulnerability. Monitor official Gitea advisories for updates and apply patches once released.