Critical Gitea Flaw Lets Public-Only Tokens Write to Private Repository Branches

Gitea administrators should update their servers immediately to address CVE-2026-58443, a critical authorization vulnerability that can let a public-only access token write commits to a private repository branch. Successful exploitation can also trigger Gitea Actions workflows inside the affected private repository.

The Gitea security advisory assigns the vulnerability a CVSS score of 9.6 out of 10. All Gitea releases through version 1.26.4 contain the flaw, while version 1.27.0 includes the security fix.

Gitea released the patched version on July 12, 2026, and urged administrators to upgrade as soon as possible. The official Gitea 1.27.0 release announcement lists CVE-2026-58443 among numerous security vulnerabilities resolved by the update.

What is CVE-2026-58443?

CVE-2026-58443 affects how Gitea checks public-only personal access tokens when processing pull request updates. These tokens can carry the write:repository scope while remaining restricted to public repositories.

Under normal conditions, such a token can modify a public repository but cannot directly write to a private one. The vulnerable pull request API route checks the token against the public repository named in the request rather than consistently applying its restriction to every repository involved.

The affected endpoint is:

POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/update

How the authorization bypass works

When the request reaches the endpoint, Gitea first checks whether the token can access the public base repository. A public-only token passes this check because the API route points to a public repository.

Gitea then checks the associated user account’s regular permissions for the private pull request head repository. However, vulnerable versions do not apply the active token’s public-only restriction again before updating the private branch.

This gap allows Gitea to merge or rebase commits from the public base repository into the private head branch. A direct write with the same token would fail, but the pull request update route can complete the private repository write on the server.

Requirement	Details
Access token	A valid public-only token with the write:repository scope
User permissions	The token owner must have normal write permission for the private head branch
Repository structure	A public base repository and private pull request head repository must exist
Pull request access	The public base branch must be eligible for merging or rebasing into the private head branch
User interaction	No additional user interaction is required during exploitation

Private Actions workflows can also run

The impact can extend beyond inserting commits into a private branch. If the private repository uses Gitea Actions, the server-side push may trigger any matching workflow configured to run on push events.

The proof of concept included in the GHSA-xxjv-752h-3vp2 advisory confirms that exploitation created both an ActionRun and an associated ActionRunJob in the private repository. Gitea recorded the attacker-controlled update as a push event.

The exact consequences depend on the private workflow’s configuration and permissions. A triggered workflow could change repository content, consume runner resources, deploy software, or perform other automated operations available to that workflow.

Who can exploit the Gitea vulnerability?

This vulnerability does not allow anonymous attackers to write to arbitrary private repositories. An attacker needs a valid token linked to a user who already has write access to the targeted private pull request head branch.

The attacker also needs a suitable public-to-private pull request relationship. The public repository must act as the base, while the private repository supplies the head branch that Gitea updates.

These conditions limit the number of practical targets. However, the vulnerability still defeats an important security boundary used to reduce the damage from leaked or misused automation tokens.

• The attack requires authentication.
• The token must include public-only and repository-write permissions.
• The associated account must already have private branch write access.
• The private repository must have a compatible pull request relationship with a public repository.
• Gitea Actions must be enabled for workflow execution to become part of the attack.

Why CVE-2026-58443 received a critical rating

CVE-2026-58443 carries a CVSS 3.1 score of 9.6 and the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H. The rating reflects remote exploitation, low attack complexity, low required privileges, and no required user interaction.

The advisory rates the potential impact on integrity and availability as high. It records no direct confidentiality impact because the demonstrated attack modifies a private branch rather than reading private repository data.

Gitea classifies the flaw as CWE-863, Incorrect Authorization. Security researcher ohxorud-dev reported the vulnerability, while bircni developed the remediation incorporated into version 1.27.0.

How to protect Gitea servers

Administrators should upgrade every affected Gitea instance to version 1.27.0 or a later supported release. The official release notes recommend backing up Gitea data before replacing the binary or Docker container and restarting the service.

Organizations should also rotate any public-only repository tokens that may have leaked or reached untrusted systems. Removing unnecessary write:repository scopes can reduce exposure while administrators complete the upgrade.

Security teams should review private repository branches and Actions logs for unexpected activity. Investigators should pay particular attention to push-triggered workflows that followed pull request update API requests involving public base repositories.

1. Identify all Gitea servers running version 1.26.4 or earlier.
2. Back up repositories, configuration files, databases, and other Gitea data.
3. Upgrade each affected server to Gitea 1.27.0 or later.
4. Restart the Gitea service and confirm the installed version.
5. Review public-only tokens carrying the write:repository scope.
6. Rotate exposed tokens and revoke those that no longer serve a business purpose.
7. Audit public-to-private pull request relationships and private branch histories.
8. Inspect Actions runs for unexpected push events or jobs.

FAQ