Summary
Gitea allows a token with the write:user scope to register an attacker-controlled SSH public key on the token owner's account. The corresponding private key can then authenticate through HTTP Signature without preserving token scope information, potentially bypassing route-level scope checks while retaining the account's permissions.
Gitea allows a token with the write:user scope to register an attacker-controlled SSH public key on the token owner's account. The corresponding private key can then authenticate through HTTP Signature without preserving token scope information, potentially bypassing route-level scope checks while retaining the account's permissions.
Affected context
This issue occurs in Gitea deployments where a user-scoped API token can manage SSH keys and HTTP Signature authentication is accepted without carrying equivalent token scope restrictions. The risk depends on the token owner's account permissions and on routes that rely on token scope checks to limit access.
This issue occurs in Gitea deployments where a user-scoped API token can manage SSH keys and HTTP Signature authentication is accepted without carrying equivalent token scope restrictions. The risk depends on the token owner's account permissions and on routes that rely on token scope checks to limit access.
Exploit preconditions
- Attack surface: Gitea API and HTTP Signature authentication
- Required access: A valid token with the
write:userscope - Trigger point: Registering an attacker-controlled SSH public key and
subsequently authenticating with the matching private key
- Why exploitation is possible: HTTP Signature authentication does not
retain the originating API token's scope information, allowing route-level
scope checks to be skipped while the account's normal permissions remain
available
- Attack surface: Gitea API and HTTP Signature authentication
- Required access: A valid token with the
write:userscope - Trigger point: Registering an attacker-controlled SSH public key and
subsequently authenticating with the matching private key
- Why exploitation is possible: HTTP Signature authentication does not
retain the originating API token's scope information, allowing route-level
scope checks to be skipped while the account's normal permissions remain
available
Why this happens
The vulnerability results from inconsistent authorization semantics between token-based authentication and HTTP Signature authentication. A scoped token can establish a persistent account authentication mechanism whose later requests are treated as account-level authentication without equivalent scope restrictions. This reflects CWE-266, Improper Privilege Management, and is also related to CWE-863, Incorrect Authorization, because access control decisions do not consistently enforce the privileges associated with the original credential.
The vulnerability results from inconsistent authorization semantics between token-based authentication and HTTP Signature authentication. A scoped token can establish a persistent account authentication mechanism whose later requests are treated as account-level authentication without equivalent scope restrictions. This reflects CWE-266, Improper Privilege Management, and is also related to CWE-863, Incorrect Authorization, because access control decisions do not consistently enforce the privileges associated with the original credential.
Potential impact
- An attacker may access API operations beyond the original token scope.
- The attacker could perform actions permitted to the token owner's account.
- Repository data or organization resources may be exposed or modified.
- Account-level actions may enable further repository or administrative impact.
- An attacker may access API operations beyond the original token scope.
- The attacker could perform actions permitted to the token owner's account.
- Repository data or organization resources may be exposed or modified.
- Account-level actions may enable further repository or administrative impact.
General mitigation guidance
Mitigation generally focuses on preserving authorization context across all
authentication mechanisms.
Common defensive patterns include:
- Bind derived authentication credentials to the originating token scopes.
- Apply centralized authorization checks after authentication, regardless of
whether the request uses an API token or HTTP Signature.
- Limit SSH key registration and management to appropriately authorized
workflows.
- Use short-lived, narrowly scoped credentials where practical.
- Apply least privilege to user, organization, and repository roles.
- Review existing keys and credentials for accounts associated with
potentially exposed scoped tokens.
Mitigation generally focuses on preserving authorization context across all
authentication mechanisms.
Common defensive patterns include:
- Bind derived authentication credentials to the originating token scopes.
- Apply centralized authorization checks after authentication, regardless of
whether the request uses an API token or HTTP Signature.
- Limit SSH key registration and management to appropriately authorized
workflows.
- Use short-lived, narrowly scoped credentials where practical.
- Apply least privilege to user, organization, and repository roles.
- Review existing keys and credentials for accounts associated with
potentially exposed scoped tokens.
How teams detect issues like this
Detection approaches may include:
- Monitoring API activity that creates or changes SSH keys using scoped tokens.
- Comparing the authorization context of HTTP Signature requests with the
scopes of the credentials that established associated keys.
- Reviewing routes where scope checks are implemented separately from
account-level authorization.
- Using static analysis and code review to identify authentication paths that
discard token scope metadata.
- Enforcing policy tests that exercise equivalent authorization decisions
across all supported authentication mechanisms.
Detection approaches may include:
- Monitoring API activity that creates or changes SSH keys using scoped tokens.
- Comparing the authorization context of HTTP Signature requests with the
scopes of the credentials that established associated keys.
- Reviewing routes where scope checks are implemented separately from
account-level authorization.
- Using static analysis and code review to identify authentication paths that
discard token scope metadata.
- Enforcing policy tests that exercise equivalent authorization decisions
across all supported authentication mechanisms.
Sources
| Source | Link |
|---|---|
| blog. | blog.gitea.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
