Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-13T20:17:30.297Z",
  "pubdate": "2026-08-13T20:17:30.297Z",
  "executiveSummary": "An authorization bypass vulnerability exists in Trigger.dev prior to version 4.5.6 within the deployment background worker creation mechanism. The flaw permits authenticated users with access to a valid API key for one project to interact with deployment identifiers belonging to entirely different projects.\nThe vulnerability allows an attacker to link an attacker-controlled background worker to a victim deployment and forcefully transition the deployment state from BUILDING to DEPLOYING.\nThis impacts system integrity and deployment workflows across affected Trigger.dev installations. Exploitation requires valid API credentials for at least one project and knowledge or enumeration of a victim deployment friendlyId.\nThe risk is mitigated by updating Trigger.dev to version 4.5.6, which introduces proper environment isolation and tenancy checks.",
  "technicalDetails": "The vulnerability resides in the HTTP endpoint POST /api/v1/deployments/:deploymentId/background-workers, which invokes the CreateDeploymentBackgroundWorkerServiceV4.call() method located in apps/webapp/app/v3/services/createDeploymentBackgroundWorkerV4.server.ts.\nThe root cause of the vulnerability is an insufficient access control check within the database query logic. Specifically, the underlying implementation executes workerDeployment.findFirst() to retrieve a deployment record using solely the deployment identifier (friendlyId) supplied in the request route, omitting any predicate or filter for the associated environmentId or projectId.\nAuthentication is required in the form of a valid API key, but the lack of proper authorization checks permits a multi-tenant isolation failure (Insecure Direct Object Reference). An attacker possessing a valid API key for Project A can target the deployment identifier of Project B.\nThe attack flow proceeds as follows: First, the attacker obtains or possesses a valid API key for their own authorized project. Second, the attacker discovers or guesses a target deployment's friendlyId belonging to a victim project. Third, the attacker issues a crafted POST request to POST /api/v1/deployments/:deploymentId/background-workers targeting the victim deployment ID, supplying parameters to register an attacker-owned background worker.\nUpon processing, the vulnerable service successfully binds the malicious background worker to the victim deployment record without validating whether the caller's API key has authorization over the target deployment's environment. Furthermore, the service updates the state machine of the victim deployment, transitioning it from BUILDING to DEPLOYING.\nThis unauthorized state transition and worker linkage can disrupt legitimate build and deployment pipelines, potentially injecting untrusted execution components into victim workflows.\nThe vulnerability affects all Trigger.dev versions prior to 4.5.6 and is resolved natively in version 4.5.6."
}