CVE-2026-114077 in Trigger.dev
Summary
by MITRE • 10/22/2026
Trigger.dev before 4.5.6 contains an authorization bypass vulnerability in createDeploymentBackgroundWorkerV4 that resolves a WorkerDeployment by friendlyId alone, without environment, project, or organization scoping. Attackers holding only their own environment API key can POST to the deployment background-workers endpoint with a victim's deployment ID to re-point that in-progress deployment at a worker in the attacker's environment.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Trigger.dev versions prior to 4.5.6 represents a critical authorization bypass within the createDeploymentBackgroundWorkerV4 API endpoint, fundamentally rooted in insufficient server-side access control mechanisms. The core technical flaw lies in the application logic used to resolve WorkerDeployments during background worker assignment processes. Specifically, the system relies exclusively on the friendlyId of a deployment as the unique identifier for scoping and validation purposes. This design choice fails to incorporate additional contextual identifiers such as environment IDs, project scopes, or organization-level attributes that are typically required to enforce strict multi-tenancy boundaries in cloud-native serverless platforms. By treating the friendlyId as a globally unique key without verifying its association with the authenticated user's specific tenant context, the application creates an open channel for unauthorized manipulation of deployment states across different organizational units.
From an operational perspective, this flaw allows attackers possessing only their own environment API keys to perform malicious actions against resources belonging to other tenants. An adversary can exploit this by issuing a POST request to the deployment background-workers endpoint and supplying the friendlyId of a victim's in-progress deployment. The server processes this request without validating whether the authenticated user has any legitimate relationship with the target deployment or its associated environment. Consequently, the attacker can successfully re-point an active deployment at a worker instance hosted within their own controlled environment. This action effectively hijacks the execution context of the victim's deployment, allowing the attacker to intercept, modify, or exfiltrate data processed during that specific workflow run.
The impact of this vulnerability is severe, as it compromises both confidentiality and integrity for affected organizations. Since Trigger.dev often handles sensitive business logic and data processing in serverless functions, hijacking a deployment allows an attacker to access proprietary code execution results, internal API responses, or database queries initiated by the victim's workflow. Furthermore, if the worker environment contains credentials or secrets, these could be exposed through logs or error messages generated during the manipulated execution. This scenario aligns with CWE-284 Improper Access Control and specifically reflects a failure in object-level authorization checks where resource identifiers are not properly bound to user session context. In terms of attack vectors, this behavior is consistent with ATT&CK technique T1078 Valid Accounts, as it leverages legitimate but insufficiently scoped credentials to escalate privileges or access unauthorized resources within the platform's multi-tenant architecture.
To mitigate this vulnerability, immediate updates to Trigger.dev version 4.5.6 or later are required, as these versions implement proper scoping logic that validates environment and project associations alongside deployment identifiers. For organizations unable to patch immediately due to dependency constraints, implementing a Web Application Firewall rule to monitor for anomalous POST requests to the background-workers endpoint may provide limited protection by detecting unusual patterns of cross-tenant ID usage. Additionally, developers should review their integration with Trigger.dev to ensure that no sensitive data is processed in unverified deployment contexts and consider rotating API keys if there is evidence of exploitation. Long-term architectural improvements should enforce strict multi-tenancy checks at the database query level, ensuring that all resource lookups include explicit filters for organization_id and environment_id rather than relying solely on user-provided friendly identifiers which may not be globally unique or securely scoped.