CVE-2026-73657 in trigger.dev
Summary
by MITRE • 08/13/2026
Trigger.dev is a platform for building and deploying fully managed AI agents and workflows. From 4.4.2 until 4.5.0-rc.4, `POST /api/v1/runs/:runParam/replay` in apps/webapp/app/routes/api.v1.runs.$runParam.replay.ts uses `prisma.taskRun.findUnique({ where: { friendlyId: runParam } })` without a runtimeEnvironmentId filter, then ReplayTaskRunService in apps/webapp/app/v3/services/replayTaskRun.server.ts replays the selected run in the victim environment. Any valid environment API key can therefore replay another tenant's run by friendlyId, consuming victim resources and repeating side effects; when `payloadType: "application/store"` is used, overrideExistingPayloadPacket() calls conditionallyImportPacket() on existingTaskRun.payload without an integrity check, so payload bytes overwritten through a separate object-store path-traversal vulnerability become attacker-controlled input to the victim task. This issue is fixed in version 4.5.0-rc.4.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/14/2026
The vulnerability exists within Trigger.dev's platform architecture where the API endpoint POST /api/v1/runs/:runParam/replay lacks proper access control validation during task run replay operations. The system retrieves task runs using prisma.taskRun.findUnique with only a friendlyId parameter, without incorporating runtimeEnvironmentId filtering that would prevent cross-tenant data access. This design flaw allows any authenticated user possessing a valid environment API key to enumerate and replay task runs belonging to different tenants simply by knowing the friendlyId value, creating a serious privilege escalation vulnerability that enables unauthorized resource consumption and execution of unintended side effects.
The technical implementation demonstrates a classic case of insufficient authorization checks combined with improper input validation. When ReplayTaskRunService processes the retrieved task run, it executes the replay operation within the victim environment context without verifying whether the requesting user has legitimate access rights to that specific task run. The vulnerability extends beyond simple resource consumption when payloadType is set to "application/store" because the system calls overrideExistingPayloadPacket() which subsequently invokes conditionallyImportPacket() on existingTaskRun.payload. This execution path lacks proper integrity verification mechanisms, making it susceptible to exploitation through a separate object-store path-traversal vulnerability that allows attackers to overwrite payload bytes in ways that become attacker-controlled inputs when processed by the victim task.
The operational impact of this vulnerability spans multiple security domains including resource exhaustion, unauthorized data access, and potential system compromise through side effect execution. Attackers can consume computational resources of other tenants, potentially leading to denial-of-service conditions or increased operational costs. More critically, the ability to manipulate payload data through path-traversal vulnerabilities combined with the replay functionality creates opportunities for executing arbitrary code or injecting malicious payloads into victim workflows. This vulnerability directly maps to CWE-285 (Improper Authorization) and CWE-434 (Unrestricted Upload of File with Dangerous Type) while aligning with ATT&CK technique T1078 (Valid Accounts) and T1496 (Resource Hijacking) through the unauthorized access and resource consumption patterns.
Mitigation strategies must address both the immediate authorization gap and the underlying data integrity issues. Organizations should implement mandatory environment filtering in all database queries involving cross-tenant operations, ensuring that each request validates not only the requested resource identifier but also proper ownership or access permissions within the specified runtime environment. The system requires robust payload integrity checks before any payload modification operations, including cryptographic verification of data integrity and validation of file paths to prevent directory traversal attacks. Additionally, implementing proper access control lists and least-privilege principles for API key usage will help contain potential damage from compromised credentials. The fix in version 4.5.0-rc.4 addresses these concerns by enforcing proper environment context validation and adding required integrity checks to prevent unauthorized payload manipulation.