CVE-2026-73800 in Gitea
Summary
by MITRE • 10/14/2026
Gitea resolves local reusable workflow files from a fork's head commit when a trusted base-branch workflow runs for a pull_request_target event. A fork author can modify a referenced reusable workflow so attacker-controlled code executes with the repository and organization secrets available to that event. Exploitation requires a base workflow that calls a local reusable workflow, and bypasses the intended separation between trusted base code and untrusted fork code.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability described involves a critical flaw in how Gitea handles pull request workflows when utilizing reusable workflow files from forks. Specifically, when a trusted base-branch workflow is triggered by a pull_request_target event, it resolves local reusable workflow files not from the base branch but from the head commit of the fork. This behavior creates a significant security gap because the pull_request_target event inherently grants access to repository and organization secrets due to its execution in the context of the target repository rather than the source fork. The intended design separates trusted code running with elevated privileges from untrusted user-contributed code, but this flaw allows an attacker-controlled reusable workflow referenced by name or path within a local file structure to be executed under those privileged conditions.
Exploitation requires that the base workflow explicitly calls a local reusable workflow, which is then resolved dynamically based on the fork's current state rather than being locked to the version present in the target repository’s main branch. An attacker who maintains control over a fork can modify this referenced reusable workflow file at any time before or during the execution of the pull request. By injecting malicious code into this local file, the attacker ensures that when the base workflow invokes it, the injected commands run with full access to sensitive secrets such as API keys, deployment credentials, and internal configuration data. This effectively bypasses the security boundary designed to protect these resources from untrusted external contributions.
From a classification perspective, this issue aligns closely with CWE-94 Improper Control of Generation of Code (Code Injection) because it allows an attacker to inject arbitrary code into a trusted execution context through manipulated input files. Additionally, it relates to CWE-78 Improper Neutralization of Special Elements used in an OS Command if the injected workflow executes shell commands or system-level operations. In terms of the MITRE ATT&CK framework, this vulnerability facilitates techniques associated with Initial Access and Execution via CI/CD pipelines, specifically leveraging trusted relationships between repositories to escalate privileges and exfiltrate data without detection by standard access controls.
The operational impact is severe as it compromises the integrity of automated software delivery processes that rely on Gitea Actions. Organizations using reusable workflows for modularizing their CI/CD logic are particularly at risk if they do not strictly enforce branch protection rules or validate workflow sources. Attackers can achieve remote code execution within the runner environment, potentially leading to full compromise of build infrastructure, theft of intellectual property through secret exfiltration, and lateral movement into internal networks depending on how secrets are utilized in subsequent steps.
Mitigation strategies must focus on enforcing strict validation of reusable workflow origins. Developers should avoid referencing local files that can be modified by fork owners unless those references are explicitly pinned to specific commit SHAs or tags from the trusted base repository rather than dynamic branches like main or master. Implementing branch protection rules that require review and approval for changes to workflows is essential, but must be complemented by architectural changes in how reusable components are resolved. Upgrading Gitea to a version where this resolution logic has been corrected to always use the target repository’s state for local references is the primary remediation step. Additionally, auditing existing workflows for patterns that call external or fork-resolved resources can help identify and patch similar risks before exploitation occurs.