Trigger.dev Cross-Project Deployment Hijack via Missing Tenant Isolation Check
First seen Aug 14, 2026 · Updated Aug 14, 2026 · CVSS 9.9
Trigger.dev, a platform used to build and deploy AI agents and workflows, had a critical authorization flaw where the deployment lookup did not verify that a deployment belonged to the caller's own project. Any authenticated user with a valid API key for one project could reference another project's deployment ID and hijack it by linking an attacker-controlled background worker, altering its deployment state. This allows cross-tenant compromise of AI agent deployments, potentially letting an attacker inject their own worker code into a victim's production agent pipeline.
Technical Analysis
The vulnerability lies in CreateDeploymentBackgroundWorkerServiceV4.call(), invoked via POST /api/v1/deployments/:deploymentId/background-workers, where workerDeployment.findFirst() looks up a deployment solely by friendlyId without scoping the query with an environmentId or project-ownership predicate. An attacker with any valid API key can guess or obtain another project's deployment friendlyId (these are often not treated as secrets) and submit it to this endpoint. Because the authorization check is missing, the attacker's own background worker becomes linked to the victim's deployment, and the victim deployment transitions from BUILDING to DEPLOYING under attacker influence. This crosses tenant/project trust boundaries entirely at the API layer, giving the attacker the ability to inject or substitute worker code that executes within the victim's agent deployment context, effectively achieving cross-tenant code execution and agent supply-chain compromise.
Affected Systems
Trigger.dev
Detection Signatures
- Log entries showing background-worker creation requests where the deployment's environmentId/projectId does not match the requesting API key's project scope
- Repeated POST /api/v1/deployments/:deploymentId/background-workers calls referencing deployment friendlyIds not previously issued to that API key's project
- Unexpected transition of a deployment from BUILDING to DEPLOYING without a corresponding build-completion event from the owning project
- Background worker registrations whose source/build metadata does not match the deployment's known CI/build pipeline
Remediation Steps
- 1
Upgrade immediately
Update Trigger.dev to version 4.5.6 or later, which adds the missing environmentId/project ownership check to the deployment lookup.
- 2
Audit deployment history
Review recent deployment and background-worker linkage events for cross-project anomalies, especially deployments transitioning state without expected build activity.
- 3
Rotate and scope API keys
Rotate API keys and ensure keys are scoped as tightly as possible to reduce blast radius if reused across environments.
- 4
Enforce tenant isolation checks
For any self-hosted or custom deployment services, add explicit object-level authorization checks (verify resource ownership against the authenticated principal) on every ID-based lookup, not just at the authentication layer.
- 5
Treat resource identifiers as non-secret
Do not rely on friendlyId obscurity for security; ensure all endpoints validate ownership regardless of ID guessability.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.