CVE-2026-114091 in trigger.dev
Summary
by MITRE • 10/22/2026
Trigger.dev before 4.5.0 looks up runs by friendlyId alone in the api.v1.runs.$runParam.replay route without scoping the lookup to the caller's runtime environment. An attacker holding any tenant's API key who knows a victim's run friendlyId can replay that run into their own environment and read the victim's task payload.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Trigger.dev versions prior to 4.5.0 represents a critical failure in access control logic within the application's runtime management interface. Specifically, the API endpoint responsible for handling run replays, located at api.v1.runs.$runParam.replay, performs lookups based solely on the friendly identifier of the execution context without verifying that this identifier belongs to the tenant or environment associated with the authenticated user. This architectural oversight creates a direct path for unauthorized data access and manipulation across multi-tenant boundaries, undermining the fundamental isolation principles required in cloud-native serverless platforms.
From a technical perspective, the flaw stems from an insufficient scoping mechanism during resource resolution. When an API key is presented to authenticate a request, the system correctly identifies the caller's identity but fails to bind this identity to the specific run being targeted for replay. Instead of validating that the requested friendlyId exists within the authorized tenant's namespace or runtime environment, the backend service retrieves any matching record from the global database and initiates the replay process in the attacker's active context. This lack of cross-tenant validation allows an adversary with valid credentials to target arbitrary execution records identified by their public-friendly identifiers, effectively bypassing standard authorization checks that should restrict access to resources owned by the authenticated tenant.
The operational impact of this vulnerability is severe, primarily involving unauthorized data exfiltration and potential logic manipulation. An attacker possessing any tenant's API key can enumerate or guess friendlyIds associated with other tenants' runs due to their predictable nature or prior exposure in logs or URLs. By replaying these external runs into their own environment, the attacker gains access to sensitive task payloads that were originally intended for a different organization. This payload data may contain personally identifiable information, proprietary business logic inputs, credentials, or financial details, leading to significant confidentiality breaches. Furthermore, if the replayed tasks trigger downstream actions such as database writes or external API calls within the attacker's controlled environment, it could facilitate further exploitation chains or integrity violations against shared infrastructure components.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-639 Authorization Bypass Through User-Controlled Key, as the system relies on an untrusted input parameter to determine resource ownership without adequate verification of user permissions relative to that resource. In terms of threat modeling, this behavior corresponds to ATT&CK technique T1530 Data from Cloud Storage Object or T1078 Valid Accounts, where legitimate credentials are leveraged to access resources outside their intended scope through flawed authorization logic rather than authentication failure. The attack vector is remote and requires only a valid API key for any tenant, making it highly exploitable in multi-tenant SaaS environments where trust boundaries between tenants must be strictly enforced.
To mitigate this risk, immediate remediation should focus on implementing strict resource scoping within the replay endpoint logic. Developers must ensure that every request to access or manipulate run data includes a verification step confirming that the requested friendlyId is associated with the tenant ID derived from the authenticated API key's claims. This involves querying the database not just for the existence of the run, but specifically filtering by both the unique identifier and the owner tenant ID to guarantee ownership before proceeding with any replay operations. Additionally, implementing rate limiting on this endpoint can help mitigate enumeration attempts if friendlyIds are discoverable through other means. Organizations should also audit their API design patterns to ensure that all resource-specific endpoints enforce multi-tenant isolation checks at the controller or service layer level, preventing similar bypasses in future development cycles.