CVE-2026-116474 in Gitea
Summary
by MITRE • 11/01/2026
The `GITEA_TOKEN` of a Gitea Actions job authenticates as the `gitea-actions` system user, and the `/api/v1/user` email and GPG key endpoints accepted that user, so a job could register an email address and a GPG key on it; without required email confirmation (the default) the address is stored as activated. Commit verification treats a key without a real owner as the instance signing key, so any user who can run a workflow job could make commits signed with their own key show as trusted and signed by the instance in every repository where they appear, including pull requests to repositories the user cannot write to. The impact is limited to the displayed signature status: enforcement such as required signed commits only checks that a signature is verified and is unaffected, and no access is gained. The `/api/v1/user` routes now reject system users.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/01/2026
The vulnerability centers on an authentication bypass within Gitea Actions that allows unauthorized manipulation of commit verification statuses through the misuse of system-level API endpoints. Specifically, the environment variable `GITEA_TOKEN`, which authenticates jobs running in a Gitea Action workflow as the internal `gitea-actions` system user, was improperly permitted to interact with certain `/api/v1/user` endpoints. These endpoints included functionality for registering email addresses and uploading GPG keys. Under default configurations, newly registered email addresses are marked as verified without requiring explicit confirmation via an external link. This design flaw allowed a malicious actor who could execute arbitrary workflow jobs on the instance to register their own email address and associate it with the privileged `gitea-actions` system account.
The core technical impact arises from how Gitea handles commit signature verification when dealing with keys that lack distinct ownership metadata. The platform treats any key associated with a user profile but lacking a verified owner identity as equivalent to the instance-level signing key. Consequently, by associating their personal GPG key with the `gitea-actions` system account via the aforementioned API endpoints, an attacker could cause commits made under their own name to be displayed in the UI and APIs as being signed by the trusted instance key rather than just a standard user key. This manipulation affects every repository where the attacker has any presence, including pull requests directed at repositories where they possess no write access or administrative privileges.
From a security impact perspective, this vulnerability is classified primarily as an integrity issue regarding display logic and trust indicators rather than a direct compromise of system confidentiality or availability. The primary consequence is the erosion of trust in commit signatures within the user interface and API responses. Attackers could falsely present their code changes as being cryptographically signed by the platform itself, potentially deceving reviewers into believing that commits have undergone stricter verification processes than they actually have. This undermines the integrity guarantees provided by GPG signing workflows, which are often used to ensure authorship authenticity in collaborative development environments.
It is critical to note that this vulnerability does not grant unauthorized access to code repositories or allow for direct system compromise. Enforcement mechanisms such as required signed commits checks remain unaffected because they verify the cryptographic validity of the signature against known public keys rather than relying solely on the display status derived from user profile associations. The attacker cannot bypass branch protection rules, push directly to protected branches, or escalate privileges beyond what is already granted by their ability to run workflow jobs. Therefore, while the visual representation of trust is compromised, the actual security boundaries enforced by Gitea's access control and signature verification logic remain intact against this specific attack vector.
The remediation for this vulnerability involves restricting API access so that system-level endpoints do not accept requests authenticated as internal service accounts like `gitea-actions`. By configuring the `/api/v1/user` routes to reject authentication attempts from these non-human, system-generated tokens, Gitea prevents external workflows from modifying user profile data such as email addresses and GPG keys. This change ensures that only human users with appropriate permissions can manage their own identity attributes, thereby preserving the integrity of the commit signing trust chain.
In terms of industry standards, this vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically where a user or process operates at an unnecessary higher privilege level than required for its function. The ability to manipulate system-level accounts via API endpoints reflects a failure in enforcing strict separation between service identities and end-user identities. Furthermore, from the perspective of the MITRE ATT&CK framework, this behavior relates to techniques involving Account Manipulation (T1098) where an adversary modifies account attributes to establish persistence or evade detection, although in this specific context, it is limited to manipulating trust indicators rather than establishing long-term access. The lack of email confirmation for system accounts also touches upon CWE-203, which involves Observable Discrepancy between intended and actual behavior regarding security controls like verification processes.