CVE-2026-114066 in Trigger.dev
Summary
by MITRE • 10/22/2026
Trigger.dev before 4.7.0 contains a missing authorization vulnerability that allows holders of unrestricted environment API keys to block runs they do not own by supplying a foreign parentRunId to batch-creation endpoints. Attackers can send requests to POST /api/v3/batches or POST /api/v2/tasks/batch with resumeParentOnCompletion to suspend, indefinitely block, or inject errors into production or cross-organization runs.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Trigger.dev versions prior to 4.7.0 represents a critical failure in access control mechanisms within the application's batch processing API endpoints. This flaw stems from an insufficient authorization check that fails to validate whether the authenticated user possesses legitimate ownership or administrative rights over the specific workflow execution context they are attempting to manipulate. Specifically, when users interact with the POST /api/v3/batches and POST /api/v2/tasks/batch endpoints using the resumeParentOnCompletion parameter, the system does not adequately verify if the parentRunId provided in the request belongs to a run owned by or accessible to the requesting entity. This architectural oversight allows any user possessing an unrestricted environment API key to target runs that are completely foreign to their organization or personal workspace, thereby bypassing standard isolation boundaries designed to protect multi-tenant environments and sensitive production workflows.
From a technical perspective, this vulnerability is classified under CWE-284 Improper Access Control, as the application fails to enforce proper restrictions on authorized individuals accessing specific resources. The exploitation vector involves an attacker crafting HTTP POST requests that include a valid but unauthorized parentRunId along with the resumeParentOnCompletion flag set to true or configured in a manner intended to alter the state of the target run. By doing so, the attacker can effectively hijack the execution flow of another user's job. This capability is particularly dangerous because it allows for denial-of-service conditions where legitimate runs are suspended indefinitely, preventing business-critical processes from completing their tasks. Furthermore, attackers may inject erroneous states or data into these foreign runs, potentially leading to data corruption or inconsistent application states that require manual intervention to resolve.
The operational impact of this vulnerability is severe, particularly in environments where Trigger.dev is used for mission-critical automation and background job processing. An attacker with access to an unrestricted API key can disrupt production workloads belonging to other tenants or internal teams within the same organization. This disruption manifests as halted executions, delayed data synchronization, and failed integrations that rely on these workflows. In a multi-tenant SaaS context, this breach of isolation undermines trust in the platform's security model, potentially leading to significant financial losses due to downtime and reputational damage. Additionally, if the affected runs involve sensitive operations such as database updates or external API calls, the injection of errors could cause cascading failures across integrated systems, amplifying the scope of the incident beyond simple service interruption.
To mitigate this risk, organizations must immediately upgrade Trigger.dev to version 4.7.0 or later, where the authorization logic has been corrected to strictly validate ownership of the parentRunId against the credentials presented in the API request. Until an upgrade is feasible, administrators should implement strict network-level controls such as IP whitelisting for API endpoints and rotate any unrestricted environment API keys that are not absolutely necessary for operational continuity. It is also advisable to audit existing logs for anomalous batch creation requests containing parentRunIds that do not correspond to the requesting user's known run history. Long-term remediation should involve adopting a principle of least privilege by replacing unrestricted keys with scoped tokens that limit access to specific resources and enforcing rigorous input validation on all API parameters related to resource identification. This incident highlights the importance of robust server-side authorization checks in multi-tenant applications, aligning with ATT&CK techniques related to Resource Hijacking and Denial of Service via application layer exploitation.