CVE-2026-73804: Gitea API token scope escalation through HTTP signatures
Gitea allows a token with write:user scope to register an attacker-controlled SSH public key on the token owner's account. API requests signed with the corresponding private key authenticate as that account through HTTP Signature without API token scope information, causing route-level token scope checks to be skipped. This converts a user-scoped token into an unscoped API authentication method while retaining the account's normal role and repository permissions.
Affected Software
Event History
Frequently Asked Questions
What access does an attacker need to exploit this?
The attacker needs an API token for the target account with the write:user scope. They use that scope to add an SSH public key they control, then authenticate HTTP Signature requests using the matching private key.
What permissions can the attacker obtain after exploitation?
HTTP Signature authentication is treated as the affected account without the API token's scope information, so route-level token scope checks are skipped. The attacker still has only the account's normal role and repository permissions; this does not grant permissions beyond what that account itself can access.
Which deployments are exposed?
Deployments are exposed where an account's write:user-scoped token can be used to register an attacker-controlled SSH key and HTTP Signature authentication is available. The provided information does not identify affected versions or configuration prerequisites.
How can defenders assess whether this may have been abused?
Review SSH public keys registered on user accounts, particularly keys added through API activity associated with write:user-scoped tokens. Also investigate HTTP Signature API requests authenticated as those accounts, because those requests may have bypassed route-level token scope checks.