Critical Gitea Vulnerability Allows Unauthorized Private Repository Writes via Pull Requests
A critical vulnerability (CVE-2026-58443) in Gitea allows attackers with public-only write tokens to modify private pull request branches and trigger private Actions workflows.
Gitea users are strongly advised to update their installations immediately following the disclosure of a critical vulnerability, tracked as CVE-2026-58443. This flaw permits attackers who possess tokens restricted to public repositories, but with write scope, to indirectly push changes to private pull request branches and consequently trigger private Actions workflows. The vulnerability affects Gitea versions up to v1.26.4, with a fix available in version v1.27.0.
The core of the vulnerability lies within Gitea's pull request update API endpoint, specifically the POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/update function. While a token intended solely for public repositories should not grant access to private ones, attackers can exploit a loophole. They can initiate a pull request targeting a private repository's head branch, using a public repository as the base. Gitea's authorization check incorrectly validates the token's public-only restriction against the public base repository specified in the API route, rather than the intended private head repository.
Although Gitea does perform a subsequent check against the user account's role-based permissions for the private head repository, it fails to re-evaluate the active token's public-only restriction at this stage. This oversight means that a token that would be rejected for a direct write operation to a private repository can still successfully modify a private branch through this indirect pull request update mechanism. This bypass undermines a crucial security boundary designed to limit the impact of compromised or misused tokens.
Security researchers have detailed how an attacker can leverage this flaw. The process involves first creating malicious content within a public base repository. Subsequently, they invoke the vulnerable API endpoint for a pull request that targets a private head branch. Gitea then proceeds to merge or rebase the commits from the public repository into the private branch on the server-side, effectively achieving an unauthorized write.
The severity of this vulnerability is amplified when Gitea Actions is enabled within the targeted private repository. A successful server-side push resulting from the exploit can trigger workflows configured to run on push events. In a proof-of-concept scenario, the injected commit initiated a matching private workflow, leading to the creation of an ActionRun and its associated job, potentially enabling arbitrary code execution within the private repository's context.
This vulnerability carries a Critical severity rating with a CVSS score of 9.6 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H). It can be exploited remotely by an attacker with low privileges and requires no user interaction. The primary impacts are on the integrity and availability of the repository and its associated workflows. It's important to note that this vulnerability does not grant anonymous access; an attacker requires a valid public-only token with repository write scope and the user account associated with that token must possess normal write permissions on the target private branch.
To mitigate this risk, Gitea administrators should immediately upgrade to version v1.27.0. Until patches can be deployed, organizations should review all public-only tokens with repository write permissions, restrict pull request update capabilities where possible, and audit pull request relationships between public and private repositories. Furthermore, monitoring Actions logs for any unexpected push-triggered workflows in private repositories, especially those initiated around the time of pull request update API activity involving public base repositories, is crucial.