Description

Gitea Actions decided whether a fork pull request run needed approval based on the user who triggered the event rather than the pull request author. For `pull_request` activity triggered by a maintainer during ordinary triage, such as adding a label, the run was created without requiring approval, while the workflow definition was still taken from the fork head. Where Actions is enabled and a matching runner is registered, fork-controlled workflow code could run on the base repository's runners without an explicit approval.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-10-06T20:17:34.733Z",
  "pubdate": "2026-10-06T20:17:34.733Z",
  "executiveSummary": "A critical authorization bypass vulnerability exists within Gitea Actions where pull request workflows triggered by fork contributors are improperly validated.\nThe vulnerability stems from the system utilizing the identity of the user triggering an event, such as a maintainer performing triage, instead of the pull request author, to determine approval requirements.\nThis flaw allows malicious actors to execute arbitrary workflow code defined within a fork directly on the base repository's runners without undergoing the mandatory security approval process.\nThe primary risk involves unauthorized code execution within the context of the base repository, potentially exposing secrets, modifying repository contents, or performing lateral movement within the CI/CD environment.\nExploitation requires the attacker to submit a malicious workflow via a fork and rely on a privileged user to interact with the pull request, thereby triggering the workflow execution.\nThis represents a failure in the trust boundary between untrusted fork contributions and the trusted infrastructure of the base repository.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper evaluation logic used by the Gitea Actions engine when determining whether a workflow run derived from a fork repository requires manual approval.\nIn the affected Gitea versions, the authorization check logic evaluates the identity of the actor who triggered the workflow event rather than the repository owner or pull request author who defined the workflow logic.\nBecause pull request-related events can be triggered by maintainers or repository administrators during routine triage (e.g., applying labels or comments), the system erroneously perceives the triggering event as originating from a trusted, authenticated user.\nWhen this occurs, the workflow runner fetches and executes the workflow definition file directly from the fork head branch without enforcing the security approval requirement intended for external contributions.\nThe attack flow follows a predictable sequence: First, an attacker creates a fork of the target repository and modifies a workflow file or introduces a malicious one. Second, the attacker submits a pull request to the base repository containing the compromised workflow configuration.\nThird, the attacker waits for a privileged user (such as a maintainer) to perform an action on the pull request that triggers a workflow event (e.g., adding a label).\nFinally, the Gitea Actions system evaluates the trigger event, incorrectly determines that the action was initiated by a trusted user, and proceeds to execute the malicious workflow on the base repository's infrastructure.\nSince the execution occurs on the base repository's runners, the malicious workflow may gain access to the repository's CI/CD secrets, environmental variables, and service tokens intended for legitimate builds.\nThis allows for post-exploitation activities including exfiltration of build-time secrets, unauthorized modifications to the codebase, or potential container escape scenarios if the runner environment is not sufficiently hardened.\nThe vulnerability is fundamentally a failure in the association between the workflow execution context and the origin of the workflow definition."
}