CVE-2026-103670: Gitea Actions Privilege Escalation Flaw

CVE-2026-103670 Overview

CVE-2026-103670 is a business logic flaw in Gitea Actions. When a new Actions run is inserted, Gitea cancels older runs that share the same workflow-level concurrency group. The cancellation logic does not check whether the newly inserted run still requires maintainer approval.

Fork pull request runs are inserted under the base repository. A user who can open a pull request from a fork can therefore cancel trusted, in-progress runs that share a concurrency group with cancel-in-progress enabled. The attacker needs no code execution and no approval. On self-hosted runners, this interrupts deployments and leaves partial state behind.

Critical Impact
An unauthenticated external contributor can abort trusted CI/CD runs by opening a fork pull request, disrupting deployments on self-hosted Gitea Actions runners.

Affected Products

Gitea versions prior to 28.0.0
Gitea Actions workflows using workflow-level concurrency with cancel-in-progress: true
Self-hosted Gitea instances accepting pull requests from forks

Discovery Timeline

2026-10-06 - CVE-2026-103670 published to the National Vulnerability Database (NVD)
2026-10-07 - Last updated in NVD database

Technical Details for CVE-2026-103670

Vulnerability Analysis

Gitea Actions supports GitHub-compatible concurrency groups. When a workflow defines a concurrency group with cancel-in-progress: true, inserting a new run in that group cancels any older in-progress runs. This design assumes that only authorized runs can enter the group.

Gitea inserts fork pull request runs under the base repository rather than the fork. These runs normally require maintainer approval before any job executes. The approval gate blocks code execution, but it does not block the concurrency-group side effect that fires when the run row is inserted.

The cancellation path therefore runs on behalf of an unapproved external contributor. Trusted jobs executing on self-hosted runners are terminated mid-execution. Deployments can be interrupted after partial changes are applied, leaving infrastructure in an inconsistent state.

Root Cause

The root cause is a missing authorization check [Broken Access Control] in the Actions run insertion path. The concurrency cancellation routine treats all newly inserted runs equivalently, regardless of whether they are approved, trusted base-branch runs or pending fork pull request runs. The approval boundary that governs job execution is not applied to concurrency-group membership.

Attack Vector

An attacker forks a target repository that uses workflow-level concurrency with cancel-in-progress: true. The attacker opens a pull request from the fork while a trusted workflow run is in progress on the base repository. Gitea inserts the fork pull request run into the same concurrency group and cancels the trusted run. The fork run itself never executes code because it remains pending approval. The attacker can repeat this to persistently deny workflow execution.

For technical details, see the GitHub Security Advisory GHSA-4j4g-m7mr-hp5j and the fix in Gitea Pull Request #39399.

Detection Methods for CVE-2026-103670

Indicators of Compromise

Trusted Actions runs transitioning to a cancelled state immediately after a fork pull request is opened against the base repository.
Pending fork pull request runs appearing in the same concurrency group as production or deployment workflows.
Partial deployment artifacts or incomplete state changes on self-hosted runners following unexpected cancellations.

Detection Strategies

Correlate Gitea audit logs for pull request creation events from forks with Actions run cancellation events within the same concurrency group.
Alert when a workflow run cancellation is attributable to an inserted run that is still awaiting approval.
Review workflow definitions for cancel-in-progress: true combined with deployment or release jobs, and flag these as high-value targets.

Monitoring Recommendations

Monitor the Gitea Actions API for unexpected transitions of long-running jobs from in_progress to cancelled.
Track self-hosted runner job logs for abrupt termination signals during deployment phases.
Baseline normal cancellation frequency per repository and alert on anomalies tied to external contributor activity.

How to Mitigate CVE-2026-103670

Immediate Actions Required

Upgrade Gitea to version 28.0.0 or later, which contains the fix shipped in Gitea Pull Request #39399.
Audit all workflows using workflow-level concurrency with cancel-in-progress: true and assess exposure on self-hosted runners.
Review recent cancellation events on production and deployment workflows for signs of exploitation.

Patch Information

Gitea addressed the vulnerability in release 28.0.0. The fix ensures that runs still requiring approval do not cancel existing runs in the same concurrency group. Release notes are available in the Gitea Release Announcement 28.0.0 and the Gitea Version 28.0.0 Release.

Workarounds

Remove cancel-in-progress: true from workflow-level concurrency groups used by deployment or release pipelines until the patch is applied.
Scope concurrency groups to the pull request number or ref so fork runs cannot collide with trusted base-branch runs.
Restrict pull requests from forks on repositories hosting sensitive self-hosted runner workflows.

bash

# Example: scope concurrency to the ref so fork PR runs do not cancel trusted runs
concurrency:
  group: deploy-${{ github.ref }}-${{ github.event.pull_request.number || github.sha }}
  cancel-in-progress: false