CVE-2026-58425: Gitea: OAuth token introspection returns metadata of tokens issued to other clients (RFC 7662 section 4 violation)

Any authenticated OAuth client can call /login/oauth/introspect with another client’s access or refresh token in the body and learn:

• active (true or false). A token-validity oracle that survives across application boundaries without consuming or “using” the token.
• scope. The scope of the token.
• username. The user the token belongs to.
• iss, sub, aud. Standard JWT registered claims. aud reveals the issuing client_id, making it obvious to the introspecting client that the token does not belong to them. The server returns the data anyway.

Practical scenarios:

1. Stolen-token validation oracle. An attacker who exfiltrates an access token from logs, traffic capture, browser memory, or a leaked dump can verify the token is still active before using it for higher-noise actions like API calls. The probe does not consume the grant counter, so it does not appear in audit trails of “actual token use”.
2. Cross-tenant metadata enumeration. Any user can register their own OAuth application on a Gitea instance (web UI: /user/settings/applications). The attacker uses their own valid credentials to introspect tokens belonging to other tenants’ clients. They learn which user/scope each token corresponds to without ever using it.
3. Token-confusion reconnaissance. Before chaining a separate vulnerability (e.g., a future token-replay or session-fixation bug), the attacker can use introspection to map the token universe.