Critical Gitea Flaw (CVE-2026-58443) Lets Public Tokens Write to Private Repos

A newly disclosed critical vulnerability in Gitea, the popular self-hosted Git service, allows an access token restricted to public repositories to silently write commits into private repositories through a pull request update endpoint.

Tracked as CVE-2026-58443 and rated CVSS 9.6, the flaw was published as GHSA-xxjv-752h-3vp2 by security researcher bircni, with credit also going to reporter ohxorud-dev.

Gitea’s token system supports a “public-only” restriction meant to guarantee that a token can never touch private data, even if it also carries write:repository scope.

Critical Gitea Flaw

The bug lives in the pull request update route, POST /api/v1/repos/{owner}/{repo}/pulls/{index}/update, which sits under a repository route group that checks the public-only restriction against ctx.Repo.

Repository the base repository named in the URL, not the pull request’s head repository. Because that base repository is public, a public-only token sails through the route-level check without issue.

Once inside, the UpdatePullRequest handler calls IsUserAllowedToUpdate(), which evaluates the caller’s ordinary account-level RBAC permissions on the head repository rather than re-checking the active token’s public-only restriction.

If the head repository happens to be private, and the underlying user account has legitimate write access to it, Gitea proceeds to merge or rebase the base branch into that private head branch and push the result server-side.

The same token that gets a flat 404 when attempting a direct write to the private repository succeeds when the write is routed through the public PR update endpoint instead.

The proof-of-concept published alongside the advisory demonstrates the full attack chain: a public-only, write:repository token creates content in a public base repo, opens a pull request against a private forked head repository, then calls the update endpoint to force that public content into the private branch.

Notably, if GitHub Actions-equivalent workflows are enabled on the private repository, the injected push also triggers the repository’s private CI/CD pipeline, spawning an ActionRun and ActionRunJob tied to the attacker-controlled commit, turning a data-integrity bug into a potential execution primitive inside a private environment.

Under CVSS 3.1 scoring, the vulnerability carries a changed scope with high integrity and availability impact but no confidentiality loss, reflecting that the flaw enables unauthorized modification and potential denial-of-service through unwanted workflow triggers rather than direct data exposure.

It is classified under CWE-863 (Incorrect Authorization), a pattern where an authorization check exists but is applied to the wrong resource context

Remediation

Gitea maintainers shipped the fix in version 1.27.0, which was released alongside a broader batch of security hardening changes.

Administrators running self-hosted Gitea instances should upgrade immediately and, in the interim, audit any tokens that combine the public-only and write: repository scopes, since revoking or rotating those tokens closes the exploitation path without requiring an upgrade.

This flaw arrives amid a string of Gitea authorization issues disclosed through 2026, including a separate bearer-token scope bypass (CVE-2026-28744) and a private container registry exposure (CVE-2026-27771), suggesting that Gitea’s layered permission model spanning tokens, route-level checks, and repository RBAC remains a persistent source of subtle authorization gaps as the platform’s feature surface expands.

Teams relying on scoped tokens for CI/CD or automation should treat “public-only” as a guideline enforced inconsistently across endpoints, not an absolute guarantee, until similar route-versus-resource mismatches are systematically audited across the API surface.

This is less a single bug than a design pattern that keeps recurring wherever a route’s declared repository and the resource ultimately mutated by that route diverge.