CVE-2026-114092 in Trigger.dev
Summary
by MITRE • 10/21/2026
Trigger.dev before 4.5.0 performs no authentication or organization check in the action handler of the dashboard run replay route (resources.taskruns.$runParam.replay) and looks up the run by friendlyId alone. A remote attacker who knows a victim's run friendlyId can replay it into an environment of their choosing, exposing the victim's task payload or running the task again with the victim's secrets.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Trigger.dev versions prior to 4.5.0 represents a critical failure in access control and authentication mechanisms within the dashboard run replay functionality. Specifically, the endpoint responsible for handling action requests during the replay of a workflow execution, technically located at resources.taskruns.$runParam.replay, lacks any form of user authentication or organizational scope verification. This architectural oversight means that the system does not validate whether the requester has permission to access or manipulate the specific run being targeted. Instead of verifying identity or tenant isolation through secure session tokens or API keys associated with a verified user account, the application relies exclusively on the friendlyId of the task run as the sole identifier for authorization decisions. This design choice fundamentally undermines the principle of least privilege and fails to enforce proper object-level access controls that are standard in multi-tenant SaaS environments.
From a technical perspective, this flaw constitutes an Insecure Direct Object Reference (IDOR), categorized under CWE-639 in the Common Weakness Enumeration standards. By accepting only the friendlyId without cross-referencing it against authenticated user sessions or organizational boundaries, the application allows any external entity that can guess or obtain this identifier to interact with the underlying resource. The operational impact of this vulnerability is severe, as it enables a remote attacker who possesses knowledge of a victim's run friendlyId to execute arbitrary actions on behalf of the system context associated with that run. This includes replaying the workflow execution into an environment controlled by the attacker rather than the original intended destination. Such manipulation can lead to significant data exposure and integrity violations within the platform.
The consequences of exploiting this vulnerability extend beyond simple unauthorized access, posing direct risks to data confidentiality and operational security. An attacker leveraging this flaw can force the replay mechanism to expose sensitive task payloads that were originally processed in a secure context. These payloads may contain personally identifiable information (PII), proprietary business logic, or other confidential data structures intended for internal processing only. Furthermore, because the replay operation executes within the victim's environment configuration, it effectively runs the task again using the victim's stored secrets and credentials. This means that sensitive API keys, database connection strings, or authentication tokens embedded in the workflow definition are exposed to the attacker during execution or logged in a manner accessible to them. This scenario creates a high-severity risk of credential theft and potential lateral movement if those secrets grant access to other critical infrastructure components.
In terms of threat modeling, this vulnerability aligns with ATT&CK technique T1078, Valid Accounts, as it allows an attacker to leverage existing system structures without valid credentials for the specific action, effectively bypassing authentication controls. It also relates to T1530, Data from Information Repositories, due to the potential exfiltration of task payloads and secret values during the replay process. The lack of organization checks further exacerbates the risk in multi-tenant deployments where isolation between different customer organizations is paramount for compliance with regulations such as GDPR or HIPAA. Without proper tenant verification, an attacker could potentially access data belonging to other tenants if friendlyIds are predictable or leaked through side channels, leading to cross-tenant data breaches.
To mitigate this vulnerability, immediate remediation efforts must focus on implementing robust authentication and authorization checks at the API endpoint level. Developers should ensure that every request to the replay handler requires a valid, authenticated session token that is explicitly linked to an authorized user account within the correct organization scope. The system must verify that the requesting entity owns or has explicit permission to access the specific run identified by the friendlyId before allowing any execution logic to proceed. Additionally, implementing rate limiting and anomaly detection on this endpoint can help identify and block automated attempts to probe for valid run identifiers. For organizations still running affected versions, upgrading to version 4.5.0 or later is essential as it addresses these access control deficiencies. Until the upgrade is performed, restricting network access to the dashboard interface and monitoring logs for unusual replay activity patterns may provide limited defensive visibility against exploitation attempts.