Gitea administrators are strongly encouraged to upgrade their systems following the discovery of a critical authorization vulnerability.
This flaw allows public-only API tokens to modify private pull request branches and potentially trigger Gitea Actions workflows.
The vulnerability, tracked as CVE-2026-58443 and GHSA-xxjv-752h-3vp2, affects Gitea versions up to and including 1.26.4. The issue has been resolved in Gitea version 1.27.0.
Critical Gitea Flaw
The vulnerability arises from inconsistent enforcement of Gitea’s public-only token restriction. A token designated as public-only with write:repository access should not be able to access or change private repositories.
While direct write attempts against a private repository do fail, an attacker can exploit the public repository’s pull request update endpoint to induce a server-side write to a private pull request head branch.
The affected API endpoint is:
POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/updateGitea applies its public-only validation to the repository in the URL path, which is the public base repository of the pull request. Since this base repository is public, the token passes the restriction check.
Subsequently, during pull request updates, Gitea evaluates write privileges for the pull request’s head repository based on the user account’s normal role-based access control permissions, rather than re-evaluating the restrictions associated with the active API token.
As a result, a user with write access to a private fork or private pull request head repository can use a public-only token to update that private branch indirectly.
This operation merges or rebases commits from the public base repository into the private head branch, even though the same token cannot directly create or modify files in the private repository.
The vulnerability is classified as CWE-863 (Incorrect Authorization) and has a CVSS 3.1 score of 10.0, with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H.
The exploitation is network-based, requires low privileges and no user interaction, and can impact integrity and availability within a changed security context.
Researchers have demonstrated that the server-side branch update can also trigger workflows configured in private repositories. In the proof of concept, a private repository was set up with a workflow meant to execute on pushes to a specific head branch.
After a public-only token called the update endpoint for a pull request associated with that branch, Gitea created an Actions run and job for the private repository.
This behavior of triggering workflows heightens operational risk. A successful attacker may not only introduce commits from a public base into a private branch, but also activate automations linked to private repository push events.
Depending on the workflow configuration, this could consume runner capacity, alter downstream build or deployment processes, or execute commands within a trusted CI environment.
Exploitation requires a valid public-only token with write:repository scope that belongs to a user with standard write access to the private head branch.
The attacker must also control or have access to a public base repository and establish a compatible pull request relationship between the public base and private head repository.
Organizations running self-hosted Gitea should upgrade to version 1.27.0 immediately. Until they have patched their systems, administrators should review the usage of public-only tokens, revoke any unnecessary repository-write tokens, audit pull request update API activity, and inspect private repository Actions runs for any unexpected workflows triggered by pushes.
This issue was reported by ohxorud-dev, with remediation credited to Gitea contributor bircni.
Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.
