Trigger.dev CVE-2026-114071

Exploitation requires an authenticated member already belonging to the target Trigger.dev project (PR:L) who additionally knows the victim's specific waitpoint 'friendly ID' - this knowledge requirement is the attack requirement (AT:P) and raises complexity (AC:H). The affected path is the waitpoint-complete route reached by submitting type=DATETIME or type=MANUAL with isTimeout, and impact is confined to the DEVELOPMENT environment only. Limiting factors: the attacker must be an existing project member (no external/unauthenticated reach), must discover a valid per-victim waitpoint identifier, and cannot affect production or other environments - only integrity of a pending dev waitpoint's completion state is impacted, with no data disclosure or service outage.

This is a genuinely low-priority issue, and the signals are consistent in saying so. The vendor-supplied CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N) scores only 2.3, reflecting that exploitation requires an already-authenticated project member (PR:L), involves elevated complexity plus a specific attack requirement (AC:H/AT:P - the attacker must know the victim's waitpoint friendly ID), and produces only a low integrity impact with no confidentiality or availability loss. Critically, the flaw is scoped to the DEVELOPMENT environment, further limiting real-world consequence. No EPSS score, CISA KEV listing, or public POC was provided; exploitation status is therefore 'no public exploit identified at time of analysis.' There are no conflicting signals here - a low CVSS, no exploitation evidence, an insider-only trust boundary, and a dev-only blast radius all point the same direction. The main residual uncertainty is that EPSS is absent, so statistical exploitation likelihood cannot be independently confirmed, but given the preconditions widespread exploitation is implausible. Treat as a routine patch-on-schedule item, not an emergency.

A malicious or curious authenticated member of a Trigger.dev project learns another member's waitpoint friendly ID (e.g., from shared logs or UI) and submits a type=DATETIME or type=MANUAL (isTimeout) completion request against the waitpoint-complete route, bypassing the per-user ownership check. This prematurely marks the victim's pending DEVELOPMENT-environment waitpoint as completed, disrupting their in-progress workflow. No public exploit code was identified at the time of analysis.