Summary
Gitea's OAuth2 token endpoint accepted an unexpired access token when a refresh token was required, provided the token belonged to the same application and grant. An attacker holding such an access token could obtain replacement access and refresh tokens, potentially extending access beyond the token's intended lifetime.
Gitea's OAuth2 token endpoint accepted an unexpired access token when a refresh token was required, provided the token belonged to the same application and grant. An attacker holding such an access token could obtain replacement access and refresh tokens, potentially extending access beyond the token's intended lifetime.
Affected context
The issue occurs in Gitea OAuth2 deployments when the token endpoint processes requests using the refresh_token grant type. The endpoint verifies the token's signature and application relationship but may fail to confirm that the submitted credential is specifically a refresh token rather than an access token.
The issue occurs in Gitea OAuth2 deployments when the token endpoint processes requests using the refresh_token grant type. The endpoint verifies the token's signature and application relationship but may fail to confirm that the submitted credential is specifically a refresh token rather than an access token.
Exploit preconditions
- Attack surface: Gitea's OAuth2 token endpoint
- Required access: Possession of a valid, unexpired access token issued for the relevant OAuth2 application and grant
- Trigger point: A token request using the
refresh_tokengrant type - Why exploitation is possible: Token validation confirms authenticity and application scope without enforcing the required token type
- Attack surface: Gitea's OAuth2 token endpoint
- Required access: Possession of a valid, unexpired access token issued for the relevant OAuth2 application and grant
- Trigger point: A token request using the
refresh_tokengrant type - Why exploitation is possible: Token validation confirms authenticity and application scope without enforcing the required token type
Why this happens
The underlying defect is incomplete credential-type validation in an authentication flow. The endpoint validates the submitted token's signature and association with the OAuth2 application but does not enforce that the credential is a refresh token before allowing token renewal. This behavior maps to CWE-287: Improper Authentication, because the system accepts a credential in a context where its intended authentication role has not been adequately verified.
The underlying defect is incomplete credential-type validation in an authentication flow. The endpoint validates the submitted token's signature and association with the OAuth2 application but does not enforce that the credential is a refresh token before allowing token renewal. This behavior maps to CWE-287: Improper Authentication, because the system accepts a credential in a context where its intended authentication role has not been adequately verified.
Potential impact
- An attacker may extend access beyond the original access-token lifetime
- A valid access token could be exchanged for a new access token and refresh token
- Compromised credentials could support longer-lived unauthorized access
- Applications and user resources could remain accessible until tokens are revoked or otherwise invalidated
- An attacker may extend access beyond the original access-token lifetime
- A valid access token could be exchanged for a new access token and refresh token
- Compromised credentials could support longer-lived unauthorized access
- Applications and user resources could remain accessible until tokens are revoked or otherwise invalidated
General mitigation guidance
Mitigation generally focuses on enforcing token-type and grant-type separation throughout OAuth2 token processing.
Common defensive patterns include:
- Accepting only credentials explicitly classified as refresh tokens for refresh-token grants
- Applying strict server-side validation for token type, issuer, client, grant, audience, and lifecycle state
- Using secure-by-default OAuth2 library and framework validation behavior
- Reducing token lifetime and refresh-token scope where operationally appropriate
- Protecting refresh tokens through secure storage, transport, rotation, and revocation controls
- Applying least privilege to OAuth2 applications and issued token scopes
Mitigation generally focuses on enforcing token-type and grant-type separation throughout OAuth2 token processing.
Common defensive patterns include:
- Accepting only credentials explicitly classified as refresh tokens for refresh-token grants
- Applying strict server-side validation for token type, issuer, client, grant, audience, and lifecycle state
- Using secure-by-default OAuth2 library and framework validation behavior
- Reducing token lifetime and refresh-token scope where operationally appropriate
- Protecting refresh tokens through secure storage, transport, rotation, and revocation controls
- Applying least privilege to OAuth2 applications and issued token scopes
How teams detect issues like this
Organizations can look for this class of issue through:
- Static and dynamic tests that submit access tokens to refresh-token endpoints and verify rejection
- Code review checks for token validation logic that confirms signatures but omits credential type
- Test coverage for mismatched grant types, token classes, clients, issuers, and audiences
- Monitoring for unusual refresh activity involving access-token identifiers or repeated token exchanges
- Policy enforcement requiring explicit token-type checks before any token renewal operation
Automated security testing and code review tools may help identify inconsistent OAuth2 validation paths.
Organizations can look for this class of issue through:
- Static and dynamic tests that submit access tokens to refresh-token endpoints and verify rejection
- Code review checks for token validation logic that confirms signatures but omits credential type
- Test coverage for mismatched grant types, token classes, clients, issuers, and audiences
- Monitoring for unusual refresh activity involving access-token identifiers or repeated token exchanges
- Policy enforcement requiring explicit token-type checks before any token renewal operation
Automated security testing and code review tools may help identify inconsistent OAuth2 validation paths.
Sources
| Source | Link |
|---|---|
| blog. | blog.gitea.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
