CVE-2026-104626: Gitea fork workflow job revival through later approval
A user who can open a fork pull request can place workflow content with a shared run-level concurrency group into a Gitea Actions run that is awaiting approval. When a later run in that group cancels the blocked job, the run becomes terminal while still marked as needing approval. If a maintainer later approves the run, Gitea passed the already-cancelled job back through concurrency preparation, set it to waiting, and made it claimable by a matching runner, executing fork-controlled workflow code. Exploitation requires the maintainer's later approval action, Actions to be enabled, and a runner that accepts the repository's jobs.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Repositories using Gitea Actions are exposed if users can open fork pull requests, maintainers can approve pending fork workflow runs, and a runner is configured to accept jobs for the repository. The attacker-controlled code executes only after the affected run is later approved.
What does an attacker need to exploit it?
An attacker needs the ability to open a fork pull request and supply workflow content using a shared run-level concurrency group. They also need a later run in that group to cancel the blocked job, followed by a maintainer approving the original run.
Are installations without Gitea Actions enabled affected?
No. Exploitation requires Gitea Actions to be enabled.
What is the immediate mitigation if patching cannot be performed?
Avoid approving pending workflow runs originating from fork pull requests, particularly where fork-controlled workflows can use shared run-level concurrency groups. Restricting or disabling Actions runners that accept jobs for affected repositories also prevents the revived job from being executed.