Summary
Trigger.dev before 4.6.0 has a missing authorization check in the waitpoint token wait endpoint. An authenticated attacker with a valid secret API key may cause a run belonging to another organization to block indefinitely and may provide resume data to that run.
Trigger.dev before 4.6.0 has a missing authorization check in the waitpoint token wait endpoint. An authenticated attacker with a valid secret API key may cause a run belonging to another organization to block indefinitely and may provide resume data to that run.
Affected context
The vulnerability occurs in Trigger.dev deployments using the waitpoint token wait endpoint when authorization is not verified against the organization that owns the referenced run. It becomes risky when an authenticated tenant can submit another organization's run identifier and the endpoint accepts the request without confirming ownership of the target run and waitpoint.
The vulnerability occurs in Trigger.dev deployments using the waitpoint token wait endpoint when authorization is not verified against the organization that owns the referenced run. It becomes risky when an authenticated tenant can submit another organization's run identifier and the endpoint accepts the request without confirming ownership of the target run and waitpoint.
Exploit preconditions
- Attack surface: The waitpoint token wait API endpoint
- Required access: Any authenticated secret API key accepted by the service
- Trigger point: A request that associates an attacker-controlled waitpoint with a run identifier belonging to another organization
- Why exploitation is possible: The endpoint does not adequately enforce tenant ownership or authorization for the referenced run before changing its wait state or accepting resume data
- Attack surface: The waitpoint token wait API endpoint
- Required access: Any authenticated secret API key accepted by the service
- Trigger point: A request that associates an attacker-controlled waitpoint with a run identifier belonging to another organization
- Why exploitation is possible: The endpoint does not adequately enforce tenant ownership or authorization for the referenced run before changing its wait state or accepting resume data
Why this happens
The underlying bug is a missing object-level authorization check. The endpoint appears to authenticate the caller but does not consistently verify that the caller is authorized to access the specific run and waitpoint identified by the request.
This maps to CWE-639: Authorization Bypass Through User-Controlled Key, in which a user-controlled identifier is used to select an object without enforcing authorization for that object. Authentication alone is treated as sufficient, allowing cross-organization workflow state to be manipulated.
The underlying bug is a missing object-level authorization check. The endpoint appears to authenticate the caller but does not consistently verify that the caller is authorized to access the specific run and waitpoint identified by the request.
This maps to CWE-639: Authorization Bypass Through User-Controlled Key, in which a user-controlled identifier is used to select an object without enforcing authorization for that object. Authentication alone is treated as sufficient, allowing cross-organization workflow state to be manipulated.
Potential impact
- An attacker may block runs belonging to another organization indefinitely
- Affected workflows could experience processing delays or service disruption
- Unauthorized resume data may be injected into a victim run
- Cross-tenant workflow integrity and availability could be compromised
- Dependent jobs or business processes could be delayed or fail
- An attacker may block runs belonging to another organization indefinitely
- Affected workflows could experience processing delays or service disruption
- Unauthorized resume data may be injected into a victim run
- Cross-tenant workflow integrity and availability could be compromised
- Dependent jobs or business processes could be delayed or fail
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the object level for every waitpoint and run operation.
Defensive patterns include:
- Verify that the authenticated principal owns, or is explicitly authorized to access, the referenced run and waitpoint
- Derive organization and tenant context from trusted server-side identity data rather than request parameters
- Apply authorization checks before changing workflow state or accepting resume data
- Use deny-by-default policies for cross-tenant object access
- Limit API-key privileges and scope keys to the smallest necessary organization and operation set
- Treat run identifiers and waitpoint tokens as references, not proof of authorization
- Record and monitor rejected cross-tenant access attempts
Mitigation generally focuses on enforcing authorization at the object level for every waitpoint and run operation.
Defensive patterns include:
- Verify that the authenticated principal owns, or is explicitly authorized to access, the referenced run and waitpoint
- Derive organization and tenant context from trusted server-side identity data rather than request parameters
- Apply authorization checks before changing workflow state or accepting resume data
- Use deny-by-default policies for cross-tenant object access
- Limit API-key privileges and scope keys to the smallest necessary organization and operation set
- Treat run identifiers and waitpoint tokens as references, not proof of authorization
- Record and monitor rejected cross-tenant access attempts
How teams detect issues like this
Detection can include:
- Static analysis and code review checks for database lookups or state changes based on user-supplied identifiers without a corresponding ownership check
- Tests that attempt to access runs, waitpoints, and workflow state across organization boundaries
- API policy checks requiring tenant scoping on every object-level operation
- Logging and alerting for repeated requests involving identifiers outside the caller's organization
- Automated authorization testing that verifies both authentication and resource ownership enforcement
Detection can include:
- Static analysis and code review checks for database lookups or state changes based on user-supplied identifiers without a corresponding ownership check
- Tests that attempt to access runs, waitpoints, and workflow state across organization boundaries
- API policy checks requiring tenant scoping on every object-level operation
- Logging and alerting for repeated requests involving identifiers outside the caller's organization
- Automated authorization testing that verifies both authentication and resource ownership enforcement
