CVE-2026-103670 in Gitea
Summary
by MITRE • 10/06/2026
When a Gitea Actions run was inserted, older runs in the same workflow-level concurrency group were cancelled without checking whether the new run still needed approval. Because fork pull request runs are inserted under the base repository, a user who can open a pull request from a fork could cancel trusted in-progress runs that share a concurrency group with `cancel-in-progress` enabled, without approval and without running any code. On self-hosted runners this can interrupt deployments and leave partial state behind.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability described constitutes a critical logic flaw within the Gitea Actions workflow execution engine, specifically affecting how concurrency groups manage run cancellation policies when new jobs are queued. In standard continuous integration and deployment pipelines, the `cancel-in-progress` configuration is designed to optimize resource usage by terminating older runs of the same workflow that have not yet completed, thereby allowing newer changes to take precedence immediately. However, this implementation fails to adequately distinguish between trusted internal workflows and untrusted external contributions when determining which existing jobs should be terminated. The core technical flaw lies in the absence of a verification step for approval requirements before executing the cancellation command. When a new workflow run is inserted into the queue, the system indiscriminately cancels older runs within the same concurrency group without evaluating whether those pending or in-progress runs require manual human intervention to proceed.
This oversight creates a significant security gap regarding fork pull request workflows. In many open-source and collaborative projects, pull requests from forks are treated as untrusted sources because they can execute arbitrary code on the contributor's machine but may also trigger actions within the base repository under specific configurations. When such a pull request triggers a workflow run that shares a concurrency group with other runs in the base repository, the insertion of this new run causes the system to cancel older, potentially trusted runs. Crucially, these cancelled runs might be waiting for manual approval from maintainers or security teams before proceeding to sensitive stages like deployment. By cancelling them without checking their approval status, an attacker who can open a pull request effectively bypasses the required human-in-the-loop controls. This allows the malicious actor to disrupt legitimate operational processes without ever executing any code within the target environment, relying solely on the structural behavior of the concurrency group management logic.
The operational impact of this vulnerability is severe, particularly for organizations utilizing self-hosted runners and automated deployment pipelines. The premature cancellation of in-progress runs can lead to interrupted deployments, leaving systems in a partial or inconsistent state that may require manual intervention to resolve. This not only causes downtime but also introduces potential security risks if the partial state involves incomplete configuration updates or database migrations. Furthermore, this behavior undermines the reliability of continuous delivery processes by allowing external contributors to arbitrarily halt internal operations simply by submitting new pull requests. It represents a denial-of-service condition against legitimate administrative workflows and compromises the integrity of approval gates that are essential for maintaining secure release practices.
From a classification perspective, this vulnerability aligns with CWE-841, Improper Enforcement of Behavioral Workflow, as it involves a failure to enforce expected procedural steps such as manual approvals before taking action on system resources. It also relates to CWE-693, Protection Mechanism Failure, where the security control designed to prevent unauthorized actions (in this case, cancelling approved or pending jobs) is bypassed due to flawed logic in handling external inputs. In terms of offensive cybersecurity frameworks, this behavior can be mapped to MITRE ATT&CK technique T1495, Endpoint Denial of Service, as it disrupts the availability and functionality of CI/CD infrastructure through logical exploitation rather than resource exhaustion.
To mitigate this vulnerability, developers must implement strict validation checks within the concurrency group cancellation logic. Specifically, before cancelling any older run in a shared concurrency group, the system should verify whether that run has pending approval requirements or is part of a protected branch workflow that mandates human intervention. If such conditions are met, the new incoming run from an untrusted source like a fork pull request should either be queued behind the existing runs rather than triggering their cancellation, or it should be explicitly blocked until the conflicting trusted runs have completed or been manually dismissed by authorized personnel. Additionally, administrators can mitigate risk by restricting `cancel-in-progress` policies to only apply within specific contexts that do not overlap with approval-gated workflows, ensuring that critical deployment pipelines remain insulated from interference caused by external contributions.