CVE-2026-119289 in Zuke
Summary
by MITRE • 10/30/2026
Zuke is a code-first, strongly typed build automation system for Deno. Prior to 1.10.0, the @zuke/gh githubWorkflow(...) gate correlates a dispatched workflow run using only a display-title marker that is visible in the workflow run list and can be copied by another dispatcher. In configurations where the external workflow repository grants workflow_dispatch permission to a party not equally trusted by the releasing repository, an attacker can dispatch a run with the marker and cause the gate to adopt its conclusion without verifying the event, ref, or creation window. A passing substituted run can authorize an unvalidated release, while a failed or cancelled run can block a valid release, and the persisted adopted run ID preserves the substitution across build resume. This issue is fixed in version 1.10.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Zuke versions prior to 1.10.0 represents a critical flaw in the authentication and authorization logic governing GitHub Actions workflow dispatches within its code-first, strongly typed build automation framework. As a system designed for Deno, Zuke relies on external integrations such as GitHub Workflows to manage complex CI/CD pipelines. The specific defect resides in the @zuke/gh githubWorkflow gate mechanism, which is responsible for validating that an upstream workflow has completed successfully before allowing subsequent steps, such as releasing software artifacts, to proceed. This validation process was fundamentally compromised because it relied exclusively on a display-title marker string rather than verifying immutable identifiers or cryptographic proofs associated with the specific workflow run instance.
In a secure implementation, any gate checking the status of an external event must verify unique attributes that cannot be easily spoofed by unauthorized parties. These typically include the run ID, which is a unique numeric identifier assigned by GitHub to each execution, along with checks on the repository origin, branch reference, and timestamp constraints. However, in this vulnerable configuration, the gate accepted any workflow dispatch where the display title matched a predefined marker string visible in the GitHub Actions UI. This design choice ignored critical contextual data such as whether the run originated from the expected repository, if it was triggered by the correct commit ref, or if it occurred within an acceptable time window relative to the current build state.
The operational impact of this flaw is severe and bidirectional, affecting both confidentiality and availability through authorization bypass and denial-of-service vectors respectively. An attacker with write access to a less-trusted external workflow repository can exploit this by dispatching a new workflow run that includes the expected display-title marker in its title field. Because Zuke does not verify the event source or uniqueness of the run, it incorrectly adopts the conclusion of this substituted run as if it were the legitimate one initiated by the trusted party. If the attacker triggers and allows their malicious run to pass, they can authorize an unvalidated release, potentially pushing compromised code artifacts to production environments without proper review or testing.
Conversely, the vulnerability also enables a denial-of-service attack against the build pipeline itself. By dispatching a workflow with the correct marker but ensuring it fails or is manually cancelled by the attacker, the gate will adopt this negative conclusion. This causes Zuke to block valid releases that are otherwise ready for deployment, effectively halting development and release cycles until the issue is resolved or workarounds are implemented. Furthermore, because the adopted run ID persists across build resume operations, once a malicious state is established, it remains locked in place even if the pipeline is restarted, requiring manual intervention to clear the incorrect validation state.
This vulnerability aligns with CWE-287, which describes Improper Authentication, as the system failed to properly verify the identity of the workflow run before trusting its status. It also relates to CWE-345, Insufficient Verification of Data Authenticity, since the gate accepted data based on a superficial string match rather than verifying the integrity and origin of the event metadata. From an ATT&CK perspective, this flaw facilitates lateral movement within CI/CD pipelines by allowing unauthorized actors to manipulate build outcomes, potentially leading to CWE-829, Inclusion of Functionality from Untrusted Control Sphere, where unverified external inputs dictate critical security decisions in the release process.
To mitigate this vulnerability and prevent similar issues in future versions, it is imperative that automation systems strictly validate workflow runs using immutable identifiers such as GitHub Actions run IDs rather than mutable display titles or names. Implementations should verify that the dispatched event originated from a trusted repository with appropriate permissions, check that the ref matches the expected branch or tag, and enforce strict time windows to prevent replay attacks where old valid runs might be reused in new contexts. Upgrading to Zuke version 1.10.0 resolves this issue by implementing these robust verification checks, ensuring that only authentic, verified workflow executions can influence release decisions. Organizations using earlier versions should immediately upgrade or implement manual validation steps as a temporary countermeasure until the patch is applied.