CVE-2026-66877 in Gitea
Summary
by MITRE • 10/15/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability described involves a logic flaw in Gitea's handling of GitHub Actions workflows, specifically concerning the enforcement of first-time contributor approvals for pull requests from forks. The system is designed to block jobs initiated by untrusted fork contributors until they receive explicit approval from repository maintainers. This security control aims to prevent arbitrary code execution on self-hosted runners and restrict access to sensitive secrets that are not shared with external contributions. However, the implementation contains a race condition or state management error where certain job transition paths fail to re-evaluate this critical approval requirement before dispatching jobs for execution.
The core technical flaw arises from how concurrency groups interact with pending job cancellations. When a separate workflow run shares a job-level concurrency group with another run, it can trigger the cancellation of pending jobs in that group. In normal operation, cancelling a job should simply stop its execution or prevent new instances from starting within that scope. However, due to the incomplete re-check logic, this cancellation event inadvertently causes blocked sibling jobs—those waiting for approval—to be re-emitted and dispatched without verifying their authorization status. This bypasses the intended security gate, allowing workflow code written by unreviewed fork contributors to execute on self-hosted runners despite lacking mandatory maintainer oversight.
The operational impact of this vulnerability is significant because it undermines the isolation model between trusted repository workflows and untrusted external contributions. While the attack does not grant access to fork secrets or elevate token permissions beyond read-only, it allows arbitrary code execution in an environment that may have network access to internal resources or sensitive infrastructure. Self-hosted runners often possess broader privileges than GitHub-hosted runners, making this bypass particularly dangerous as it could lead to lateral movement within a private network or exfiltration of data accessible only from the runner's local context. The absence of secret leakage limits the blast radius but does not eliminate the risk of system compromise through malicious code execution.
This issue aligns with CWE-20, which describes Improper Input Validation, as the application fails to properly validate the authorization state during specific job lifecycle transitions. It also relates to ATT&CK technique T1654, Logical Vulnerability, where an attacker exploits a flaw in business logic rather than traditional input parsing errors. The mitigation requires ensuring that all code paths leading to job dispatching, including those triggered by concurrency group cancellations or re-emissions, strictly enforce the approval check before allowing execution. Developers should audit workflow files for complex concurrency configurations and ensure that state checks are idempotent and consistently applied across all transition events. Updating Gitea to a patched version is essential to resolve this logic gap and restore the integrity of the fork contribution security model.