CVE-2026-66877: Gitea fork workflow approval bypass through concurrency cancellation
Gitea enforces first-time fork contributor approval by blocking jobs, but some job transition and dispatch paths do not re-check the run's approval requirement. A separate run sharing a job-level concurrency group can cancel a pending job and cause its blocked sibling jobs to be re-emitted and dispatched without approval. This allows unreviewed workflow code to execute on self-hosted runners; fork secrets remain withheld and the run token remains read-only.
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Instances that run workflows from first-time fork contributors on self-hosted runners are exposed. The issue can cause unreviewed fork workflow code to execute on those runners.
What does an attacker need to exploit the bypass?
The attacker needs to submit workflow activity from a first-time fork contributor and use a separate run that shares a job-level concurrency group. That separate run can cancel a pending job and trigger dispatch of blocked sibling jobs without approval.
Are repository secrets or write-capable run tokens exposed?
Fork secrets remain withheld, and the run token remains read-only. The primary impact described is execution of unreviewed workflow code on self-hosted runners.
What configuration condition is central to exploitation?
The affected workflow activity must involve a job-level concurrency group shared with another run. The cancellation and re-dispatch behavior of that shared group is what enables the approval bypass.