Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain any valid secret API key
-
ExploitCall waitpoint token wait endpoint with victim run ID
-
ExecutionAttach attacker-controlled waitpoint to the run
-
ImpactBlock victim run indefinitely and inject resume data
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | Requires the attacker to possess any valid Trigger.dev secret API key (the CVSS PR:L reflects this low-privilege authenticated requirement) and to know or supply a target run ID belonging to another organization. The flaw is in the waitpoint token wait endpoint, which is reachable over the network (AV:N) with no user interaction (UI:N) and low attack complexity (AC:L). No special non-default configuration is named in the advisory, so default multi-tenant deployments of Trigger.dev prior to 4.6.0 are affected. Limiting factors: the attacker is not fully unauthenticated - a provisioned secret API key is mandatory - and the practical blast radius is largest on shared/multi-tenant instances where keys from one organization can reference another organization's run IDs. |
| Impact | This is a moderate, practically-relevant authorization flaw (CWE-639, IDOR-class) rather than a critical infrastructure break. The source CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H) scores 7.2 and is internally consistent with the description: network-reachable endpoint, low complexity, and low privilege (PR:L) matching the stated requirement of holding 'any secret API key.' The primary impact is availability (victim runs blocked indefinitely, VA:H) and integrity (injected resume data, VI:H), with only limited confidentiality exposure (VC:L). No EPSS score, KEV listing, or POC was supplied: exploitation status is 'no public exploit identified at time of analysis,' so there is no evidence of active or widespread exploitation. The chief risk-amplifying factor is the cross-tenant nature - a single valid API key from any organization can disrupt other organizations' runs on a shared/multi-tenant Trigger.dev instance - which makes this meaningful for hosted or shared deployments. Net: a genuine, patch-worthy priority for multi-tenant Trigger.dev operators, but not an emergency-grade remote code execution; raw CVSS slightly overstates urgency given the authenticated prerequisite and absence of exploitation signals. Note: EPSS and POC data are entirely absent from the input and could not be weighed. |
| Exploit ScenarioDerived | An attacker who has signed up for (or obtained) any valid Trigger.dev secret API key calls the waitpoint token wait endpoint, supplying a run ID belonging to a different organization together with their own waitpoint. The victim's run is then blocked on a waitpoint that only the attacker controls and the victim cannot complete, stalling it indefinitely, and the attacker can inject arbitrary resume data into it. No public exploit code is identified at time of analysis, and the authenticated, low-complexity network vector (PR:L/AC:L) makes the attack straightforward to script once a key is held. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Trigger.dev before 4.6.0 fails to enforce organization scoping in the waitpoint token wait endpoint, allowing an authenticated attacker who holds any valid secret API key to supply another organization's run ID and make that run block indefinitely on a waitpoint the victim cannot complete; the same path can also inject resume data into the targeted run. This is an IDOR-class authorization flaw (CWE-639) affecting default multi-tenant deployments prior to 4.6.0, with the greatest practical impact on shared instances where keys from one organization can reference another organization's runs. No public exploit identified at time of analysis.
RemediationAI
Vendor-released patch: upgrade Trigger.dev to 4.6.0 or later, following the vendor advisory at https://github.com/triggerdotdev/trigger.dev/security/advisories/GHSA-xrp6-5fpv-4fxf and the VulnCheck advisory at https://www.vulncheck.com/advisories/trigger-dev-before-4.6.0-missing-authorization-via-waitpoint-token-wait-endpoint. If immediate upgrade is not possible, restrict and rotate secret API keys so that no key can be used across organizational boundaries, and monitor or block waitpoint token wait calls that reference run IDs outside the caller's organization. On shared or multi-tenant deployments, consider temporarily disabling or network-restricting the waitpoint token wait endpoint until the patch is applied; this breaks legitimate wait/resume workflows and must be scoped carefully. Auditing existing runs for unexpected waitpoints or injected resume data is also advisable. No public exploit identified at time of analysis, but the authorization gap is straightforward to exercise once a valid key and a target run ID are known.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Trigger.dev is a workflow/job orchestration platform where runs can pause on waitpoints and later be resumed when a token is completed. The waitpoint token wait endpoint is reachable over the network and is supposed to ensure that a caller can only operate on runs and waitpoints belonging to its own organization. CVE-2026-114068 is a CWE-639 authorization bypass through a user-controlled key: the endpoint does not adequately verify that the supplied run ID belongs to the caller's organization, so a low-privilege authenticated user with any valid secret API key can bind a victim run to an attacker-controlled waitpoint. The provided CVSS:4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H) and the independent CVSS:3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H) both reflect a network-reachable, low-complexity, authenticated issue requiring no user interaction, with high integrity and availability impact on the targeted run. The CPE cpe:2.3:a:triggerdotdev:trigger.dev:*:*:*:*:*:*:*:* identifies Trigger.dev as the affected product, with versions before 4.6.0 in scope.
Know when Trigger Dev gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N
Any secret API key suffices so PR:L and AC:L; network endpoint (AV:N); indefinite blocking gives A:H and resume-data injection gives I:H, with only limited data exposure (C:L).
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
Trigger.dev before 4.6.0 contains a missing authorization vulnerability in the waitpoint token wait endpoint that allows authenticated attackers to block runs belonging to other organizations. Attackers holding any secret API key can supply a victim run ID with their own waitpoint, causing that run to block indefinitely on a waitpoint the victim cannot complete, and can inject resume data into it.
Technical POC Analysis
CWE-639 (Authorization Bypass Through User-Controlled Key), with a secondary CWE-862 flavor: the run identifier is taken from the URL and used without any ownership check.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Trigger.dev deployments running versions earlier than 4.6.0 do not properly confine workflow runs to the organization that owns them, so a holder of any valid secret API key can stall another tenant's run indefinitely or push unauthorized resume data into it. On shared, multi-tenant instances this breaks the isolation assumption customers and internal teams depend on when consolidating automation onto one platform. Leadership should care about two things: business processes that silently stop when runs are blocked on waitpoints nobody can complete, and the integrity of workflow data owned by other parts of the organization.
No vendor-released patch identified at time of analysis. Interim mitigations: separate tenants onto distinct Trigger.dev instances or deployments so keys from one organization cannot reference another organization's runs; rotate and tightly scope secret API keys, issuing per-tenant and per-environment keys instead of shared ones; restrict network access to the waitpoint token endpoint; enable and review audit logging for cross-organization run ID references; and alert on runs blocked on incomplete waitpoints or on unexpected resume data appearing in a run.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Related Vulnerabilities in Trigger.dev Authorization and Injection Flaws
View all 29More in Trigger Dev
View allPrototype pollution in Trigger.dev's run metadata API (versions 3.3.8 through 4.5.5) lets any authenticated tenant corru
Cross-tenant authorization bypass in Trigger.dev before 4.5.6 lets a caller holding a valid API key for one project act
Missing authorization on the run replay API endpoint in Trigger.dev before 4.5.2 allows authenticated attackers to injec
EUVD-2026-107019
GHSA-q775-f6f3-5923
NVD
CVE.org
EPSS
Exploit-DB