CVE-2026-114075 in Trigger.dev
Summary
by MITRE • 10/21/2026
Trigger.dev before 4.5.12 contains an authorization bypass vulnerability that allows holders of capability-restricted user-actor tokens to create alert channels by using the legacy personal access token helper. Attackers with a read-only UAT can POST to the project alertChannels endpoint to create production webhook channels, routing future deployment and error alerts to attacker-controlled infrastructure.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
Trigger.dev versions prior to 4.5.12 are affected by a critical authorization bypass vulnerability that stems from an inconsistency in how legacy authentication mechanisms interact with modern capability-restricted user-actor tokens. This flaw allows attackers who possess read-only or otherwise restricted User Actor Tokens (UATs) to escalate their privileges and perform administrative actions, specifically the creation of alert channels. The root cause lies in the application's handling of the legacy personal access token helper, which fails to properly enforce the scope limitations defined by the UAT when processing requests for sensitive endpoints. Consequently, an attacker can bypass intended security controls that should restrict write operations on configuration resources based on the user's assigned role or permissions.
The technical exploitation involves sending a POST request to the project alertChannels endpoint using the restricted token through this legacy helper mechanism. Because the authorization logic does not correctly validate whether the current actor has permission to modify alert configurations, the system accepts and processes the request as if it were coming from an administrator with full privileges. This allows the attacker to define new webhook endpoints that point to infrastructure under their control. By establishing these channels, the attacker gains a persistent foothold within the application's notification pipeline, effectively turning legitimate operational alerts into vectors for data exfiltration or further network reconnaissance.
The operational impact of this vulnerability is significant, particularly in environments where automated deployment and error monitoring are critical to business continuity. Once an alert channel is created pointing to an attacker-controlled server, all future production deployments, system errors, and performance anomalies will be transmitted directly to the adversary's infrastructure. This provides a continuous stream of sensitive information regarding application behavior, internal architecture, and potential security incidents that were previously hidden from unauthorized users. Furthermore, if these alerts contain stack traces or detailed error logs, they may expose source code snippets, database queries, or internal IP addresses, facilitating more advanced attacks such as SQL injection or server-side request forgery against other parts of the infrastructure.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization, as the system fails to enforce proper access control policies for specific API endpoints. In terms of adversary tactics, it maps directly to ATT&CK technique T1505.003 Server Message Block (SMB) Services or more broadly T1505 Web Shell if interpreted through a broader lens of persistent backdoors, but specifically relates to data exfiltration via compromised communication channels akin to T1048 Exfiltration Over Alternative Protocol. The use of legacy helpers for modern token types represents a common pattern in technical debt accumulation where backward compatibility features are not subjected to the same rigorous security reviews as new code paths.
To mitigate this vulnerability, organizations must immediately upgrade Trigger.dev to version 4.5.12 or later, which addresses the authorization logic flaw within the personal access token helper. Until an upgrade is possible, administrators should audit existing alert channels for any unexpected webhook endpoints and revoke them if they do not correspond to known internal services. It is also advisable to restrict network egress rules to prevent outbound connections to unknown external IPs from application servers, thereby limiting the effectiveness of exfiltrated data even if a channel is compromised. Long-term remediation should involve removing support for legacy authentication helpers that are no longer necessary and ensuring that all API endpoints strictly validate permissions against the current user's role definitions rather than relying on potentially ambiguous token types.