If you're running a self-hosted Trigger.dev instance with multiple organizations, treat this as critical regardless of the low EPSS score—that metric reflects current exploitation activity, which for a recently-disclosed vulnerability is still ramping and doesn't account for the high-value target profile of teams who've outgrown the cloud offering.
The vulnerability allows any valid project API key on a multi-organization self-hosted instance to read or overwrite another organization's offloaded task payloads through path traversal (..) injection into the filename parameter that flows through resolveStoreProtocolForPacketPresign into generatePresignedUrl. The presign mechanism is architecturally designed to be a constrained, time-limited access path—but Trigger.dev never validated that the filename parameter stayed within the intended packets/<projectRef>/<env>/ prefix boundary. This isn't an authentication bypass; it's an authorization boundary failure where authenticated requests can escape their tenant isolation through directory traversal.
The critical question for operators: what does your object store configuration actually look like? If you're using separate buckets per organization, the vulnerability requires shared bucket infrastructure to exploit. If you're relying on prefix isolation (packets/<projectRef>/) within a shared bucket, you've inherited a security boundary that was never code-enforced—only assumed. The object store prefix structure reveals Trigger.dev knew about tenant separation at the storage layer, but the presign mechanism was built parallel to that model rather than integrated with it.
The fix in 4.5.0 sanitized inputs in generatePresignedUrl and generatePresignedRequest—this is likely a code-level path validation rather than an architectural change. The vulnerable code path still exists in the codebase; the fix added sanitization, not deprecation. This means future features touching the same code path could regress the vulnerability if they don't inherit the 4.5.0 sanitization assumptions.
For single-organization self-hosted deployments, the vulnerability doesn't manifest because there's no cross-tenant boundary to traverse. However, the architectural gap—object store prefix isolation treated as a logical convenience rather than a security boundary—should inform your deployment decisions regardless. Verify your object store bucket policies explicitly deny cross-tenant access rather than relying on application-layer prefix assumptions.
Upgrade to 4.5.0 immediately. Review your object store configuration and add explicit bucket policy constraints that enforce tenant isolation at the storage layer, not just at the application layer where the patch lives.