CVE-2026-94205: Gitea fork workflow approval bypass through maintainer-triggered events
Gitea Actions decided whether a fork pull request run needed approval based on the user who triggered the event rather than the pull request author. For pullrequest activity triggered by a maintainer during ordinary triage, such as adding a label, the run was created without requiring approval, while the workflow definition was still taken from the fork head. Where Actions is enabled and a matching runner is registered, fork-controlled workflow code could run on the base repository's runners without an explicit approval.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments are exposed where Gitea Actions is enabled and a matching runner is registered. The affected scenario involves pull requests from forks whose workflow definitions are taken from the fork head.
What maintainer action can trigger the vulnerable workflow run?
Ordinary pull-request triage activity by a maintainer, such as adding a label, can trigger a pull_request event. Gitea evaluates approval based on that maintainer-triggered event rather than on the fork pull request author.
What can an attacker achieve if the vulnerable conditions are present?
A fork author can have fork-controlled workflow code executed on the base repository's runners without explicit approval. This occurs when the maintainer-triggered pull_request activity creates a run using the workflow definition from the fork head.