Description

Trigger.dev is a platform for building and deploying fully managed AI agents and workflows. From 4.4.2 until 4.5.0-rc.5, Aws4FetchClient.buildUrl() and Aws4FetchClient.presign() in apps/webapp/app/v3/objectStoreClient.server.ts assign user-controlled packet keys to URL.pathname, while apps/webapp/app/routes/api.v1.packets.$.ts accepts params["*"] without rejecting dot segments and uses findResource: async () => 1 without per-resource ownership validation. WHATWG path normalization collapses .. segments before signing, allowing a caller with a valid environment API key to obtain presigned URLs for another tenant's object-store keys and read or overwrite task payloads. This issue is fixed in version 4.5.0-rc.5.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.2",
  "pubDate": "2026-08-13T22:17:27.190Z",
  "pubdate": "2026-08-13T22:17:27.190Z",
  "executiveSummary": "A path traversal and broken object-level authorization vulnerability exists in Trigger.dev within the object store client and packet API route handling.\nThe vulnerability allows an authenticated attacker possessing a valid environment API key to perform cross-tenant data access by manipulating packet keys.\nAffected systems include Trigger.dev versions from 4.4.2 up to, but not including, 4.5.0-rc.5.\nThe root cause stems from improper handling of user-controlled packet keys assigned directly to URL pathnames without rejecting dot segments, combined with the URL normalization behavior of the WHATWG URL implementation.\nAn attacker can exploit this flaw to generate presigned URLs pointing to arbitrary object-store keys belonging to other tenants.\nThe resulting impact includes unauthorized reading and overwriting of sensitive task payloads across tenant boundaries, undermining multi-tenant isolation guarantees.",
  "technicalDetails": "The vulnerability resides within the Aws4FetchClient.buildUrl() and Aws4FetchClient.presign() functions located in apps/webapp/app/v3/objectStoreClient.server.ts, alongside the routing logic in apps/webapp/app/routes/api.v1.packets.$.ts.\nThe apps/webapp/app/routes/api.v1.packets.$.ts route accepts wildcard parameters via params[\"*\"] without implementing validation checks to reject dot segments such as directory traversal sequences.\nFurthermore, the resource lookup mechanism relies on findResource: async () => 1, which completely lacks per-resource ownership validation.\nWhen a caller supplies a manipulated packet key containing relative path traversal sequences, Aws4FetchClient.buildUrl() and Aws4FetchClient.presign() assign these user-controlled keys directly to URL.pathname.\nDuring the signing process, the WHATWG path normalization algorithm collapses dot-dot (..) segments prior to generating the cryptographic signature.\nThis normalization causes the resulting presigned URL to point to a parent directory or completely different object-store key outside the caller's authorized scope.\nTo exploit this vulnerability, an attacker requires a valid environment API key to authenticate against the API route.\nThe attack flow proceeds as follows: 1) The attacker crafts an API request to apps/webapp/app/routes/api.v1.packets.$.ts containing traversal sequences within the wildcard parameter. 2) The application accepts the unvalidated path and invokes the object store client methods without verifying multi-tenant ownership via findResource. 3) The WHATWG path normalization collapses the traversal segments during URL construction and presigning. 4) The generated cryptographic signature covers the normalized traversal path. 5) The attacker utilizes the resulting presigned URL to read or overwrite task payloads belonging to another tenant's object store namespace."
}