CVE-2026-73804: 
Gitea vulnerability analysis and mitigation

CVE-2026-73804 is a privilege escalation vulnerability in Gitea that allows an attacker holding a write:user-scoped API token to mint unscoped HTTP Signature API credentials, effectively bypassing all route-level token scope enforcement. It affects Gitea versions up to and including v1.26.4, and was patched in v1.27.2. The vulnerability was reported by researcher ohxorud-dev, coordinated by bircni and TheFox0x7, and published on August 14, 2026. It carries a CVSS v3.1 base score of 8.1 (High) (GitHub Advisory).

The root cause is a combination of CWE-266 (Incorrect Privilege Assignment) and CWE-863 (Incorrect Authorization) in Gitea's HTTP Signature authentication path. When HTTPSign.Verify() authenticates a request via a registered SSH public key, it sets IsApiToken=true in the request data store but does not populate ApiTokenScope. The tokenRequiresScopes() middleware is fail-open: it only enforces scope checks when both IsApiToken=true and ApiTokenScope is present; if ApiTokenScope is absent, the check is silently skipped. An attacker exploits this by using a write:user token (which legitimately permits POST /api/v1/user/keys) to register an attacker-controlled SSH public key on the victim account, then signing subsequent API requests with the corresponding private key to reach any API category permitted by the account's RBAC — including admin endpoints — without possessing the required token scopes (GitHub Advisory, Fix PR #38862).

Successful exploitation allows an attacker with a limited write:user token to escalate to an effectively unscoped API authentication method for the same account, constrained only by the account's normal Gitea RBAC. For site-administrator accounts, this enables unauthorized access to admin-only API endpoints such as user creation (POST /api/v1/admin/users), repository deletion, and other destructive operations. For non-admin accounts, the attacker gains unscoped access to repository, package, organization, issue, and notification APIs beyond what the original token permitted, posing significant confidentiality and integrity risks (GitHub Advisory).

A public proof-of-concept is included in the official GitHub Security Advisory, detailing the exact API call sequence required to exploit the vulnerability. Exploitation requires only a valid write:user API token for the target account (low privileges required) and is performed entirely over the network with no user interaction. No in-the-wild exploitation has been reported, no threat actor attribution exists, and the CVE is not listed in the CISA KEV catalog. The EPSS score is reported as 0.0, reflecting low current exploitation probability (GitHub Advisory, Feedly).

1. Obtain a write:user token: Acquire or compromise a Gitea API token with at least write:user scope for the target account.
2. Verify scope restriction: Confirm the token cannot directly access out-of-scope endpoints (e.g., POST /api/v1/admin/users returns 403 Forbidden).
3. Generate an attacker-controlled SSH key pair: Create a new RSA or Ed25519 SSH key pair locally (e.g., ssh-keygen -t rsa -b 4096 -f attacker_key).
4. Register the SSH public key: Use the write:user token to call POST /api/v1/user/keys with the attacker-controlled public key and receive a 201 Created response containing the key's fingerprint.
5. Construct an HTTP Signature request: Sign a target API request (e.g., POST /api/v1/admin/users) using the attacker's private key, setting the Signature header with keyId equal to the enrolled SSH key fingerprint, and including (request-target), (created), and (expires) in the signed headers.
6. Send the signed request: Submit the HTTP Signature-authenticated request to the target endpoint. Gitea's HTTPSign.Verify() authenticates the request as the key owner with IsApiToken=true but no ApiTokenScope, causing tokenRequiresScopes() to skip enforcement and the handler to execute with full account RBAC.
7. Achieve privilege escalation: For admin accounts, create users, modify resources, or perform other admin-only actions; for non-admin accounts, access repository, package, or organization APIs beyond the original token's scope (GitHub Advisory).

• Network: Unexpected POST /api/v1/user/keys API calls using a write:user token, especially from unfamiliar IP addresses or automated clients; subsequent API requests to privileged endpoints (e.g., /api/v1/admin/users, /api/v1/repos/{owner}/{repo}) authenticated via Signature: header rather than Authorization: token.
• Logs: Gitea access logs showing requests with a Signature header (HTTP Signature authentication) to admin or out-of-scope API routes from accounts that do not normally use SSH key-based API access; POST /api/v1/user/keys entries followed shortly by privileged API calls from the same account.
• File System / Database: Unexpected SSH public keys registered to user accounts (visible in Gitea admin panel under user SSH keys); newly created user accounts, repositories, or organizations that cannot be attributed to legitimate activity.
• Process/Application: Gitea application logs showing HTTP Sign: Logged in user trace entries for API routes that require elevated scopes (e.g., admin routes) (GitHub Advisory).

Gitea has released version 1.27.2 which fixes this vulnerability by refactoring the API token scope check logic: the IsApiToken flag is removed and scope enforcement now relies solely on the presence of ApiTokenScope, ensuring HTTP Signature-authenticated requests without a scope are no longer treated as scoped token requests (Gitea Release v1.27.2, Fix PR #38895). All Gitea instances running v1.26.4 or earlier should upgrade to v1.27.2 immediately. As a temporary workaround where upgrading is not immediately possible, administrators can audit and remove any unexpected SSH public keys from user accounts and restrict API token issuance to trusted users.

The vulnerability was disclosed via a GitHub Security Advisory by Gitea maintainer bircni, with the fix coordinated by TheFox0x7 and wxiaoguang. The Gitea release blog post for v1.27.2 highlighted the security fix prominently. The release received positive community engagement on GitHub (25+ thumbs-up, 14 rocket reactions), indicating the community was attentive to the security update (Gitea Release v1.27.2, Gitea Blog). No significant independent researcher commentary or broader media coverage has been identified at this time.