Gitea CVE-2026-101023

Attacker must already possess an unexpired, valid OAuth2 access token issued for the same OAuth2 application and grant on a Gitea instance at version ≤28.0.0 with the OAuth2 provider in use. The flaw is that the token endpoint accepted any such valid access token under the refresh_token grant without checking it was actually a refresh token. Key limiting factor: there is NO path to exploitation without a pre-existing valid access token - this extends/persists already-granted access rather than granting new access, and does not by itself let an unauthenticated outsider in. No user interaction is required.

Signals conflict sharply here. The published CVSS is 9.1 Critical (AV:N/AC:L/PR:N/UI:N/C:H/I:H), and SSVC rates Technical Impact as 'total' and Automatable as 'yes' - which on paper argues for urgency. However, SSVC Exploitation is 'none', there is no CISA KEV listing, no public exploit code is identified, and EPSS is only 0.17% (6th percentile), indicating very low near-term exploitation probability. More importantly, the CVSS PR:N rating appears to overstate real-world attacker preconditions: per the description, exploitation requires the attacker to ALREADY hold a valid, unexpired OAuth2 access token for the same application and grant. This is not a path to initial compromise - it is a token-persistence/lifetime-extension flaw that undermines token expiry and revocation after a token has already leaked. Net assessment: this is a legitimate authentication/session-management defect worth patching on a normal cycle, but it is not a drop-everything, internet-facing pre-auth RCE despite the 9.1 label. Treat as medium-priority unless you have evidence of leaked OAuth2 tokens.

An attacker who has obtained a valid but soon-to-expire OAuth2 access token (e.g. leaked from logs, a compromised client, or intercepted) submits it to Gitea's token endpoint using the refresh_token grant type. Because the endpoint validated the signature and grant but not the token's kind, Gitea issues a fresh access token and a new refresh token, letting the attacker retain access indefinitely past the original token's lifetime and survive expiry. No public exploit code is identified at time of analysis.