In Gitea versions before 1.27.0, the function GetActionsUserRepoPermission incorrectly grants code-read permission to a fork pull-request Actions workflow on a private repository B if B lists the fork's base repository owner A as a collaborative owner. This is due to the absence of a check for task.IsForkPullRequest in the collaborative-owner branch of the permission logic, unlike sibling branches that correctly deny fork PRs cross-repo access. Consequently, an attacker controlling a fork PR workflow can clone and read repository B, which they have no direct rights to, resulting in a confidentiality breach. The vulnerability requires that repository B is configured to trust owner A as a collaborative owner and that the fork PR workflow runs, typically after prior approval. The issue is limited to read-only access and does not allow write or code execution.

This vulnerability leads to a confidentiality breach where an attacker controlling a fork pull-request workflow can read the full source code of a third private repository that trusts the fork's base repository owner as a collaborative owner. The attacker gains unauthorized read access to repository B despite having no direct permissions on it. The breach is read-only, with no impact on integrity or availability. The exploit requires repository B to be private and configured with a collaborative owner trust relationship, and the fork PR workflow must be executed.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The suggested remediation is to add a guard that denies fork pull-request workflows the collaborative-owner cross-repo read permission, matching sibling permission branches. Until an official fix is available, avoid configuring private repositories with collaborative-owner trust for repositories that accept fork pull-requests, or restrict fork PR workflow execution. Monitor vendor communications for an official patch release.