CVE-2026-114071 in Trigger.dev
Summary
by MITRE • 10/21/2026
Trigger.dev before 4.5.12 contains an authorization bypass vulnerability that allows authenticated project members to complete another member's DEVELOPMENT environment waitpoint by skipping the per-user environment ownership check. Attackers who know a victim's waitpoint friendly ID can submit type=DATETIME or type=MANUAL with isTimeout to prematurely mark the pending waitpoint completed.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Trigger.dev versions prior to 4.5.12 represents a critical authorization bypass flaw within the platform's workflow orchestration engine, specifically affecting the handling of waitpoints in development environments. In this context, developers utilize waitpoints to pause execution until specific conditions are met or external events occur, which is essential for integrating asynchronous processes with synchronous application logic. The core technical deficiency lies in the server-side validation logic that governs these waitpoint completions. While the system correctly enforces ownership checks during initial creation and general management of workflows, it fails to verify user identity when processing requests intended to resolve or complete a specific waitpoint instance. This oversight creates an insecure direct object reference scenario where the access control mechanism relies solely on the presence of valid authentication credentials rather than verifying that the authenticated user possesses administrative privileges over the specific resource being modified.
From a technical perspective, the flaw exploits the lack of per-user environment ownership verification during the completion operation. An attacker who has obtained legitimate authentication credentials for an account within a shared project can target waitpoints belonging to other team members by leveraging known identifiers. Specifically, if an adversary is aware of a victim's waitpoint friendly ID, they can craft API requests specifying parameters such as type=DATETIME or type=MANUAL with the isTimeout flag set to true. These parameters instruct the backend system to prematurely mark the pending waitpoint as completed without requiring actual external input or time expiration. Because the authorization middleware does not cross-reference the requesting user's identity against the owner of the development environment associated with that waitpoint, the request is processed successfully, effectively allowing one team member to unilaterally alter the state of another member's workflow execution context.
The operational impact of this vulnerability extends beyond simple data manipulation, potentially leading to significant integrity issues within CI/CD pipelines and automated business processes. By forcing a waitpoint to complete prematurely, an attacker can disrupt the intended synchronization points in application workflows. This may result in downstream tasks executing with incomplete or incorrect state information, causing logic errors, data corruption, or service failures that are difficult to trace back to their root cause due to the asynchronous nature of the operations. Furthermore, this capability undermines team collaboration by allowing unauthorized interference with ongoing development and testing activities, potentially masking bugs introduced by other developers or disrupting scheduled deployments. In environments where waitpoints are used for security-sensitive approvals or data validation steps, such bypasses could lead to compliance violations or exposure of sensitive information if subsequent stages proceed without proper verification.
To mitigate this risk, organizations must immediately upgrade Trigger.dev to version 4.5.12 or later, which addresses the authorization logic by enforcing strict ownership checks on all waitpoint completion endpoints. In addition to patching, developers should implement defense-in-depth strategies such as validating user permissions at every step of the workflow lifecycle and utilizing short-lived tokens with minimal scopes for API interactions where possible. Monitoring logs for unusual patterns in waitpoint resolution times or unexpected completions can also aid in detecting potential exploitation attempts before they cause significant damage. This incident highlights the importance of rigorous access control testing, particularly for functions that modify shared resources within multi-tenant environments, ensuring that authentication is always coupled with robust authorization checks aligned with industry standards such as CWE-284 Improper Access Control and MITRE ATT&CK techniques related to privilege escalation or unauthorized resource modification.