CVE-2026-104632

Executive Summary

CVE-2026-104632 is an authorization bypass in Gitea Actions that allows workflow code from a first-time fork pull request contributor to execute on a repository's registered runners without the maintainer approval that the first-time contributor policy is designed to enforce. The flaw is triggered by a user holding Actions write access who cancels a workflow run that is awaiting approval and then re-runs it, causing the new attempt's jobs to be created in a waiting state while the run still records that approval was required. Any organization self-hosting Gitea with Actions enabled and at least one matching runner registered is exposed to untrusted code execution within its CI infrastructure.

Technical Analysis

Gitea Actions implements a security control for fork-based contributions: when a pull request originates from a first-time contributor's fork, the workflow runs associated with that pull request are placed in a blocked state and do not execute until a maintainer explicitly approves them. This control exists because fork pull request workflow code is attacker-controlled — the fork head commit contains the workflow definitions and scripts that would run inside the repository's CI environment.

The defect described lies in the re-run code path. According to the NVD description, the rerun path "only required a run to be finished and built the new attempt's jobs without considering the pending approval." In other words, the conditions checked before allowing a re-run did not include the state of the approval gate. A user with Actions write access can cancel a run that is awaiting approval and then re-run it. During the re-run, the new attempt's jobs are constructed as "waiting" rather than "blocked," even though the run still records that approval was required. The result is a state inconsistency: the run metadata asserts that approval is pending, but the individual jobs are in a schedulable state.

Because the jobs are no longer blocked, and because the workflow definition is taken from the fork pull request head, the attacker-controlled workflow code becomes eligible to execute. The description states this occurs "where Actions is enabled and a matching runner is registered." A matching runner is any runner whose labels and scope satisfy the job's requirements, which for many repositories is simply the default self-hosted or hosted runner pool.

The vulnerability class is a state-machine / authorization inconsistency rather than a memory-safety or injection flaw. The approval gate is enforced at run creation and at the initial job-construction stage, but not at the job-construction stage of a re-run attempt following cancellation of a pending-approval run. The "cancel + re-run" sequence is described as "a routine action that does not involve the approval control," meaning operators perform it regularly on stale fork checks without any expectation that it interacts with the approval logic. This makes the bypass both low-friction and easy to trigger accidentally as well as deliberately.

No further code-level detail (specific function names, handler paths, or API endpoints) is available in the provided data. The analysis above is limited to the mechanism explicitly described in the NVD entry.

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template is available for CVE-2026-104632. The attack chain below is inferred strictly from the vulnerability class and the behavior described in the NVD entry.

1. Reconnaissance / target identification. The attacker identifies a Gitea instance hosting a target repository with Actions enabled, where fork pull requests from first-time contributors are subject to maintainer approval. The attacker needs the ability to open a pull request from a fork — the standard, unauthenticated-or-low-privilege contribution path on a public instance — and the attacker (or a colluding party) needs a Gitea account with Actions write access on the target repository. The latter is a moderate privilege: it is typically held by maintainers, trusted contributors, or automation accounts, and may be obtainable through compromised credentials, insider access, or overly permissive team configuration.

2. Triggering the flaw class. The attacker pushes a branch to their fork whose head commit contains a malicious workflow definition — the payload is the workflow itself, since fork pull request workflow code is executed by design once approval is granted. The attacker opens a pull request against the target repository. Gitea places the resulting workflow run in the blocked/awaiting-approval state, as intended for first-time fork contributors. At this point the approval control has not been defeated.

3. Bypassing the approval gate. Using the account with Actions write access, the attacker (or their colluding account) cancels the run that is awaiting approval, then re-runs it. Due to the described defect, the re-run path does not re-evaluate the pending-approval condition and constructs the new attempt's jobs in the waiting state rather than the blocked state. The run still records that approval was required, but the jobs are now eligible for scheduling.

4. Execution and post-exploitation impact. Provided Actions is enabled and a matching runner is registered, the jobs dispatch to the repository's runner infrastructure, and workflow code taken from the fork pull request head executes. From that position the attacker gains code execution in the CI environment: they can access repository secrets and tokens exposed to the workflow, read the source and any artifacts available to the job, interact with the runner's network and filesystem, and potentially pivot to infrastructure reachable from the runner (build caches, package registries, deployment targets, cloud metadata endpoints). The exact secrets and permissions available depend entirely on the target repository's workflow configuration and runner deployment model, and no specifics of that configuration are available in the provided data.

Impact Assessment

The primary impact is unauthorized code execution within a CI/CD trust boundary. Because CI runners frequently hold repository-scoped credentials, deployment keys, cloud provider identities, and network access to internal systems, a successful bypass can escalate from "untrusted fork code" to "compromise of build and deployment pipelines." The scope is changed (S:C) relative to the vulnerable component: the flaw lives in the run/job authorization state machine, but the consequence is execution on separate runner hosts.

Confidentiality, integrity, and availability impacts are rated High in the vector above on the assumption that CI environments in the affected deployment expose credentials and deployment capability to workflow jobs, which is the common configuration. If a given repository runs workflows with minimal permissions on isolated, credential-free runners, the realized impact is correspondingly lower. The attack is network-reachable (AV:N) and requires only low privilege (PR:L) — the combination of a fork contributor account and an Actions write account; at minimum a single attacker with Actions write access can orchestrate both roles. No user interaction beyond the attacker's own actions is required (UI:N), and no special conditions beyond Actions being enabled and a matching runner existing are needed (AC:L).

The blast radius is scoped per Gitea instance and per repository. An attacker with Actions write access on one repository gains code execution on that repository's runners; where runners are shared across repositories or organizations, the blast radius expands to every project that schedules work onto the same runner pool. The vulnerability does not appear to provide a direct path to Gitea server compromise, but runner compromise is frequently a stepping stone to exactly that.

Detection Guidance

Detection for this CVE centers on the anomalous administrative sequence it requires: a cancel followed by a re-run of a workflow run that was awaiting first-time-contributor approval, followed by job execution attributed to fork head code. There is no single high-fidelity network signature, so the detections below emphasize audit-log correlation and runner-side monitoring.

Sigma Rule

title: Gitea Actions Approval Bypass via Cancel and Re-run of Pending Fork Run
id: 6c1f9a2e-4b7d-4e8a-9f3c-2d1a5b8e7c40
status: experimental
description: Detects a workflow run being cancelled and then re-run while it was awaiting first-time fork contributor approval, followed by job creation, consistent with CVE-2026-104632.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-104632
author: valtersit.com
date: 2026/01/01
tags:
  - attack.t1195
logsource:
  product: gitea
  service: actions
detection:
  selection_cancel:
    action:
      - 'workflow_run.cancel'
      - 'workflow_run.cancelled'
    run_approval_required: true
  selection_rerun:
    action:
      - 'workflow_run.rerun'
      - 'workflow_run.rerun_requested'
    run_approval_required: true
  selection_jobs:
    action:
      - 'workflow_job.created'
      - 'workflow_job.queued'
    job_conclusion: null
  timeframe: 15m
  condition: selection_cancel and selection_rerun and selection_jobs
falsepositives:
  - Maintainers re-running genuinely approved workflows after cancellation
level: high

YARA Rule

rule Gitea_Actions_ForkPR_Unauthorized_Workflow
{
    meta:
        description = "Detects Gitea Actions workflow run records indicating a re-run of a pending-approval first-time fork contributor run (CVE-2026-104632)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-104632"
        date = "2026-01-01"
        severity = "high"
    strings:
        $a = "workflow_run"
        $b = "approval" nocase
        $c = "rerun" nocase
        $d = "pending" nocase
        $e = "waiting" nocase
        $f = "blocked" nocase
        $g = "pull_request" nocase
        $h = "fork" nocase
    condition:
        filesize < 5MB and
        $a and ($b or $d or $f) and ($c) and ($e or $f) and ($g or $h)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-104632 Gitea Actions Cancel and Re-run of Pending Fork Run Approval Bypass Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/actions/runs/"; pcre:"/\/actions\/runs\/\d+\/(cancel|rerun)/Ui"; threshold:type both, track by_src, count 2, seconds 60; classtype:attempted-admin; sid:2026104632; rev:1; metadata:created_at 2026_01_01, cve CVE-2026-104632, vendor Gitea;)

Elastic Detection

sequence by user.name, source.ip with maxspan=15m
  [any where event.action in ("workflow_run.cancel","workflow_run.cancelled")]
  [any where event.action in ("workflow_run.rerun","workflow_run.rerun_requested")]
  [any where event.action in ("workflow_job.created","workflow_job.queued")]

Splunk SPL Query

index=gitea sourcetype="gitea:actions"
| transaction run_id maxspan=15m startswith=action="workflow_run.cancel" endswith=action="workflow_job.created"
| where mvcount(approval_required)>0 AND approval_required="true"
| stats count min(_time) as first_seen max(_time) as last_seen values(action) as actions by run_id user repo
| where count > 0
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="gitea,actions,cve-2026-104632,">
  <rule id="104632" level="12">
    <decoded_as>json</decoded_as>
    <field name="action">workflow_run\.(rerun|rerun_requested)</field>
    <field name="approval_required">true</field>
    <description>CVE-2026-104632: Gitea Actions re-run of a workflow run still requiring first-time fork contributor approval - possible approval bypass.</description>
    <mitre>
      <id>T1195</id>
    </mitre>
    <group>cve_2026_104632,authorization_bypass,</group>
  </rule>
  <rule id="104633" level="10">
    <if_sid>104632</if_sid>
    <field name="action">workflow_job\.(created|queued)</field>
    <description>CVE-2026-104632: jobs created after an unapproved forked run was re-run - verify fork PR approval state.</description>
    <group>cve_2026_104632,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix version or workaround has been published in the tracked data for CVE-2026-104632. The measures below are defense-in-depth controls, not a substitute for a vendor patch.

1. Immediate mitigations

• Restrict Gitea Actions write access to the smallest possible set of trusted maintainers, and audit existing membership for accounts that do not require it. The flaw is reachable only by a user with Actions write access; tightening that group directly reduces exposure.
• Where the first-time-contributor approval requirement is not operationally essential, consider disabling workflow execution for fork pull requests entirely until a fix is available.
• Instruct maintainers not to use "cancel then re-run" on workflow runs that are awaiting first-time fork contributor approval. Treat any such run as blocked and require a fresh approval decision instead.
• Isolate self-hosted runners from sensitive networks and credentials. Run fork-triggered or untrusted workflows on dedicated, ephemeral, credential-free runner pools with restrictive egress.
• Rotate CI secrets and repository tokens if there is any indication the bypass was exercised, since workflow code from the fork head would have had access to whatever those jobs expose.

2. Patch / upgrade steps

• Monitor the Gitea security advisories and release notes for a version that corrects the re-run path to re-evaluate pending approval before constructing jobs. No patched version is identified in the provided data.
• Once a fix is published, upgrade all Gitea instances that have Actions enabled, prioritizing public instances accepting external contributions.
• After upgrading, re-test the exact sequence — open a fork PR from a first-time contributor, cancel the awaiting-approval run, then re-run it — and confirm the jobs remain blocked.

3. Long-term hardening

• Enforce least privilege across CI: scope workflow token permissions per job, avoid long-lived credentials on runners, and use short-lived, tightly scoped federated identities where supported.
• Segment runner infrastructure by trust level so that no runner that can execute fork-sourced code shares network reachability or credentials with production deployment systems.
• Add continuous monitoring for the cancel-then-rerun pattern on approval-gated runs (see Detection Guidance) and alert on job creation that follows it.
• Adopt a policy of periodic review of Actions write access and runner registrations, and maintain an inventory of which runners are eligible to run first-time fork contributor workflows.

References

• NVD — CVE-2026-104632: https://nvd.nist.gov/vuln/detail/CVE-2026-104632
• Gitea project repository and release/advisory channel: https://github.com/go-gitea/gitea
• Gitea Actions documentation (fork pull request approval behavior and runner registration): https://docs.gitea.com
• CWE-863 — Incorrect Authorization: https://cwe.mitre.org/data/definitions/863.html
• MITRE ATT&CK T1195 — Supply Chain Compromise: https://attack.mitre.org/techniques/T1195/

No public PoC, exploit code, or Nuclei template is known for this CVE. CISA KEV status: NO — no evidence of exploitation in the wild and no known threat actor campaigns are associated with this vulnerability in the available data.