Trigger.dev EUVD-2026-107028

Exploitation requires the attacker to already hold a valid Trigger.dev environment API key for any tenant (PR:L - this is self-service in a multi-tenant deployment), a victim deployment that is currently in-progress (the attack re-points an in-progress deployment, matching AT:P), and knowledge of the victim's deployment friendlyId to place in the POST to the deployment background-workers endpoint. The flaw is reachable only because createDeploymentBackgroundWorkerV4 resolves the deployment by friendlyId without environment/project/organization scoping. Limiting factors: the attacker must be authenticated with their own key (not fully unauthenticated), must hit the timing window while the target deployment is in progress, must know or guess the target friendlyId, and the instance must run a version before 4.5.6 - upgrading to 4.5.6 closes the gap.

This is a moderate-severity cross-tenant authorization flaw (CWE-639, IDOR) in Trigger.dev's createDeploymentBackgroundWorkerV4, rated CVSS 4.0 base 6.1. The provided CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:H/VA:H) signals a network-reachable but non-trivial attack: it requires existing low-level privileges (PR:L - the attacker's own valid environment API key) plus a present attack requirement (AT:P) and high complexity, because exploitation depends on a victim deployment being in-progress and the attacker supplying the correct deployment ID. Impact is integrity- and availability-weighted (VI:H/VA:H) with limited confidentiality (VC:L), consistent with hijacking/re-pointing another tenant's deployment rather than reading their data. No EPSS score, KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the risk is driven by the structural tenant-isolation break and VulnCheck/vendor confirmation, not by observed in-the-wild activity. Net: a genuine multi-tenant isolation bug worth patching promptly for any shared/hosted Trigger.dev instance, but the PR:L + AC:H + AT:P combination and absence of exploitation signals place it below drop-everything urgency. Note the signals are internally consistent (authenticated, timing-dependent cross-tenant abuse); the main missing data are EPSS/KEV/POC, whose absence is not itself an error.

An attacker who is a legitimate but low-privileged tenant on a shared Trigger.dev instance uses only their own environment API key to POST to the deployment background-workers endpoint, supplying a victim tenant's in-progress deployment friendlyId. Because the server resolves the deployment by friendlyId alone without checking environment, project, or organization ownership, the attacker re-points the victim's active deployment to a background worker in the attacker's own environment. No public exploit code was provided in the intelligence, but the attack requires only standard authenticated API access and a timing window where the victim deployment is in progress.