A critical security vulnerability has been identified in Gitea, the widely used self-hosted Git service, which could allow unauthorized modifications to private repositories and trigger private Actions workflows. This flaw, designated as CVE-2026-58443, affects Gitea versions up to 1.26.4 and has been addressed in version 1.27.0.
The vulnerability resides in Gitea’s pull request update API endpoint:
POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/updateIn this context, a token restricted to public repositories with the ‘write:repository’ scope should not have the capability to access or modify private repositories. However, the flaw allows attackers to exploit this endpoint to push changes from a public base repository into a private pull request head branch. This creates an authorization bypass because Gitea validates the token restriction against the public base repository specified in the API route.
While Gitea does perform subsequent checks on the private head repository using the user account’s standard role-based permissions, it fails to reapply the active token’s public-only restriction. Consequently, a token that would typically be denied direct write access to a private repository can still modify a private branch through the pull request update function.
Security researchers have demonstrated that an attacker could first create content in a public base repository and then invoke the vulnerable update endpoint for a pull request targeting a private head branch. Gitea would then merge or rebase the public repository commits into the private branch on the server side. The risk escalates when Gitea Actions is enabled in the private head repository, as a successful server-side push can trigger workflows configured for push events in the private repository. In proof-of-concept scenarios, the injected commit initiated a matching private workflow, creating an ActionRun and associated job.
To exploit this vulnerability, an attacker needs a valid public-only token with repository write scope. The user account associated with this token must also have normal write permission on the private pull request head branch. Additionally, the attack requires a public base repository and an existing pull request relationship that permits updates from the base branch to the private head branch. This means the flaw does not grant anonymous access to private repositories but undermines an important token security boundary.
Organizations often issue public-only tokens to limit the consequences of accidental exposure or misuse in automation. This vulnerability allows such a restricted token to perform a private repository write under specific pull request conditions, thereby compromising the intended security measures.
Gitea administrators are strongly advised to upgrade to version 1.27.0 immediately. Until patches are deployed, it is crucial to review public-only tokens with repository write permissions, restrict pull request update capabilities, and audit public-to-private fork and pull request relationships. Additionally, teams should inspect Actions logs for any unexpected push-triggered workflows in private repositories.
This incident underscores the importance of rigorous access control mechanisms and the need for continuous monitoring of repository interactions. As self-hosted Git services like Gitea become integral to development workflows, ensuring their security is paramount to protect sensitive codebases and maintain the integrity of software projects.
