Gitea users are urged to update immediately after a critical vulnerability was disclosed that allows public-only repository access tokens to indirectly write to private pull request branches and trigger private Actions workflows.

Tracked as CVE-2026-58443, the vulnerability affects Gitea versions up to v1.26.4 and has been fixed in v1.27.0. The flaw exists in Gitea’s pull request update API endpoint:

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

A token restricted to public repositories, with the write:repository scope, should not be able to access or modify a private repository.

However, attackers can exploit the public pull request route 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 named in the API route.

Gitea Vulnerability

While the application later checks access to the private head repository using the user account’s normal role-based permissions, it does not reapply the active token’s public-only restriction.

Therefore, a token that fails when attempting a direct write to a private repository can still modify a private branch through the pull request update function.

According to the GitHub advisory (GHSA-xxjv-752h-3vp2), the vulnerability is rated Critical with a CVSS score of 9.6 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H), meaning it can be exploited remotely with low privileges and no user interaction, primarily impacting integrity and availability.

Security researchers demonstrated that an attacker could first create content in a public base repository, then invoke the vulnerable update endpoint for a pull request targeting a private head branch.

Gitea would merge or rebase the public repository commits into that private branch on the server-side. The issue becomes more severe when Gitea Actions is enabled in the private head repository.

A successful server-side push can trigger workflows configured for push events in the private repository. In the proof of concept, the injected commit started a matching private workflow, creating an ActionRun and associated job.

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. However, it undermines an important token security boundary.

Organizations may 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.

Gitea administrators should immediately upgrade to v1.27.0 and, until patches are deployed, review public-only tokens with repository write permissions, restrict pull request update capabilities, and audit public-to-private fork and pull request relationships.

Teams should also inspect Actions logs for any unexpected push-triggered workflows in private repositories, paying particular attention to workflows initiated after pull request update API activity involving public base repositories.

The vulnerability is classified as CWE-863, Incorrect Authorization. The advisory credits researcher ohxorud-dev for reporting the issue, with bircni publishing the advisory.

The Privilege Paths Attackers See That You Don’t: BeyondTrust Pathfinder Platform Does It for You -> Get Free Identity Security Assessment

The post Critical Gitea Vulnerability Enables Private Repository Writes and Actions Workflow Triggers appeared first on Cyber Security News.