Gitea CVE-2026-58422

Exploitation requires that the target account (1) exists in Gitea and is linked to a configured external OAuth/OIDC authentication provider, (2) has been set to disabled/prohibited-login by an administrator, and (3) the attacker still controls valid credentials at that OAuth provider to complete the sign-in callback. The limiting factors are significant: it only affects accounts an admin explicitly disabled (not arbitrary or new users), requires a functioning OAuth integration to be configured, and requires the attacker to authenticate successfully at the upstream identity provider - so an attacker with no prior account or whose provider identity has also been revoked cannot exploit it. It does not grant privileges beyond what the disabled account previously held.

The published CVSS is 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H), but the signals conflict with the described behavior. The description scopes the impact to re-enabling a previously-disabled account - an access-control/integrity failure - which does not plausibly carry a High availability impact (A:H), so the 9.8 appears inflated relative to the mechanism. EPSS is low at 0.16% (6th percentile), the CVE is not in CISA KEV, and no POC is referenced, indicating no evidence of active or imminent widespread exploitation. Realistic risk is bounded by a meaningful precondition: the attacker must already possess valid OAuth credentials for a specific account that an administrator chose to disable. Where such accounts exist (for example, a deprovisioned employee whose OAuth identity is still valid), the impact is genuinely serious because it defeats an intentional revocation; but it is not the mass-exploitable unauthenticated RCE that a 9.8 might suggest. Treat this as a targeted access-control priority for organizations that rely on Gitea's account-disable feature, not as an internet-worm-class emergency.

An administrator disables a departing contributor's Gitea account, but the account remains linked to the organization's OAuth provider (e.g., a still-valid corporate SSO identity). The former user browses to the Gitea login page, clicks 'Sign in with OAuth,' completes the provider flow, and the callback silently re-enables their account, restoring access to private repositories. No public exploit code is required - the attack uses the product's normal OAuth login button.