CVE-2026-114069 in Trigger.dev
Summary
by MITRE • 10/21/2026
Trigger.dev before 4.6.0 contains an improper authorization vulnerability in the GET /api/v1/projects/:projectRef/envvars endpoint, which returns the environment's root API key as TRIGGER_SECRET_KEY for staging, production, and preview environments. Attackers holding a restricted read:envvars key can obtain the root secret and plaintext secrets, then trigger tasks and mint admin public JWTs.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Trigger.dev versions prior to 4.6.0 represents a critical failure in access control mechanisms within the application's API layer. Specifically, this flaw resides in the GET /api/v1/projects/:projectRef/envvars endpoint, which is designed to retrieve environment variables associated with specific projects. The core issue stems from improper authorization checks that fail to distinguish between restricted and unrestricted scopes when handling sensitive configuration data. This misconfiguration allows an attacker possessing a limited API key with only read:envvars permissions to bypass intended restrictions and access information that should be strictly protected, leading to a significant escalation of privileges within the application's security model.
From a technical perspective, the vulnerability exploits the endpoint's tendency to return the environment's root API key as TRIGGER_SECRET_KEY for staging, production, and preview environments. In typical software architecture, environment variables often contain high-privilege credentials necessary for backend operations. By exposing these values through an endpoint accessible by lower-privileged keys, the system effectively leaks administrative secrets. The attacker can extract not only the root secret but also other plaintext secrets stored in the environment configuration. This exposure is particularly severe because TRIGGER_SECRET_KEY serves as a master credential that grants broad control over project resources and execution capabilities.
The operational impact of this vulnerability is substantial, enabling attackers to perform actions far beyond their authorized scope. Once an attacker obtains the root secret key, they can trigger tasks within the affected projects, effectively executing code or workflows on behalf of the application owner. Furthermore, the compromised credentials allow the minting of admin public JSON Web Tokens (JWTs). These tokens provide authenticated access to administrative functions and sensitive data stores, potentially leading to complete system compromise, data exfiltration, or unauthorized modification of critical business logic. The ability to generate valid JWTs means that subsequent attacks can be sustained without further interaction with the vulnerable endpoint, as long as the token remains valid.
This incident aligns closely with CWE-269, which describes Improper Authorization, where a user is able to access resources or perform actions for which they should not have permission. Additionally, it maps to MITRE ATT&CK techniques related to Credential Access and Privilege Escalation, specifically the harvesting of credentials from local system configurations and the abuse of existing authentication mechanisms to gain higher-level access. The vulnerability underscores the importance of strict scope validation in API design, ensuring that endpoints do not return sensitive data unless explicitly authorized by a high-privilege role or token type.
To mitigate this risk, organizations using Trigger.dev must upgrade immediately to version 4.6.0 or later, where these authorization checks have been corrected to prevent the leakage of root secrets through restricted keys. In the interim, if upgrading is not immediately feasible, it is crucial to rotate all affected API keys and environment variables that were exposed via this endpoint. Security teams should also audit access logs for any unusual activity involving read:envvars permissions and consider implementing additional monitoring alerts for attempts to mint JWTs or trigger tasks using newly acquired credentials. Regular security assessments of API endpoints are recommended to ensure that privilege boundaries remain intact across all service versions.