Summary
Trigger.dev contains an authorization bypass in schedule deletion and activation services, allowing an authenticated user to act on schedules belonging to another organization. Under deployments where schedule identifiers are accepted without verifying project or organization ownership, an attacker may delete or disable another organization's imperative cron schedules.
Trigger.dev contains an authorization bypass in schedule deletion and activation services, allowing an authenticated user to act on schedules belonging to another organization. Under deployments where schedule identifiers are accepted without verifying project or organization ownership, an attacker may delete or disable another organization's imperative cron schedules.
Affected context
The vulnerability occurs in Trigger.dev deployments using the DeleteTaskScheduleService and SetActiveOnTaskScheduleService. It becomes risky when an authenticated request can reference a schedule friendlyId through the caller's own project route without a reliable authorization check tying the target schedule to the caller's organization or project.
The vulnerability occurs in Trigger.dev deployments using the DeleteTaskScheduleService and SetActiveOnTaskScheduleService. It becomes risky when an authenticated request can reference a schedule friendlyId through the caller's own project route without a reliable authorization check tying the target schedule to the caller's organization or project.
Exploit preconditions
- Attack surface: Authenticated schedule-management routes
- Required access: A valid authenticated user account with access to a project schedule route
- Trigger point: Delete or disable operations handled by the affected schedule services
- Target condition: A victim schedule friendlyId is supplied as the referenced resource
- Why exploitation is possible: Authorization checks fail to confirm that the target schedule belongs to the requesting organization or project
- Attack surface: Authenticated schedule-management routes
- Required access: A valid authenticated user account with access to a project schedule route
- Trigger point: Delete or disable operations handled by the affected schedule services
- Target condition: A victim schedule friendlyId is supplied as the referenced resource
- Why exploitation is possible: Authorization checks fail to confirm that the target schedule belongs to the requesting organization or project
Why this happens
The underlying bug is an object-level authorization failure mapped to CWE-639: Authorization Bypass Through User-Controlled Key. The services trust a caller-controlled schedule identifier without consistently enforcing ownership or tenant boundaries before performing destructive or state-changing actions. This insecure pattern allows a valid user to use an otherwise legitimate endpoint to operate on resources outside the user's authorized scope.
The underlying bug is an object-level authorization failure mapped to CWE-639: Authorization Bypass Through User-Controlled Key. The services trust a caller-controlled schedule identifier without consistently enforcing ownership or tenant boundaries before performing destructive or state-changing actions. This insecure pattern allows a valid user to use an otherwise legitimate endpoint to operate on resources outside the user's authorized scope.
Potential impact
- An authenticated user may delete another organization's imperative cron schedules
- An attacker could disable schedules and interrupt automated task execution
- Scheduled workflows may fail, be delayed, or remain inactive
- Organizations could experience operational disruption and loss of scheduling integrity
- Repeated abuse could affect availability across multiple tenant boundaries
- An authenticated user may delete another organization's imperative cron schedules
- An attacker could disable schedules and interrupt automated task execution
- Scheduled workflows may fail, be delayed, or remain inactive
- Organizations could experience operational disruption and loss of scheduling integrity
- Repeated abuse could affect availability across multiple tenant boundaries
General mitigation guidance
Mitigation generally focuses on enforcing server-side, object-level authorization
for every schedule operation.
Common defensive patterns include:
- Resolve the target schedule within the authenticated user's organization and authorized project scope
- Perform ownership and tenant checks before deletion or activation-state changes
- Avoid treating user-controlled identifiers as sufficient proof of authorization
- Use deny-by-default authorization policies for destructive and state-changing actions
- Apply least privilege to schedule-management roles and service identities
- Record and review cross-tenant authorization failures and sensitive schedule changes
Mitigation generally focuses on enforcing server-side, object-level authorization
for every schedule operation.
Common defensive patterns include:
- Resolve the target schedule within the authenticated user's organization and authorized project scope
- Perform ownership and tenant checks before deletion or activation-state changes
- Avoid treating user-controlled identifiers as sufficient proof of authorization
- Use deny-by-default authorization policies for destructive and state-changing actions
- Apply least privilege to schedule-management roles and service identities
- Record and review cross-tenant authorization failures and sensitive schedule changes
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review checks for resource lookups based only on caller-supplied identifiers
- Review of delete and state-change handlers for missing tenant, project, or ownership predicates
- Authorization tests that attempt cross-organization access using valid authenticated accounts
- Policy checks requiring object-level authorization before destructive operations
- Audit-log monitoring for schedule changes initiated by users outside the resource's owning scope
- Automated security testing and code review tools that identify insecure direct object reference patterns
Organizations can look for this class of issue through:
- Static analysis and code review checks for resource lookups based only on caller-supplied identifiers
- Review of delete and state-change handlers for missing tenant, project, or ownership predicates
- Authorization tests that attempt cross-organization access using valid authenticated accounts
- Policy checks requiring object-level authorization before destructive operations
- Audit-log monitoring for schedule changes initiated by users outside the resource's owning scope
- Automated security testing and code review tools that identify insecure direct object reference patterns
