A critical authorization flaw in Gitea, tracked as CVE-2026-58443, allows API tokens restricted to public repositories to indirectly write into private repositories and trigger their Actions workflows.
The vulnerability, disclosed via GHSA-xxjv-752h-3vp2 based on a report from ohxorud-dev, carries a CVSS v3.1, placing it in the Critical severity band.
The bug lives in the pull request update endpoint, POST /api/v1/repos/{owner}/{repo}/pulls/{index}/update.
Gitea’s public-only token restriction is checked only against the route repository, which is the public base repo, rather than against every repository the request ultimately touches.
Critical Gitea Vulnerability
When UpdatePullRequest() processes the request, it authorizes the pull request’s head repository using standard user RBAC via IsUserAllowedToUpdate(), without re-checking the token’s public-only restriction against that head repo.
If the head repository is private, a token that cannot write to it directly can still cause Gitea to merge or rebase public base commits into the private head branch, because the push is performed server-side on behalf of the authenticated user rather than under the restricted token’s own permissions.
The impact escalates significantly when Actions is enabled on the private repository. Since the update triggers a genuine push event, it queues the repository’s push-triggered workflows exactly as a normal contributor push would, turning a token-scoping bypass into a mechanism for executing private CI/CD pipelines using only a public-scoped credential.
This is a serious integrity violation classified under CWE-863 (Incorrect Authorization), though confidentiality is not directly affected since the attacker cannot read private data through this path.
The published PoC demonstrates the full chain end-to-end. A public-only, write:repository token first creates a file in a public base repo, then attempts a direct write to the private head repo and is correctly rejected with an HTTP 404.
The same token opens a pull request from the private head branch against the public base repository, and calling the update endpoint with that token successfully merges the public commit into the private branch.
Gitea Actions then fires a corresponding ActionRun and ActionRunJob for the private repository, confirming that the injected push actually triggered private workflow execution.
According to Bircni, an attacker needs a valid public-only token belonging to a user who already has legitimate write access to the private head branch, along with an existing pull request relationship linking a public base repository to a private head repository that can be merged or rebased.
This constrains the attack to scenarios involving token mismanagement or compromised public-scoped credentials rather than arbitrary unauthenticated actors.
Affected Versions and Mitigation
Gitea versions up to and including v1.26.4 are vulnerable, and the issue is patched in v1.27.0.
Organizations running self-hosted Gitea instances should upgrade immediately, audit existing public-only tokens for unexpected pull request update activity, and review Actions workflow logs on private repositories for unauthorized push-triggered runs.
This disclosure follows a wave of Gitea security advisories throughout mid-2026, including a critical reverse-proxy authentication bypass and an SSRF flaw in webhook handling, underscoring a broader pattern of scope-boundary failures where route-level checks miss downstream resources touched by server-side operations.
Prevent critical incidents and financial loss with stronger proactive defense. Integrate a live threat feed from 15K SOCs
