CVE-2026-73656 in Trigger.dev
Summary
by MITRE • 08/13/2026
Trigger.dev is a platform for building and deploying fully managed AI agents and workflows. Prior to 4.5.6, POST /api/v1/deployments/:deploymentId/background-workers calls CreateDeploymentBackgroundWorkerServiceV4.call() in apps/webapp/app/v3/services/createDeploymentBackgroundWorkerV4.server.ts, where workerDeployment.findFirst() selects a deployment by friendlyId without an environmentId predicate. A caller with a valid API key for one project can submit another project's deployment identifier, link an attacker-owned background worker to the victim deployment, and move the victim deployment from BUILDING to DEPLOYING. This issue is fixed in version 4.5.6.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/13/2026
This vulnerability exists within Trigger.dev platform version 4.5.5 and earlier, where a critical access control flaw allows unauthorized manipulation of deployment states through a specific API endpoint. The vulnerability stems from insufficient input validation and authorization checks during the background worker creation process for deployments. When a POST request is made to /api/v1/deployments/:deploymentId/background-workers, the system invokes CreateDeploymentBackgroundWorkerServiceV4.call() which executes workerDeployment.findFirst() without properly verifying that the deployment identifier corresponds to the authenticated user's project environment. This design flaw creates a path where an attacker with a valid API key for one project can exploit the system by submitting a deployment identifier from another project, effectively linking an attacker-controlled background worker to a victim deployment.
The technical implementation of this vulnerability involves a database query operation that lacks proper environmental context validation. The workerDeployment.findFirst() function performs a lookup based solely on friendlyId without incorporating environmentId as a filtering parameter, creating a direct path for cross-project resource manipulation. This type of flaw falls under CWE-284 Access Control Issues, specifically representing inadequate authorization checks where the system fails to verify that the requesting entity has legitimate access rights to manipulate the specified deployment resource. The vulnerability is particularly concerning because it allows an attacker to transition a victim deployment from BUILDING state to DEPLOYING state without proper authorization, effectively enabling unauthorized modification of deployment workflows.
The operational impact of this vulnerability extends beyond simple data manipulation as it enables attackers to disrupt legitimate deployment processes and potentially compromise system integrity. An attacker can leverage this flaw to inject malicious background workers into victim deployments, potentially leading to execution of unauthorized code or disruption of legitimate business processes. This issue directly impacts the platform's workflow management capabilities and could be exploited to cause service degradation or even enable more sophisticated attacks such as persistent backdoor installation through compromised deployment workflows. The vulnerability affects any organization using Trigger.dev platforms where multiple projects share the same API key space, creating a significant risk for multi-tenant deployments.
Mitigation strategies should focus on implementing proper authorization checks at the API endpoint level and ensuring that all database queries incorporate appropriate environmental context validation. Organizations should immediately upgrade to version 4.5.6 or later where this vulnerability has been addressed through enhanced input validation and environment-specific lookup constraints. Additionally, implementing comprehensive monitoring for unusual deployment state transitions and background worker associations can help detect exploitation attempts. The fix implemented in version 4.5.6 likely involves adding environmentId predicates to the database queries and enforcing stricter access control policies during deployment worker creation operations. This vulnerability demonstrates the critical importance of validating resource ownership context in multi-tenant systems and aligns with ATT&CK technique T1078 Valid Accounts, where attackers leverage legitimate credentials to perform unauthorized operations within system boundaries. Organizations should also consider implementing principle of least privilege access controls and regular security audits of API endpoint authorization logic to prevent similar issues from emerging in other components of their deployment pipelines.