CVE-2026-94205

Executive Summary

CVE-2026-94205 is an authorization-logic flaw in Gitea Actions affecting how fork pull-request workflow runs are approved. Gitea evaluated whether a fork pull-request run required approval based on the user who triggered the event rather than the author of the pull request, allowing a maintainer's routine triage action (for example, adding a label) to spawn a workflow run that draws its workflow definition from the untrusted fork head without an explicit approval step. On instances where Actions is enabled and a matching runner is registered, this permits fork-controlled workflow code to execute on the base repository's runners, effectively granting untrusted contributors a path to code execution within the project's CI/CD trust boundary.

Technical Analysis

The vulnerability is a trust-boundary confusion (CWE-441, Unintended Proxy or Intermediary / confused deputy class) in the Gitea Actions approval gate. The core mechanism described is a misattribution of identity: the approval decision considers the actor who triggered a pull_request event, not the origin of the workflow code that will execute.

In a standard hardened fork-PR model, workflow runs sourced from a fork must be gated behind explicit approval, because the workflow file (and any referenced shell steps or container images) is attacker-controlled. Gitea Actions deviated from that model in the following way:

1. A pull_request activity event occurs. The NVD description explicitly names the "adding a label" action as an example of an ordinary maintainer triage operation.
2. Because the triggering user is a maintainer, Gitea's logic concluded the run did not require approval.
3. However, the workflow definition itself is "still taken from the fork head" — meaning the YAML and any embedded commands originate from the untrusted fork branch, not the base repository.
4. The result is that a run is created and dispatched without the explicit approval that should be required for fork-sourced code.

This is a classic confused-deputy outcome: the maintainer's elevated trust is transferred to code they did not author and did not intend to vouch for. The attacker (the fork author/PR author) does not need to compromise the maintainer account; they only need a maintainer to perform a routine, low-suspicion action such as labeling the PR. The workflow then executes on "the base repository's runners" — infrastructure that typically holds the base repo's secrets, tokens, and network position.

Two preconditions are stated explicitly in the description and bound the attack surface: (a) Gitea Actions must be enabled, and (b) a matching runner must be registered. Absent either condition, the fork-controlled workflow code has no execution target. Where both hold, no further misconfiguration is strictly required — the approval bypass is inherent to the logic flaw.

Note on technical specificity: the NVD description does not disclose function names, file paths, API parameters, or the exact version range. No public PoC or Nuclei template exists per the provided data. The analysis above stays at the vulnerability-class and mechanism level and draws only on terms appearing in the description ("fork pull request," "pull_request activity," "fork head," "base repository's runners").

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred strictly from the vulnerability class and the mechanism described in the NVD entry.

1. Reconnaissance / target identification. The attacker identifies a Gitea instance running Actions with at least one registered runner capable of servicing fork pull requests. This is discernible from public repositories, open PR workflows, or the presence of CI status checks on fork PRs.

2. Triggering the misattribution. The attacker forks a target repository and opens a pull request containing a workflow definition (or a modification to an existing workflow) under the fork head. Because the workflow content is taken from the fork head, the attacker fully controls the commands that will execute.

3. Inducing the maintainer action. The attacker relies on a routine maintainer triage event — per the description, adding a label to the PR is the explicitly cited path. When a maintainer performs this pull_request activity, Gitea creates the run without requiring approval, because the decision keys off the maintainer (the trigger) rather than the fork author. The attacker does not need to social-engineer the maintainer into running anything explicitly; standard triage suffices.

4. Execution at the vulnerability-class level. The fork-supplied workflow instructions are dispatched to a matching runner on the base repository's infrastructure, executing in the base repo's CI context.

5. Post-exploitation impact. Code executing on the base repository's runners can typically access the repository's CI secrets and tokens, environment variables, and the runner's network position — enabling repository tampering, credential theft, or lateral movement. The precise secrets reachable depend on the project's CI configuration, which the advisory does not enumerate.

The essential exploitation primitive is: fork-controlled code → base-repo runner execution → no explicit approval, gated only by Actions being enabled, a matching runner existing, and a maintainer performing an ordinary triage action.

Impact Assessment

• Authorization bypass / trust-boundary violation. The intended approval control for fork PR workflows is defeated, allowing untrusted fork code to run on base repository infrastructure. This is the primary impact and is consistent with CWE-441.
• CI/CD supply-chain risk. Because runners on the base repository often hold deployment credentials, package-publish tokens, and cloud secrets, successful execution can translate into supply-chain compromise of downstream consumers.
• Blast radius. Limited to Gitea deployments with Actions enabled and a matching registered runner. Repositories without fork PR workflows, or instances without Actions, are not exposed by this logic flaw.
• CVSS. No CVSS score or vector was assigned in the provided data; this report does not fabricate one. Qualitatively, the described mechanism implies a confidentiality-and-integrity impact on CI infrastructure contingent on the two stated preconditions.
• Exploitability. No public PoC, no Nuclei template, and no exploit code are known per the data. CISA KEV: not listed. EPSS: not yet scored by FIRST.org (no value fabricated).
• Severity caveat. Because approval-bypass depends partly on maintainer interaction (the triage event) and the availability of a matching runner, real-world exploitability is environment-dependent rather than universal.

Detection Guidance

Detection should focus on the anomaly the flaw produces: workflow runs originating from fork heads on base-repo runners that were created without an approval record, and on CI behavior deviating from the repository's normal workflow source.

Sigma Rule

title: Gitea Actions Fork PR Workflow Run Without Approval
id: 8f3c1a2e-5b7d-4c9a-9e21-7d0a6f4b2c11
status: experimental
description: Detects Gitea Actions runs whose workflow definition originates from a fork head but which were created without an explicit approval, indicative of CVE-2026-94205 style approval bypass.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-94205
author: valtersit.com
logsource:
  product: gitea
  service: actions
detection:
  selection_event:
    event.type: 'workflow_run'
  selection_fork:
    workflow.source: 'fork'
  selection_no_approval:
    run.approved: false
  condition: selection_event and selection_fork and selection_no_approval
falsepositives:
  - Repositories that intentionally auto-approve fork workflows (rare, should be documented)
level: high

YARA Rule

rule CVE_2026_94205_Gitea_Actions_Fork_Workflow
{
    meta:
        description = "Flags Gitea Actions workflow files indicating fork-sourced workflow execution context (approval-bypass related)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-94205"
        date = "2026-01-01"
    strings:
        $a = "pull_request"
        $b = "fork"
        $c = "runs-on"
    condition:
        (uint16(0) == 0x233F) and all of them
}

Note: because the advisory discloses no file paths or code artifacts, this rule targets the generic workflow-file markers named in the description (pull_request, fork context, runs-on) and should be tuned per environment.

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-94205 Gitea Actions fork PR workflow run without approval"; flow:established,to_server; http.method; content:"PUT"; http.uri; content:"/actions"; content:"fork"; http.uri; nocase; content:"workflow"; http.uri; nocase; sid:9009420501; rev:1;)

Tune http.uri content to the instance's actual Actions API paths; the advisory does not name endpoints, so this targets the Actions+fork+workflow request pattern and requires local validation.

Elastic Detection

sequence by host.id
  [ process where event.action == "start" and process.name : ("runner", "act_runner") ]
  [ file where file.name : "*.yml" and file.path : "*workflows*" ]

The EQL above targets runner process activity followed by workflow file access on CI hosts. Adjust field names to your agent's schema.

Splunk SPL Query

index=gitea sourcetype=gitea:actions
| search action="workflow_run" fork=true approved=false
| stats count values(repo) as repos values(actor) as actors by user, workflow
| where count > 0

Wazuh OSSEC Rule

<group name="gitea,actions,">
  <rule id="100942" level="12">
    <decoded_as>json</decoded_as>
    <field name="event.type">workflow_run</field>
    <field name="workflow.source">fork</field>
    <field name="run.approved">false</field>
    <description>CVE-2026-94205: Gitea Actions fork-PR workflow run created without approval</description>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence from any tracked source; no vendor fix, workaround, or affected version range was provided in the data. The following are defensive recommendations, not confirmed vendor guidance.

1) Immediate mitigations (no patch available):

• Restrict Gitea Actions so that fork-sourced workflow runs require explicit approval regardless of who triggers them. If the running version offers a "require approval for all outside contributors" setting, enable it and verify fork-head workflows are covered.
• Disable Actions on repositories where fork PR workflows are not operationally necessary; removing the execution target eliminates the flaw's precondition.
• Configure runners so that fork-PR jobs do not receive base-repository secrets or privileged tokens, and block runner network access to internal systems.
• Enforce manual review: treat any workflow definition originating from a fork as untrusted; avoid blanket "first-time contributor" auto-approval superseded by trigger-user logic.

2) Patch / upgrade steps:

• No patch is available per tracked sources. Monitor the Gitea security advisories and release notes for a fix specifically addressing approval logic for fork pull-request runs (the decision should key off the PR author/fork origin, not the triggering user). Because no affected/fixed version range is provided, confirm the version referenced by any forthcoming Gitea advisory before upgrading.
• When a fix is released, upgrade and then re-verify that maintainer-triggered pull_request activities no longer bypass approval for fork-head workflows.

3) Long-term hardening:

• Adopt a policy that workflow approval is bound to the origin of the workflow code, not the actor who triggered the event — audit any CI system making actor-based approval decisions.
• Apply least privilege to runner identity: scoped, short-lived credentials; no broad organization tokens.
• Monitor fork-PR workflow execution and maintain alerting (see Detection Guidance).
• Periodically test fork-PR approval enforcement with a controlled fork workflow to detect regressions.

References

• NVD — CVE-2026-94205: https://nvd.nist.gov/vuln/detail/CVE-2026-94205
• Gitea Security Advisories: https://github.com/go-gitea/gitea/security/advisories
• CWE-441 — Unintended Proxy or Intermediary ('Confused Deputy'): https://cwe.mitre.org/data/definitions/441.html
• Gitea Actions documentation (approval and runner configuration): https://docs.gitea.com/usage/actions/overview
• CISA Known Exploited Vulnerabilities Catalog (status: NOT listed — verify current status): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No known threat actor campaigns or in-the-wild exploitation evidence were provided for this CVE. No public PoC, exploit code, or Nuclei template is known per the data.