CVE-2026-114082 in Trigger.dev
Summary
by MITRE • 10/22/2026
Trigger.dev before 4.6.2 contains an authorization vulnerability that allows public-token holders with session write access to obtain environment-wide S2 stream credentials via session input initialization. Attackers can use the credential directly against the storage API to append, create, or trim other session and run streams, forging output or permanently deleting records.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The identified vulnerability in Trigger.dev versions prior to 4.6.2 represents a critical authorization flaw rooted in improper access control mechanisms within the application's session management subsystem. Specifically, the issue arises from an insufficiently restrictive permission model that allows users possessing public tokens with write access to sessions to manipulate underlying infrastructure credentials indirectly through input initialization processes. This architectural weakness enables attackers to escalate their privileges beyond intended boundaries by leveraging the session input mechanism as a vector for credential extraction. The core technical flaw lies in the application's failure to properly validate whether the entity requesting environment-wide Server-to-Server stream credentials has legitimate authorization for such high-level access, thereby trusting inputs from lower-privileged contexts without adequate isolation checks.
From an operational perspective, this vulnerability poses severe risks to data integrity and availability within the Trigger.dev ecosystem. An attacker who successfully exploits this flaw can obtain S2 stream credentials that are scoped at the environment level rather than being restricted to specific sessions or runs. These credentials provide direct access to storage APIs, allowing malicious actors to perform destructive actions such as appending unauthorized data, creating new streams with forged outputs, or permanently deleting existing records associated with other users' sessions and execution runs. This capability effectively compromises the multi-tenancy isolation that is fundamental to cloud-based workflow automation platforms, potentially leading to widespread data corruption, loss of audit trails, and manipulation of automated business logic outcomes across multiple tenants sharing the same environment configuration.
The exploitation path aligns closely with CWE-269, which classifies Improper Privilege Control, as it involves a user gaining access to resources or functions that they are not authorized to use. Furthermore, this vulnerability can be mapped to MITRE ATT&CK techniques related to Credential Access and Defense Evasion, specifically how attackers might harvest credentials from local systems or applications to maintain persistence or expand their foothold within the target infrastructure. The ability to forge output streams also touches upon CWE-345, Insufficient Verification of Data Authenticity, as it allows for the injection of false data into trusted pipelines without detection by standard validation mechanisms that rely on signature verification rather than origin authorization checks.
To mitigate this vulnerability, organizations running Trigger.dev must immediately upgrade to version 4.6.2 or later where these access control restrictions have been enforced. In addition to patching, administrators should review their token permission scopes and adhere strictly to the principle of least privilege by ensuring that public tokens are granted only the minimum necessary permissions required for specific tasks rather than broad write access unless absolutely essential. Implementing additional monitoring for unusual patterns in stream creation or deletion events can help detect potential exploitation attempts early. Security teams should also consider implementing strict input validation on session initialization parameters to prevent unauthorized credential requests from being processed by the backend services, thereby adding a layer of defense-in-depth against privilege escalation attacks targeting infrastructure-level resources.