Trigger.dev CVE-2026-114091

Requires (1) a valid Trigger.dev API key for ANY tenant/environment (PR:L - the attacker must be an authenticated tenant, not fully anonymous), (2) knowledge of the victim's specific run friendlyId, and (3) a target running Trigger.dev before 4.5.0 that exposes the api.v1.runs.$runParam.replay route. The core vulnerable condition is that this route looks up runs by friendlyId alone without scoping to the caller's runtime environment. Limiting factors: impact is bounded to confidentiality (reading the victim's task payload only), it needs an authenticated API key rather than being fully unauthenticated, and it depends on the attacker discovering a valid victim friendlyId (reflected as AT:P), which is not enumerable by default - making this most relevant in shared/multi-tenant hosted deployments.

This is a genuine but moderate-priority cross-tenant authorization flaw (IDOR, CWE-639), not a critical remote-code threat. The source CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H) scores 6.0 (Medium) and the signals are internally consistent: network reachable, but it requires an authenticated API key (PR:L) AND a present attack requirement (AT:P) - the attacker must already know the victim's run friendlyId, which is not enumerable by default. Impact is confidentiality-only (VC:H, VI:N/VA:N): read access to a victim's task payload, with no integrity or availability loss and no subsequent-system scope change (SC:N). No EPSS score, KEV listing, or POC flag was provided, so per input this is 'no public exploit identified at time of analysis.' The absence of KEV/EPSS plus the PR:L and AT:P prerequisites argues against widespread automated exploitation - realistic risk is targeted, originating from a malicious or compromised tenant in a shared multi-tenant Trigger.dev deployment. One caveat: the 4.0 vector marks SC:N (no scope change) even though the attack crosses a tenant trust boundary; a reasonable analyst could argue a scope change, so weigh the cross-tenant data-boundary impact as the key decision factor rather than the raw numeric score.

A legitimate but malicious customer (or an attacker who has stolen any tenant's Trigger.dev API key) learns the friendlyId of a run belonging to another tenant - for example via leaked logs, shared references, or a predictable identifier. They call the api.v1.runs.$runParam.replay route with that friendlyId; because the lookup is not scoped to the caller's runtime environment, the victim's run is replayed into the attacker's own environment, exposing the victim's task payload. No public exploit code was identified at time of analysis, but the technique is trivial to reproduce once a valid target friendlyId is known.