EUVD-2026-93911Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessOpen pull request from fork
-
ExploitTrigger Actions run insertion
-
ExecutionCancel trusted concurrency-group run
-
ImpactInterrupt deployment, leave partial state
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Proper locking
|
| Exploitation Conditions | Requires (1) a target repository whose workflows define a workflow-level concurrency group with cancel-in-progress enabled, (2) the instance permitting pull requests from forks against that base repository, and (3) the attacker possessing an account able to open such a fork PR. The impact (interrupted deployments, partial state) specifically affects self-hosted runners performing deployments. Limiting factors: no effect without the cancel-in-progress concurrency configuration, no exploitation if fork PRs are disabled or restricted, and the attacker cannot run code or read data - only cancel runs. These constraints make it a targeted CI-disruption vector rather than broad default-config exposure. |
| Impact | Signals are consistent in pointing to a real but conditional, lower-priority issue rather than an urgent one. The vendor CVSS of 7.5 is driven entirely by integrity (I:H) - cancellation of trusted in-progress runs - with no confidentiality or availability impact and no code execution, which matches CWE-667 (improper locking / concurrency handling). Exploitation-probability signals are weak and corroborating: EPSS is 0.16% (4th percentile), the CVE is NOT in CISA KEV, and no public exploit code was identified - only the vendor fix PR #39399. There is a notable discrepancy to verify: the CVSS vector states PR:N (unauthenticated), but the description requires 'a user who can open a pull request from a fork,' which on most Gitea deployments requires a registered account - treat the unauthenticated rating with caution and assume at least low-privilege authentication in practice. Exploitation is further gated by a specific workflow configuration (concurrency group with cancel-in-progress), so this is a targeted CI-abuse/integrity concern for self-hosted CI operators, not a wormable or mass-exploitable flaw. |
| Exploit ScenarioDerived | An attacker with an account on a Gitea instance opens a pull request from a fork against a repository whose workflows use a concurrency group with cancel-in-progress enabled. Because the fork PR run is inserted under the base repository, its insertion cancels a trusted, in-progress deployment run sharing that concurrency group - without approval and without executing any attacker code - interrupting the deployment and leaving partial state. No public exploit exists; only the vendor fix (PR #39399) describes the flaw. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Authenticated users who are able to open a pull request from a fork can cancel trusted, in-progress Gitea Actions runs in the base repository when those runs share a workflow-level concurrency group with cancel-in-progress enabled, because the cancellation logic does not check whether the newer run still needs approval before terminating the older ones. The attacker runs no code and gains no data access, but on self-hosted runners the interruption can abort an in-flight deployment and leave partial state behind. No public exploit code has been identified at time of analysis and EPSS is low at 0.16% (4th percentile), consistent with a targeted, configuration-dependent CI-disruption issue rather than a broad default-config exposure.
RemediationAI
Upgrade to Gitea v28.0.0 or later, which contains the fix (vendor-released patch: v28.0.0, source change in PR https://github.com/go-gitea/gitea/pull/39399); the release notes at https://blog.gitea.com/release-of-28.0.0/ and the advisory at https://github.com/go-gitea/gitea/security/advisories/GHSA-4j4g-m7mr-hp5j document the change. If immediate upgrade is not possible, the most effective compensating control is to remove cancel-in-progress from workflow-level concurrency groups that are shared between fork pull request runs and trusted branch runs - the trade-off is that superseded runs will queue and consume runner slots rather than being pruned, which increases concurrency pressure on self-hosted runners. Alternatively, disable pull requests from forks entirely (or restrict them to first-time-contributor approval mode) on repositories that deploy via Actions, at the cost of losing a common external-contribution workflow. Splitting trusted deployment workflows into dedicated concurrency group names that fork PRs cannot collide with also mitigates the issue without disabling forks, though it requires auditing every workflow file. Finally, hardening self-hosted deployment runners so that an aborted job cannot leave partially applied state (idempotent deploy steps, transactional rollouts, or locking the deployment target) reduces the blast radius if cancellation does occur.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Gitea Actions implements workflow-level and job-level concurrency groups so that only one run in a group proceeds at a time; when cancel-in-progress is enabled, a newly inserted run cancels the older runs in the same group. Because pull request runs originating from forks are attributed to and inserted under the base repository, an attacker-controlled fork PR can enter the same concurrency group as a trusted branch run. The backend handler that inserts the run cancelled previously queued or running jobs before evaluating whether the new run was itself gated by approval (NeedApproval), so an unapproved fork-PR run could preempt an already-approved trusted run that had started executing. This is a synchronisation/ordering defect in the concurrency control path, classified as CWE-667 (Improper Locking) since the concurrency group acts as a mutual-exclusion primitive that is released and reassigned without verifying the state of the competing run. The upstream fix introduces an ActionRun.IsAwaitingApproval() helper (NeedApproval && !Status.IsDone()), excludes the current attempt's own run from CancelPreviousJobsByRunConcurrency via slices.DeleteFunc, and re-runs concurrency preparation in ApproveRuns so that approval-time promotion of a blocked run properly accounts for sibling jobs already cancelled in the same loop. The impact is limited to integrity of run scheduling (CVSS integrity:H, confidentiality and availability unaffected): the attacker cannot execute workflow code, read secrets, or modify repository contents - only disturb the ordering of trusted runs.
Know when Gitea gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Opening a fork PR requires an authenticated account (PR:L, not PR:N); no user interaction; cancelling trusted deployment runs corrupts state (I:H) with no confidentiality and no code execution.
Primary rating from Vendor (88ee5874-cf24-4952-aea0-31affedb7ff2).
CVSS VectorVendor: 88ee5874-cf24-4952-aea0-31affedb7ff2
Lifecycle Timeline
3DescriptionCVE.org
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.
Technical POC Analysis
CWE-667 (Improper Locking), per the CVE record (the GitHub advisory itself lists no CWE).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Gitea Actions on self-hosted Gitea instances can allow users who can open fork pull requests to cancel trusted in-progress workflow runs when workflow-level concurrency with cancel-in-progress is enabled, potentially aborting deployments and leaving partial state. Leadership should care because this configuration-dependent CI disruption can affect release integrity and availability, though no public exploit has been identified and no data access or code execution is reported.
No vendor-released patch identified at time of analysis. Interim mitigations: disable cancel-in-progress for workflow-level concurrency groups protecting trusted deployment runs; require approval for fork pull request workflow runs before they can cancel or join shared concurrency groups; use separate concurrency groups for trusted and untrusted runs; restrict fork pull requests to trusted users or disable them for sensitive repositories; ensure deployments are idempotent and support rollback/checkpointing; monitor Gitea audit logs and Actions cancellations for anomalies.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Remote code execution in Gitea (self-hosted Git service) via a code-injection flaw (CWE-94) allows attackers to run arbi
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r
Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea
Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged us
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any
Path traversal in Gitea's Org-mode (`.org`) markup renderer allows an attacker who can get Org-mode content rendered by
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec
models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to rem
Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authentica
Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth gran
Exploit-DB