CVE-2026-118535 in Gitea
Summary
by MITRE • 11/15/2026
A repository registered by its owner as a source of scoped workflows kept that registration when it was transferred to another owner. The new owner could then change the workflows in the transferred repository, and they kept running in the previous owner's repositories with access to their Actions secrets and job tokens. A transfer now removes the owner-level registrations of the repository, and registrations whose source repository no longer belongs to the registering owner are ignored.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/15/2026
This vulnerability pertains to a logic flaw within GitHub Actions workflow management systems involving scoped workflows during repository ownership transfers. Scoped workflows allow organizations or users to define reusable workflow templates that can be referenced by other repositories, providing centralized control over CI/CD pipelines and ensuring consistent security policies across multiple projects. The core technical flaw arises from the persistence of these registrations after a repository is transferred between owners without proper revocation or re-evaluation of access rights. When an owner registers a repository as a source for scoped workflows, GitHub associates that registration with specific organizational or user-level permissions. However, if the repository containing those workflow definitions is subsequently transferred to a different account, the system historically retained the original registration link rather than invalidating it based on the change in ownership context.
The operational impact of this flaw allows the new owner of the transferred repository to modify the underlying workflow files while maintaining their execution capability within the previous owner's repositories that reference them as scoped workflows. This creates a severe supply chain risk where malicious or compromised code introduced by the new owner can execute with elevated privileges in the original organization's environment. Specifically, these workflows retain access to sensitive Actions secrets and job tokens belonging to the previous owner. Consequently, an attacker who gains control of the transferred repository could exfiltrate credentials, inject backdoors into build processes, or perform unauthorized actions under the identity of the victim organization, effectively bypassing intended isolation boundaries between different entities within a GitHub ecosystem.
This issue aligns with CWE-20 Improper Input Validation and CWE-798 Use of Hard-coded Credentials in the context of dynamic permission inheritance, as well as MITRE ATT&CK technique T1654 False Flagging or Impersonation if used to mask malicious activity within legitimate CI/CD pipelines. The vulnerability exploits a gap in state management during administrative operations like repository transfer, where identity assertions are not properly reconciled with current ownership status. To mitigate this risk, GitHub implemented changes such that transferring a repository now automatically removes any owner-level registrations associated with it. Furthermore, the system logic was updated to ignore registrations whose source repositories no longer belong to the registering entity. Users and organizations should verify their scoped workflow configurations after any recent transfers and ensure that only trusted sources are registered for reusable workflows to prevent unauthorized code execution in critical CI/CD environments.