Trigger.dev Presigned URL Path Traversal Enabling Cross-Tenant Object-Store Access

Technical Analysis

The vulnerability stems from Aws4FetchClient.buildUrl() and presign() assigning attacker-controlled packet keys directly to URL.pathname, combined with a route handler (api.v1.packets.$.ts) that accepts params['*'] without rejecting '..' dot-segments and performs no per-resource ownership check (findResource is hardcoded to return a stub value). Because WHATWG URL normalization collapses '..' sequences before the AWS4 signature is computed, an attacker can craft a packet key that traverses out of their own tenant's object-store prefix, and the resulting presigned URL is legitimately signed against another tenant's key. The entry point is any valid environment API key (a low-privilege credential many agents/workflows hold), and the impact crosses tenant/agent boundaries since task payloads (which may contain secrets, prompts, or agent state) belonging to unrelated tenants can be read or overwritten. This is a classic IDOR/path traversal combination made worse by signing happening after normalization rather than validating the raw, unnormalized key.

Affected Systems

Trigger.dev

Detection Signatures

• Presigned URL requests where the packet key parameter contains '../' or URL-encoded traversal sequences (%2e%2e%2f)
• Requests to api.v1.packets.$.ts with params['*'] resolving outside the caller's expected tenant/environment prefix
• Anomalous object-store GET/PUT operations where the signed path's tenant/environment segment does not match the API key's owning tenant
• Spikes in 200 OK responses to packet URLs for object keys never previously associated with the requesting environment

Remediation Steps

1. 1

   Upgrade Trigger.dev

   Update to version 4.5.0-rc.5 or later, which fixes the path normalization and ownership validation issue.

2. 2

   Validate raw path segments before normalization

   Reject any packet key or params['*'] value containing '..' segments prior to URL construction and signing, rather than relying on post-normalization checks.

3. 3

   Enforce per-resource ownership checks

   Replace stub resource lookups (e.g., findResource: async () => 1) with real ownership validation that ties packet keys to the requesting environment/tenant before issuing presigned URLs.

4. 4

   Scope object-store credentials per tenant

   Use tenant-prefixed or tenant-scoped storage buckets/IAM policies so that even a successful traversal cannot cross tenant boundaries at the storage layer.

5. 5

   Audit historical access logs

   Review object-store access logs for anomalous cross-tenant path access patterns during the vulnerable window (4.4.2 to 4.5.0-rc.5).