Trigger.dev CVE-2026-114079

Requires the attacker to possess a valid but lower-trust secret API key (dev, preview, or CI/per-PR preview-branch key) for the SAME project as the target, and the target deployment must be in a non-final, in-progress state (PENDING, INSTALLING, BUILDING, or DEPLOYING) - validateDeployment rejects only FINAL_DEPLOYMENT_STATUSES. Limiting factors that reduce real-world risk: the flaw cannot cross project boundaries (lookup is still projectId-scoped), it cannot read or exfiltrate the production deployment (the GET route remains correctly environmentId-scoped and returns 404), it only cancels - not modifies or deploys - and affected installs must be running trigger.dev before 4.5.6 (self-hosted or cloud).

This is a genuine but moderate-severity authorization flaw, not a critical priority. The vendor-provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the score of 5.3 (MEDIUM) are internally consistent with the description: exploitation is network-reachable, low-complexity, requires no user interaction, but does require privileges (PR:L) - specifically a valid lower-trust API key for the target project. Impact is correctly scoped to partial integrity/availability (VI:L/VA:L) with no confidentiality loss (VC:N), matching a flaw that cancels (disrupts) deployments but does not read or steal data. No EPSS score was provided, the CVE is NOT on CISA KEV, and no public proof-of-concept is referenced, so exploitation status is 'no public exploit identified at time of analysis.' The signals do not conflict: a MEDIUM CVSS with no KEV/POC and a privilege requirement points to a real-but-limited risk primarily affecting multi-environment CI/CD pipelines where lower-trust keys exist. The main nuance is organizational: because the broken trust boundary is between a project's own environments, the realistic threat is an insider, a compromised dev/preview/CI key, or a malicious collaborator - not an anonymous internet attacker.

An attacker who holds a lower-trust API key (dev, preview, or CI secret key) for a Trigger.dev project - for example a leaked CI secret or a malicious contributor - sends a crafted POST to the deployment cancel endpoint referencing an in-progress production deployment's friendlyId in the same project. Because DeploymentService.getDeployment scopes the lookup by projectId only, the production deployment is cancelled despite the key lacking production privileges, disrupting the release. No public exploit code is referenced, but the flaw is trivially reproducible from the advisory's root-cause analysis.