Critical Gitea CVE-2024-4696 allows private repo writes, workflow triggers

Key Takeaways

• A critical vulnerability (CVE-2026-58443) in Gitea allows restricted access tokens to bypass security controls.
• The flaw enables tokens scoped for public repositories to write to private pull request branches and trigger private Gitea Actions workflows.
• All Gitea versions up to v1.26.4 are affected; the issue is resolved in v1.27.0.
• Exploitation requires a public-only token with write permissions and existing pull request conditions, but it undermines token security boundaries.

Gitea users are urged to apply immediate updates following the disclosure of a critical vulnerability that permits access tokens, ostensibly restricted to public repositories, to indirectly modify private pull request branches and initiate private Actions workflows. This flaw represents a significant authorization bypass, undermining the intended security segmentation of access tokens.

Identified as CVE-2026-58443, the vulnerability impacts all Gitea versions through v1.26.4. The issue has been addressed in version v1.27.0. The core of the vulnerability lies within Gitea’s pull request update API endpoint, specifically POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/update.

Ordinarily, a token with write:repository scope, limited to public repositories, should be incapable of interacting with or altering private repository content. However, attackers can exploit this public pull request route to inject changes from a public base repository into a private pull request head branch. This circumvents authorization checks because Gitea initially validates the token’s restrictions against the public base repository specified in the API call.

Understanding the Gitea Vulnerability

Despite subsequent checks by the application for access to the private head repository using the associated user account’s normal role-based permissions, the critical flaw is that the system fails to reapply the active token’s public-only restriction. Consequently, a token that would be denied a direct write operation to a private repository can still successfully modify a private branch via the pull request update function.

According to the GitHub advisory (GHSA-xxjv-752h-3vp2), this vulnerability carries a Critical CVSS score of 9.6 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H). This rating signifies that the flaw can be exploited remotely with low privileges and no user interaction, primarily compromising the integrity and availability of affected systems.

Security researchers have demonstrated that an attacker can first prepare malicious content within a public base repository. They then invoke the vulnerable update endpoint for an existing pull request that targets a private head branch. Gitea would then merge or rebase the commits from the public repository into the private branch on the server side. The severity escalates significantly if Gitea Actions is enabled within the private head repository. A successful server-side push can trigger workflows configured for push events in that private repository. In a proof-of-concept exploit, the injected commit successfully initiated a corresponding private workflow, generating an ActionRun and associated job.

Successful exploitation requires several conditions: an attacker must possess a valid public-only token with repository write scope, and the user account linked to this token must also have standard write permissions on the private pull request head branch. Furthermore, the attack necessitates a public base repository and an existing pull request relationship that allows updates from the base branch to the private head branch. While this vulnerability does not grant anonymous access to private repositories, it fundamentally compromises an essential token security boundary. Organizations often issue public-only tokens to mitigate risks associated with accidental exposure or misuse in automated processes; this vulnerability allows such restricted tokens to execute private repository writes under specific pull request scenarios.

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

What You Should Do

• Upgrade Immediately: Gitea administrators should prioritize upgrading to version v1.27.0 without delay.
• Review Public-Only Tokens: Until patches are fully deployed, audit all public-only tokens that possess repository write permissions.
• Restrict Pull Request Updates: Evaluate and restrict pull request update capabilities, especially those involving public-to-private fork and pull request relationships.
• Audit Actions Logs: Scrutinize Actions logs for any unexpected push-triggered workflows in private repositories, particularly those initiated after pull request update API activity involving public base repositories.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.