Gitea CVE-2026-26247

Exploitation requires that the target Gitea instance is acting as an OAuth2/OIDC provider and that a client initiates an authorization-code flow using the S256 PKCE challenge method; the attacker must be able to obtain the resulting authorization code (via a malicious registered client, redirect-URI leakage, or interception of a public client's callback) before it is legitimately redeemed. The limiting factor is that PKCE is a protection against code interception - so an attacker who has NO way to capture an authorization code gains nothing; the flaw's value is that it nullifies PKCE's protection once a code is in hand. It does not grant unauthenticated access against a default instance in isolation: a victim OAuth flow and code capture are prerequisites. Fixed entirely by upgrading to Gitea 1.25.5.

The signals here are notably split. CVSS 9.1 (AV:N/AC:L/PR:N/UI:N, C:H/I:H) and SSVC 'Technical Impact: total, Automatable: yes' paint a severe, network-exploitable picture, but SSVC 'Exploitation: none', EPSS of 0.17% (6th percentile), no CISA KEV listing, and no public exploit code all point to low real-world exploitation pressure today. There is also a meaningful nuance the raw vector understates: PKCE is a defense-in-depth control, so exploiting this weakness in practice requires an attacker to first intercept or obtain a victim's authorization code (e.g., via a malicious registered client, redirect/URI leakage, or a compromised public-client channel) - the flaw removes the safety net that would otherwise make a stolen code useless. Thus the AC:L rating is arguably optimistic; realistic exploitation depends on being positioned to capture an authorization code, which raises attack complexity. Net assessment: this is a genuine authentication-hardening defect worth patching promptly on any internet-facing Gitea acting as an OAuth2 provider, but it is not a spray-and-pray mass-exploitation bug - treat it as elevated priority rather than emergency, pending exposure of your OAuth2 provider usage.

An attacker registers or abuses a public OAuth2 client on the Gitea instance and induces a victim to authorize it, then intercepts the issued authorization code (for example via a malicious mobile/desktop client, redirect interception, or a leaked callback). Because Gitea failed to persist the S256 challenge method, the attacker redeems that code at /login/oauth/access_token without supplying the correct code_verifier, obtaining an access token for the victim's account. No public proof-of-concept exists, but the vendor's regression test (TestAuthorizeGrantS256RequiresVerifier) precisely demonstrates the missing verifier enforcement.