Trigger.dev EUVD-2026-106895

Target is the dashboard run replay POST action at apps/webapp/app/routes/resources.taskruns.$runParam.replay.ts, whose action() handler (unlike the GET loader) calls neither requireUser() nor requireUserId() and applies no organization membership filter, querying taskRun by friendlyId alone. Concrete prerequisites: the attacker must (1) reach the instance over the network and (2) know or enumerate the victim's run friendlyId (format run_<id>, described as short, incrementing, enumerable strings) and supply a target environmentId. No non-default configuration is required - the vulnerable route is a standard dashboard resource. Limiting factors: the GHSA advisory frames exploitation as requiring a valid session ('any authenticated user'), which contradicts the code's lack of an auth check and the PR:N vector, so authentication requirements are not definitively confirmed; successful abuse also depends on knowing a valid friendlyId and a reachable victim environment. The same missing-auth bug class also affects resources.batches.$batchId.check-completion.ts.

The vendor CVSS 4.0 base score of 8.3 (High) reflects a network-reachable (AV:N), low-complexity (AC:L) flaw with no user interaction and high confidentiality impact (VC:H), tempered by an attack requirement (AT:P) - the attacker must know or enumerate the target run's friendlyId. A working proof-of-concept is published inside the vendor GHSA advisory, so publicly available exploit code exists; however, there is no EPSS score and no CISA KEV listing provided, so there is no evidence of active or widespread exploitation at this time. A key signal conflict must be verified: the CVSS vector sets PR:N (unauthenticated), yet the GHSA advisory repeatedly frames the issue as exploitable by 'any authenticated user' with a valid session cookie - the action handler itself contains no requireUser() call (supporting PR:N), but the realistic threat model assumes an authenticated tenant abusing cross-organization access (an IDOR). This gap should be confirmed with the vendor. Net assessment: a genuine, patch-worthy authorization/authentication flaw with a public PoC, but real-world mass-exploitation risk is moderated by the relatively niche deployment footprint of Trigger.dev, the need to know/enumerate friendlyIds, and the likely requirement of a tenant session - making this more suited to targeted abuse than opportunistic internet-wide scanning.

A user with any valid session on a multi-tenant Trigger.dev instance (or, per the code, potentially any requester, since the action performs no auth check) sends a crafted POST to the run replay route supplying another organization's run friendlyId and an attacker-chosen environmentId. Because the action handler skips authentication and organization scoping and looks up the run by friendlyId alone, the ReplayTaskRunService re-executes the victim's task, exposing its payload and running it again with the victim's secrets. A proof-of-concept HTTP request is published in the vendor GHSA advisory.