Trigger.dev CVE-2026-114075

Exploitation requires three concrete conditions: (1) the attacker must already possess a valid capability-restricted user-actor token (UAT), specifically a read-only one - this is a privilege-escalation-within-authentication flaw, not an unauthenticated bypass; (2) the target must be running Trigger.dev before 4.5.12, which still exposes the legacy personal access token helper code path that fails to enforce UAT capability restrictions on the project alertChannels endpoint; (3) the attacker issues a POST to that project alertChannels endpoint to register a production webhook channel. Limiting factors that reduce realistic risk: the mandatory possession of a pre-issued token (PR:L), impact confined to alert rerouting (low confidentiality/integrity, no availability impact), and that only deployments on affected versions issuing scoped tokens to less-trusted actors are at risk.

This is a medium-severity authorization bypass (CWE-863) with a vendor-provided CVSS 4.0 score of 5.3, and the signals are internally consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N) correctly reflects the description: the attack is network-reachable with low complexity and no user interaction, but it is NOT unauthenticated - PR:L means the attacker must already hold a valid (even if read-only, capability-restricted) user-actor token. This authentication prerequisite is the single biggest factor keeping real-world risk moderate rather than critical. No EPSS score was provided in the input, the CVE is NOT listed in CISA KEV, and no public proof-of-concept is referenced, so by the precision rules this is 'no public exploit identified at time of analysis.' The low confidentiality/integrity impact (VC:L/VI:L) and null availability impact match an alert-rerouting primitive rather than code execution or data destruction. Net assessment: a legitimate but not top-priority issue - it is a privilege-boundary defeat that should be patched promptly for any Trigger.dev deployment issuing scoped tokens to semi-trusted users, but it is not a mass-exploitation, high-CVSS-but-overhyped emergency. It was reported by VulnCheck and a fix exists in 4.5.12.

An attacker who has been issued a read-only, capability-restricted user-actor token (for example a limited collaborator or an over-scoped CI token) calls the project alertChannels endpoint through the legacy personal access token helper, which fails to enforce the token's capability restrictions. They create a production webhook alert channel pointing at infrastructure they control, so future deployment and error alerts - potentially containing sensitive operational detail - are delivered to the attacker. No public exploit code is identified at time of analysis, but the described HTTP flow is simple and low-complexity.