Trigger.dev EUVD-2026-58390

Requires a valid Trigger.dev API key for any project (PR:L) - this is authenticated per the CVSS vector, not anonymous. The attacker must know or guess the victim deployment's friendlyId, and the target deployment must be in a state where linking a background worker and transitioning BUILDING→DEPLOYING is meaningful. No user interaction is needed (UI:N) and the request is fully network-remote (AV:N) against the /api/v1/deployments/:deploymentId/background-workers endpoint. Limiting factors: exploitation is bounded by possession of a valid API key and by knowledge of a victim's deployment identifier; it does not work against fully unauthenticated callers, and it is only impactful on affected versions prior to the fix.

The signals are mostly consistent toward high priority: the vendor-supplied vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:H yields 9.9, reflecting a network-reachable, low-complexity attack that needs only low privileges (any valid API key) and crosses a tenant boundary (scope change). Attaching an attacker-owned worker to a victim deployment and advancing its lifecycle is a genuine integrity and potentially availability/code-execution concern for the victim project, so operators - from large SaaS tenants down to a mid-sized team self-hosting a single instance - should treat this as urgent. Tempering factors: there is no CISA KEV listing and no EPSS score in the provided data, and no public PoC was supplied, so this is not confirmed as actively exploited - it is a high-severity, easily-reachable authorization flaw rather than a demonstrated in-the-wild campaign. One data conflict must be resolved: the description states the fix landed in 4.5.6 (twice), but the reference set points to release tag v4.5.2 and PR #4199 - verify the exact fixed version with the vendor advisory (GHSA-j6vv-pq9h-f4wj) before relying on either number.

An attacker signs up for or already holds any low-privilege Trigger.dev account and generates a valid API key for their own project. They obtain a victim deployment's friendlyId (guessable/enumerable or leaked) and POST to /api/v1/deployments/:deploymentId/background-workers with that identifier, causing the server to link their attacker-controlled background worker to the victim's deployment and advance it from BUILDING to DEPLOYING. No public PoC is documented, but the low attack complexity and single authenticated request make exploitation straightforward if a valid identifier is known.