CVE-2026-118386 in Gitea
Summary
by MITRE • 11/01/2026
Workflows triggered by a pull request review were read from the commit named in the review's `commit_id`, while the fork restrictions were decided by the reviewed pull request, and the commit was not checked to belong to that pull request. A user with read access to a repository could place a commit of their own in it, through a fork pull request or an AGit push, and submit a review naming that commit on a pull request whose head branch is in the same repository. On instances with a runner serving the repository, the attacker's workflow then ran without approval, received the Actions secrets of the repository and its owner, and got a `GITEA_TOKEN` with write access to the repository. Review-triggered workflows now run on the pull request head.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/01/2026
This vulnerability represents a critical logic flaw in GitHub Actions that allows for unauthorized code execution within a target repository through manipulation of workflow triggers associated with pull requests. The core issue stems from an inconsistency between how the system identifies which commit should trigger a workflow and how it validates access controls based on fork restrictions. Specifically, when a review is submitted to initiate or modify a workflow run, the system extracts the `commit_id` directly from the review payload rather than verifying that this specific commit corresponds to the head of the pull request being reviewed. This decoupling creates a window for attackers to inject arbitrary code into the execution context by associating their own commits with legitimate pull requests.
An attacker possessing read access to a repository can exploit this flaw through several vectors, such as submitting a review via an API call or manipulating fork-based workflows. By pushing a malicious commit to any branch within the target repository and then submitting a review on a separate pull request that references that specific commit ID, the attacker tricks the system into executing their code under the guise of the legitimate workflow trigger. Because the validation logic fails to confirm that the `commit_id` belongs to the head of the reviewed pull request, the platform proceeds with execution without requiring standard approval processes or verifying branch protection rules. This effectively bypasses security controls designed to prevent untrusted code from running in privileged contexts.
The operational impact of this vulnerability is severe due to the elevated privileges granted to workflow runs triggered by reviews. When such a malicious workflow executes, it receives full access to Actions secrets scoped to both the repository and its owner organization. Furthermore, the runner environment is provisioned with a `GITEA_TOKEN` or equivalent GitHub token that possesses write permissions for the target repository. This allows an attacker not only to exfiltrate sensitive credentials but also to modify source code, create new branches, or deploy malicious artifacts directly into the protected project. The ability to execute arbitrary commands in this context can lead to complete compromise of the CI/CD pipeline and potential lateral movement within the organization's infrastructure if secrets are reused across services.
This flaw aligns with CWE-20 Improper Input Validation as the system fails to adequately validate that the input commit identifier matches the expected state of the pull request head. In terms of attack taxonomy, it maps to MITRE ATT&CK technique T1652 Misuse of Cloud Infrastructure which involves abusing cloud-native features for unauthorized access or execution. It also relates to T1078 Valid Accounts as the attacker leverages legitimate read-only permissions to escalate privileges through logic abuse rather than credential theft. The vulnerability highlights a broader class of issues in continuous integration systems where trust boundaries between different entities, such as forks and main repositories, are not strictly enforced during workflow initialization.
To mitigate this risk, platform administrators must ensure that workflows triggered by pull request reviews execute exclusively on the head commit of the associated pull request rather than any arbitrary commit referenced in review metadata. This requires strict validation logic to verify ownership of the `commit_id` against the pull request's source branch before granting execution privileges. Additionally, organizations should enforce branch protection rules that require manual approval for workflows originating from forks or external contributors. Limiting the scope of secrets available to untrusted runners and implementing least-privilege principles for workflow tokens can further reduce the blast radius if such an exploit is attempted. Regular auditing of workflow configurations and monitoring for anomalous execution patterns are also recommended defensive measures.