CVE-2026-114068 in Trigger.dev
Summary
by MITRE • 10/21/2026
Trigger.dev before 4.6.0 contains a missing authorization vulnerability in the waitpoint token wait endpoint that allows authenticated attackers to block runs belonging to other organizations. Attackers holding any secret API key can supply a victim run ID with their own waitpoint, causing that run to block indefinitely on a waitpoint the victim cannot complete, and can inject resume data into it.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Trigger.dev versions prior to 4.6.0 represents a critical failure in access control mechanisms within the platform's workflow orchestration engine. Specifically, the flaw resides in the endpoint responsible for handling waitpoint tokens, which are essential components of asynchronous task execution and state management. In this architecture, workflows often pause at specific points known as waitpoints until an external signal or token is provided to resume execution. The security defect allows any authenticated user possessing a valid secret API key to manipulate these waitpoints in ways that compromise the integrity and availability of other organizations' data and processes. This lack of proper authorization checks means that the system fails to verify whether the requesting entity has legitimate ownership or administrative rights over the specific workflow run being targeted, thereby enabling cross-tenant interference.
From a technical perspective, an attacker can exploit this vulnerability by supplying a victim's unique run ID along with their own waitpoint token during API interactions. Because the server does not adequately validate that the waitpoint belongs to the specified run or that the user has permission to interact with it, the system accepts the malicious input and associates the attacker-controlled waitpoint with the victim's workflow instance. This action effectively hijacks the execution state of the target run. The immediate operational impact is a denial of service condition for the affected organization, as the vulnerable run becomes blocked indefinitely on a waitpoint that only the attacker can resolve or manipulate. Furthermore, this capability extends beyond simple blocking; it allows for data injection attacks where an adversary can supply resume data to influence the outcome of the victim's workflow logic, potentially leading to unauthorized actions, data corruption, or further exploitation depending on how the downstream processes handle the injected payload.
This vulnerability aligns with CWE-269, which classifies Improper Privilege Escalation and specifically touches upon Broken Access Control principles where a user can access resources they are not authorized to touch. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior is consistent with techniques involving Resource Hijacking or Interception of Communication Flow, particularly within the context of cloud infrastructure and API-based services. The ability to block runs indefinitely constitutes an Availability impact, while the capacity to inject resume data poses a significant Integrity risk. For organizations utilizing Trigger.dev for critical business automation, this flaw undermines trust in multi-tenant isolation guarantees and exposes sensitive operational workflows to malicious interference by any authenticated account on the platform.
To mitigate this vulnerability, immediate action is required to upgrade all instances of Trigger.dev to version 4.6.0 or later, where these authorization checks have been implemented and validated. Until an upgrade can be performed, organizations should review their API key permissions and consider rotating keys if there is any suspicion of unauthorized access attempts. Additionally, implementing strict rate limiting and monitoring for anomalous patterns in waitpoint token submissions may help detect exploitation attempts in real-time. It is also advisable to audit workflow designs that rely on external signals for critical logic, ensuring that fallback mechanisms or timeout handlers are in place to prevent indefinite blocking even if an attacker manages to inject a malicious waitpoint. Regular security assessments and adherence to least-privilege principles when distributing API keys will further reduce the attack surface associated with such orchestration platforms.