Trigger.dev isolates projects into multiple environments, each with its own secret API key and trust boundary. Most API routes enforce environment scoping by filtering resource lookups with the authenticated environment ID. However, the deployment cancel operation uses a lookup scoped only by project ID, ignoring the environment ID. Consequently, an API key for any environment within a project can cancel deployments in any other environment of the same project, including production. The deployment GET route correctly scopes by environment and denies access to unauthorized environments, but the cancel route allows cancellation despite this. This asymmetry is a security bug. The vulnerability was demonstrated with a proof-of-concept where a dev environment key canceled a production deployment it could not read. The issue affects Trigger.dev versions prior to 4.5.6 and impacts both self-hosted and cloud instances.

An attacker or user with access to a lower-trust environment API key (e.g., dev or preview) within a project can cancel in-progress deployments in higher-trust environments (e.g., production) of the same project. This could disrupt production deployments without proper authorization. The vulnerability does not allow reading or modifying deployment details beyond cancellation, and cross-project cancellation is not possible. There is no indication of data confidentiality loss, but availability and integrity of deployment processes are impacted.

A patch is available for this vulnerability as indicated by the vendor. Users should upgrade to version 4.5.6 or later where the deployment cancel operation is correctly scoped by environment ID. Until patched, avoid using lower-trust environment keys in contexts where they could be abused to cancel production deployments. Review API key permissions and environment isolation policies. Since this affects self-hosted and cloud deployments, self-hosted users must apply the update; cloud users should verify with the vendor if the service has been updated.