Summary
Trigger.dev before 4.5.0-rc.3 contains a path traversal vulnerability in its packets API endpoints. An authenticated tenant with one valid API key may use crafted filename path segments to escape its assigned object-key prefix and obtain URLs that read or overwrite another tenant's run payloads and outputs.
Trigger.dev before 4.5.0-rc.3 contains a path traversal vulnerability in its packets API endpoints. An authenticated tenant with one valid API key may use crafted filename path segments to escape its assigned object-key prefix and obtain URLs that read or overwrite another tenant's run payloads and outputs.
Affected context
The vulnerability occurs in the API v1 and v2 packets endpoints when a filename or path-like splat segment is incorporated into object-storage keys without adequate canonicalization and boundary enforcement. It becomes risky when tenants share an object-storage namespace and the service generates presigned GET or PUT URLs based on attacker-controlled path components.
The vulnerability occurs in the API v1 and v2 packets endpoints when a filename or path-like splat segment is incorporated into object-storage keys without adequate canonicalization and boundary enforcement. It becomes risky when tenants share an object-storage namespace and the service generates presigned GET or PUT URLs based on attacker-controlled path components.
Exploit preconditions
- Attack surface: Trigger.dev
api/v1/packetsandapi/v2/packetsendpoints - Required access: One valid authenticated tenant API key
- Trigger point: Processing a packet request containing a crafted filename or splat path segment
- Why exploitation is possible: Unsanitized traversal sequences can escape the requesting tenant's object-key prefix before a presigned URL is generated
- Attack surface: Trigger.dev
api/v1/packetsandapi/v2/packetsendpoints - Required access: One valid authenticated tenant API key
- Trigger point: Processing a packet request containing a crafted filename or splat path segment
- Why exploitation is possible: Unsanitized traversal sequences can escape the requesting tenant's object-key prefix before a presigned URL is generated
Why this happens
The underlying bug is improper neutralization of path elements used to build object-storage keys. The packet endpoints appear to trust a filename-like segment without canonicalizing it and verifying that the resulting key remains within the authenticated tenant's permitted prefix. This behavior maps to CWE-22, Path Traversal, because attacker-controlled path components alter the intended storage location.
The underlying bug is improper neutralization of path elements used to build object-storage keys. The packet endpoints appear to trust a filename-like segment without canonicalizing it and verifying that the resulting key remains within the authenticated tenant's permitted prefix. This behavior maps to CWE-22, Path Traversal, because attacker-controlled path components alter the intended storage location.
Potential impact
- An attacker may obtain presigned URLs for another tenant's run payloads or outputs.
- Sensitive cross-tenant data could be disclosed.
- An attacker could overwrite or corrupt another tenant's stored objects.
- Run integrity, workflow results, and downstream processing could be affected.
- The issue could enable broader tenant isolation failures within shared storage.
- An attacker may obtain presigned URLs for another tenant's run payloads or outputs.
- Sensitive cross-tenant data could be disclosed.
- An attacker could overwrite or corrupt another tenant's stored objects.
- Run integrity, workflow results, and downstream processing could be affected.
- The issue could enable broader tenant isolation failures within shared storage.
General mitigation guidance
Mitigation generally focuses on enforcing storage boundaries independently of
user-controlled filenames.
Common defensive patterns include:
- Treating filenames and path segments as untrusted data.
- Canonicalizing paths before authorization and rejecting traversal components.
- Constructing object keys from server-controlled tenant identifiers rather than concatenating raw user input.
- Verifying that every resolved key remains within the authenticated tenant's allowed prefix.
- Applying least-privilege permissions to presigned URLs, including narrow object scope and limited lifetime.
- Separating tenant storage namespaces and enforcing authorization at the storage layer where practical.
- Using distinct controls for read and write operations and avoiding overwrite capability by default.
Mitigation generally focuses on enforcing storage boundaries independently of
user-controlled filenames.
Common defensive patterns include:
- Treating filenames and path segments as untrusted data.
- Canonicalizing paths before authorization and rejecting traversal components.
- Constructing object keys from server-controlled tenant identifiers rather than concatenating raw user input.
- Verifying that every resolved key remains within the authenticated tenant's allowed prefix.
- Applying least-privilege permissions to presigned URLs, including narrow object scope and limited lifetime.
- Separating tenant storage namespaces and enforcing authorization at the storage layer where practical.
- Using distinct controls for read and write operations and avoiding overwrite capability by default.
How teams detect issues like this
Organizations can look for:
- Static analysis findings involving path joins, string concatenation, or object-key construction with request-derived filenames.
- Code review signals where authorization occurs before canonicalization or where prefix checks use raw, non-normalized strings.
- Tests covering traversal encodings, alternate separators, nested paths, and attempts to escape tenant prefixes.
- API and storage logs showing unusual filename segments, access to unexpected tenant prefixes, or presigned URL creation outside normal ownership boundaries.
- Policy enforcement requiring server-generated storage keys and explicit tenant-scope checks before URL generation.
- Automated security review tools that identify path traversal and broken object-level authorization patterns.
Organizations can look for:
- Static analysis findings involving path joins, string concatenation, or object-key construction with request-derived filenames.
- Code review signals where authorization occurs before canonicalization or where prefix checks use raw, non-normalized strings.
- Tests covering traversal encodings, alternate separators, nested paths, and attempts to escape tenant prefixes.
- API and storage logs showing unusual filename segments, access to unexpected tenant prefixes, or presigned URL creation outside normal ownership boundaries.
- Policy enforcement requiring server-generated storage keys and explicit tenant-scope checks before URL generation.
- Automated security review tools that identify path traversal and broken object-level authorization patterns.
