External risk intelligence

Gitea Actions Fork Pull Request Workflow Hijacking

CVE advisorySeverity: CRITICAL (CVSS 9.8)

CVE-2026-94205

Gitea is commonly deployed as a self-hosted, internet-facing code hosting and CI/CD platform. Because Gitea Actions are often enabled in these public-facing instances to automate workflows, the attack surface involving workflow execution and pull request handling is frequently exposed to the internet in real-world deployments.

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory concerns a vulnerability in Gitea Actions where workflow code from a fork could execute on the base repository's runners without explicit approval. This could allow unauthorized code execution under certain conditions when pull requests are processed. The main concern is confirming relevance and exposure to your Gitea deployments.

Code from forks can run automatically.
Allows untrusted code to execute without approval.
Confirm if Gitea Actions are enabled and used.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this by manipulating how Gitea Actions process pull requests from forks. Normally, workflows triggered by forks require approval to prevent malicious code execution. However, this vulnerability allows a workflow from a forked repository to run on the main repository's infrastructure without approval if a maintainer interacts with the pull request in a specific way, potentially leading to the execution of arbitrary code.

Network access required.
Maintainer interaction with pull request.
Arbitrary code execution on runners.

Live Threat

Current exploitation, exposure, and threat context

When Gitea Actions are enabled and configured with runners, this vulnerability could allow unauthorized workflow code from a forked pull request to execute on the base repository's runners. This could occur if a maintainer triggers an action, bypassing normal approval checks, and the workflow definition is still sourced from the fork.

Repository runners and workflow code execution.
Forked pull request actions bypass approvals.
Unauthorized code execution on runners.

Operational Fix

Recommended remediation, mitigation, and detection steps

In real-world deployments, Gitea instances, especially those used for CI/CD and exposed to the internet, are likely managed by platform or infrastructure teams in coordination with security and vendor management. The immediate first step should be to identify all Gitea instances, determine if Actions is enabled and externally reachable, and confirm ownership before planning remediation.

Platform or infrastructure teams should own.
Verify Gitea Actions configuration and reachability.
Plan remediation based on exposure and risk.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Gitea Actions and how does it relate to this software?

Gitea is an open-source, self-hosted platform used for Git repository management. Gitea Actions is an integrated CI/CD component within this platform that automates software building, testing, and deployment processes using runners—servers that execute defined workflow tasks triggered by repository events.

What does CVE-2026-94205 mean in simple terms?

This vulnerability involves an authorization bypass, categorized under CWE-863 and CWE-441. It means the software fails to correctly enforce approval requirements for CI/CD workflows. Specifically, it mistakenly trusts fork-based code if a maintainer interacts with a pull request, allowing unauthorized code to execute on your infrastructure.

How is this Gitea Actions vulnerability triggered?

An attacker needs to submit a pull request from a forked repository containing a workflow. The bug is triggered when a maintainer performs a standard action on that pull request, such as adding a label. This action inadvertently causes the runner to execute the fork's workflow without the mandatory approval check. Simple pull request submissions without such maintainer interaction do not trigger this specific bypass.

Who should be concerned about this CVE?

According to Halo Surface Signal, anyone managing self-hosted Gitea instances should care, especially if those instances are internet-facing. Because Gitea is frequently deployed publicly to facilitate collaborative development and automated workflows, the attack surface for this vulnerability is often accessible to unauthorized parties over the network.

What steps should I take if I run Gitea?

First, verify if Gitea Actions is enabled and if your instance is reachable over the internet. Work with your platform or infrastructure teams to identify all active instances and their configuration status. Once identified, prioritize these systems for remediation based on their exposure to external users and their role in your CI/CD pipeline.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.