Summary
Trigger.dev deployments may be exposed to an authorization bypass when a background-worker operation resolves a deployment using only its friendly identifier. An attacker with an API key for their own environment could potentially redirect an in-progress deployment belonging to another environment to a worker under the attacker's control.
Trigger.dev deployments may be exposed to an authorization bypass when a background-worker operation resolves a deployment using only its friendly identifier. An attacker with an API key for their own environment could potentially redirect an in-progress deployment belonging to another environment to a worker under the attacker's control.
Affected context
The issue occurs in Trigger.dev deployment workflows that use the background-workers endpoint and identify WorkerDeployment records by friendlyId without consistently applying environment, project, or organization scope. Risk depends on whether an attacker can obtain a valid API key for an environment and can reference a deployment identifier associated with another tenant or organizational context.
The issue occurs in Trigger.dev deployment workflows that use the background-workers endpoint and identify WorkerDeployment records by friendlyId without consistently applying environment, project, or organization scope. Risk depends on whether an attacker can obtain a valid API key for an environment and can reference a deployment identifier associated with another tenant or organizational context.
Exploit preconditions
- Attack surface: Deployment background-workers API endpoint
- Required access: A valid API key for an attacker-controlled environment
- Target condition: An in-progress deployment identifier from another environment, project, or organization is known or obtainable
- Trigger point: Processing a request that associates the selected deployment with a worker
- Why exploitation is possible: The deployment lookup relies on a friendly identifier without enforcing all relevant authorization boundaries
- Attack surface: Deployment background-workers API endpoint
- Required access: A valid API key for an attacker-controlled environment
- Target condition: An in-progress deployment identifier from another environment, project, or organization is known or obtainable
- Trigger point: Processing a request that associates the selected deployment with a worker
- Why exploitation is possible: The deployment lookup relies on a friendly identifier without enforcing all relevant authorization boundaries
Why this happens
The underlying flaw is an object-level authorization failure mapped to CWE-639: Authorization Bypass Through User-Controlled Key. The application accepts an identifier for a deployment but does not bind the lookup and subsequent update to the authenticated caller's environment, project, and organization scope. As a result, possession of a valid credential may be incorrectly treated as sufficient authority to operate on a similarly addressable object outside that credential's permitted scope.
The underlying flaw is an object-level authorization failure mapped to CWE-639: Authorization Bypass Through User-Controlled Key. The application accepts an identifier for a deployment but does not bind the lookup and subsequent update to the authenticated caller's environment, project, and organization scope. As a result, possession of a valid credential may be incorrectly treated as sufficient authority to operate on a similarly addressable object outside that credential's permitted scope.
Potential impact
- An attacker could redirect an in-progress deployment to a worker in their own environment.
- Deployment integrity could be compromised.
- Victim workloads could be affected by unauthorized worker selection.
- Cross-tenant isolation could be weakened.
- Operational disruption or supply-chain-style tampering could occur.
- An attacker could redirect an in-progress deployment to a worker in their own environment.
- Deployment integrity could be compromised.
- Victim workloads could be affected by unauthorized worker selection.
- Cross-tenant isolation could be weakened.
- Operational disruption or supply-chain-style tampering could occur.
General mitigation guidance
Mitigation generally focuses on enforcing object-level authorization at every lookup and update boundary.
Defensive patterns include:
- Scope deployment queries by authenticated environment, project, and organization identifiers.
- Perform authorization checks immediately before changing deployment relationships.
- Prefer server-derived tenant context over caller-supplied scope values.
- Use opaque, non-guessable identifiers where appropriate, while treating them as identifiers rather than authorization controls.
- Apply least privilege to environment API keys and separate credentials by tenant and operation.
- Fail closed when ownership or scope cannot be established.
Mitigation generally focuses on enforcing object-level authorization at every lookup and update boundary.
Defensive patterns include:
- Scope deployment queries by authenticated environment, project, and organization identifiers.
- Perform authorization checks immediately before changing deployment relationships.
- Prefer server-derived tenant context over caller-supplied scope values.
- Use opaque, non-guessable identifiers where appropriate, while treating them as identifiers rather than authorization controls.
- Apply least privilege to environment API keys and separate credentials by tenant and operation.
- Fail closed when ownership or scope cannot be established.
How teams detect issues like this
Detection can include:
- Static analysis for database lookups using user-controlled identifiers without tenant or ownership predicates.
- Code review checks for authorization performed separately from object retrieval or omitted before mutation.
- API policy tests that attempt cross-environment access using otherwise valid credentials.
- Audit-log monitoring for deployment changes where the actor, environment, and deployment owner differ.
- Automated review tools and repository rules that flag missing resource-scope checks on mutating endpoints.
Detection can include:
- Static analysis for database lookups using user-controlled identifiers without tenant or ownership predicates.
- Code review checks for authorization performed separately from object retrieval or omitted before mutation.
- API policy tests that attempt cross-environment access using otherwise valid credentials.
- Audit-log monitoring for deployment changes where the actor, environment, and deployment owner differ.
- Automated review tools and repository rules that flag missing resource-scope checks on mutating endpoints.
