EUVD-2026-93905Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain Actions write access on repo
-
DeliveryIdentify fork PR run awaiting approval
-
ExploitCancel the pending-approval run
-
ExecutionRe-run, recreating jobs as waiting not blocked
-
PersistFork-supplied workflow executes on runner
-
ImpactAccess CI secrets and compromise runner
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization verification
MITRE ATT&CK
1 technique across 1 tactic: Defense Evasion The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires all of the following concrete conditions, drawn from the description: (1) Gitea Actions must be enabled on the repository and at least one matching runner must be registered; (2) a pull request must originate from a first-time fork contributor so that the maintainer-approval gate is actually engaged (run.NeedApproval set); (3) the attacker must hold Actions write access on the repository (CVSS PR:L), enabling them to cancel and re-run the run; and (4) a run must be in the awaiting-approval state to be cancelled and re-run. The limiting factors are the Actions-write privilege requirement and the need for the fork-approval workflow to be in use - repositories that disable Actions, use no self-hosted/registered runners, or do not accept external fork pull requests are not exposed. No end-user interaction is required (UI:N). |
| Impact | Signals point to a genuine but not emergency-grade issue. The CVSS 3.1 base score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects total technical impact - arbitrary fork-supplied workflow code executing on the repository's runners - which aligns with the SSVC 'Technical Impact: total' rating. However, the exploitation-probability signals all point low: EPSS is 0.16% (4th percentile), SSVC records 'Exploitation: none' and 'Automatable: no', the CVE is not listed in CISA KEV, and no public exploit code was identified (the only code artifact provided is the upstream fix, PR #39399, not an exploit). The key limiting factor is PR:L: the CVSS vector confirms the actor must already hold Actions write access on the repository, so this is an authorization-control bypass exploitable by a semi-trusted insider/contributor rather than an anonymous internet attacker. Net: a real priority for organizations running Gitea Actions with external fork contributors and self-hosted runners, but the required privilege and absence of any exploitation evidence make targeted misuse far more likely than widespread automated attack. No signals are in direct conflict; the high CVSS and low EPSS are reconcilable because CVSS measures impact while EPSS measures likelihood, and the PR:L precondition explains the low likelihood. |
| Exploit ScenarioDerived | A contributor who has been granted Actions write access on a Gitea repository notices a first-time fork pull request whose CI run is paused awaiting maintainer approval. They cancel that pending run and immediately re-run it; because the rerun path only checked that the prior run had finished, the new jobs are created as waiting instead of blocked, and the fork's workflow code executes on the repository's self-hosted runners with no approval. This lets untrusted pull-request code reach CI secrets and the runner environment. No public exploit code was identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Gitea Actions in versions up to and including 1.27.3 can execute workflow code from an untrusted fork pull request head on the repository's runners without the maintainer approval that the first-time-contributor gate is supposed to require. An authenticated user holding Actions write permission can cancel a run that is still awaiting approval and then re-run it; the rerun path recreated the attempt's jobs as waiting instead of blocked while the run still recorded that approval was required, so the jobs were released without an approval decision. Signals point to a genuine but not emergency-grade issue: exploitation requires Actions enabled, a registered matching runner, a fork pull request from a first-time contributor, and Actions write access (CVSS PR:L), no public exploit code was identified at time of analysis, and EPSS is low at 0.16% (4th percentile).
RemediationAI
Upgrade Gitea to 28.0.0 or later, which is the vendor-released fix identified in the advisory, the vendor release blog (https://blog.gitea.com/release-of-28.0.0/), and the release tag (https://github.com/go-gitea/gitea/releases/tag/v28.0.0); the code-level fix is the upstream pull request https://github.com/go-gitea/gitea/pull/39399, which adds the IsAwaitingApproval() check so re-run attempts cannot be released without an approval decision. If immediate upgrade is not possible, the actionable compensating controls are: disable Gitea Actions on repositories that accept pull requests from external forks (this removes the execution path entirely but also disables all CI for those repositories), restrict Actions write permission to trusted maintainers only, since the bypass requires a user who can cancel and re-run a run, and avoid registering broadly accessible self-hosted runners that untrusted fork code could reach (limiting runner scope reduces the value of the bypass but does not remove it). Because the underlying defect is an authorization-logic gap rather than a configuration error, no configuration change fully replaces the patch; where approval-required workflows must remain enabled, treat any pre-28.0.0 cancellation-and-rerun of an unapproved fork run as a potential unreviewed code execution and review runner logs and workflow artifacts for those runs. Additional detail is available in the GitHub advisory GHSA-pvjf-7jrm-6w9g and the VulDB entry https://vuldb.com/vuln/414536.
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
The root cause is CWE-285 (Improper Authorization): Gitea's fork pull request approval gate is tracked on an ActionRun via the NeedApproval flag, but the logic that rebuilds jobs on a re-run only checked whether the run was finished and never re-evaluated whether approval was still pending. The upstream fix introduces an IsAwaitingApproval() helper on ActionRun (NeedApproval && !Status.IsDone()) and uses it consistently in the API approve handler, the web run view, ApproveAllChecks, and the merge-box status check, so that a cancelled-and-re-run attempt whose approval requirement is still outstanding produces jobs in the blocked state rather than the waiting state. The patch (PR 39399, models/actions/run.go, services/actions/approve.go, routers/api/v1/repo/actions_run.go, routers/web/repo/actions/view.go, routers/web/repo/pull.go) also adjusts concurrency handling so that approval releases only genuinely blocked jobs and excludes sibling jobs cancelled by the same concurrency group. The affected component is Gitea's built-in CI/CD subsystem, Gitea Actions, which pulls workflow definitions from the pull request head commit; when the approval check is skipped, the runner executes attacker-controlled workflow YAML in the context of the repository's registered runners. Per EUVD, all Gitea releases from 0 through 1.27.3 are affected; the issue is resolved in 28.0.0. The assessed CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8) reflects network-reachable exploitation by an authenticated Actions-write user with no user interaction, and total technical impact (CISA SSVC technical impact: total), consistent with code execution on CI runners that typically hold repository credentials.
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:L/UI:N/S:U/C:H/I:H/A:H
Remotely reachable (AV:N), routine cancel-and-rerun (AC:L), requires Actions write access so PR:L, no user interaction; arbitrary workflow code on runners yields full C/I/A impact.
Primary rating from Vendor (88ee5874-cf24-4952-aea0-31affedb7ff2).
CVSS VectorVendor: 88ee5874-cf24-4952-aea0-31affedb7ff2
Lifecycle Timeline
3DescriptionCVE.org
Gitea Actions blocks the jobs of workflow runs from first-time fork pull request contributors until a maintainer approves the run. The rerun path only required a run to be finished and built the new attempt's jobs without considering the pending approval, so when a user with Actions write access cancelled a run that was awaiting approval and then re-ran it, the new jobs were created as waiting rather than blocked while the run still recorded that approval was required. Cancelling and re-running stale fork checks is a routine action that does not involve the approval control, so where Actions is enabled and a matching runner is registered, workflow code taken from the fork pull request head could run on the repository's runners without an explicit approval.
Technical POC Analysis
CWE-285 (Improper Authorization) per the CVE record; the GHSA itself lists no CWE and scores 9.0 Critical versus the CVE's 8.8 High.
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, the self-hosted CI/CD engine in Gitea deployments (affected through version 1.27.3), can be induced to run workflow code from an untrusted fork pull request on the organization's own runners without the maintainer approval the platform is supposed to enforce, meaning third-party code could execute on infrastructure that typically holds deployment credentials, registry tokens, and network access to internal systems. The flaw is triggered by an authenticated user holding Actions write permission - a low bar inside many engineering organizations - though it requires Actions to be enabled, a matching runner to be registered, and a fork pull request from a first-time contributor, so exposure is limited to teams that accept external contributions or run Actions on credentialed runners. Leadership should treat this as a supply-chain integrity gap rather than an active breach: there is no public exploit identified at time of analysis and exploitation is confirmed to require authenticated privileges, but the dependency on a vendor fix (none released at time of analysis) means interim policy controls are the only near-term defense.
No vendor-released patch identified at time of analysis. Interim mitigations: disable automatic workflow execution from fork pull requests and require maintainer approval for all outside contributors; restrict or remove Actions write permission from non-essential accounts, as the issue is only reachable by authenticated users with that permission and no public exploit was identified at time of analysis (CISA KEV: not listed); audit Actions logs for cancel-then-rerun sequences that bypass the approval gate; rotate secrets and tokens accessible to runners if such reruns are found; scope workflow secrets to protected environments not exposed to fork-originated runs; and segment runner network access to limit lateral movement if untrusted code does execute.
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
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
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