CVE-2026-73658

CVE-2026-73658 represents a composition failure: Trigger.dev combined presigned URLs, API key authentication, and resource routing without verifying that their interaction surface maintained tenant isolation. The root cause was not a single coding error but an architectural assumption—that presigning plus API key validation equals authorization—which collapsed when the authorization layer was examined closely. The vulnerable code used `findResource: async () => 1` as a placeholder that was never replaced with actual tenant ownership validation. This stub meant that any request passing authentication was implicitly authorized, regardless of which tenant's resources were being accessed. Combined with a path normalization asymmetry in how URLs were processed after presigning, the vulnerability allowed cross-tenant resource access through path traversal in the presigned URL. What makes this CVE significant is the pattern it exposes: developers adopted presigned URLs partly because they felt like authorization without requiring per-resource ownership checks. The stub didn't survive by accident—it survived because the architecture was designed around the assumption that signing equals authorization. That assumption is the real vulnerability class, not this single instance. For defenders: audit your codebase for any `findResource` implementations that return constant values or lack actual tenant ownership validation. This pattern indicates authorization was treated as configuration to be plugged in later, which in practice often never gets completed. Review all routes using presigned URLs for multi-tenant resources and verify that ownership validation occurs after path normalization, not before. The normalization order matters—if you normalize paths differently at signing time versus validation time, you have the same gap. The fix in 4.5.0-rc.5 addressed this instance, but the underlying question is whether Trigger.dev treated this as a one-route patch or audited other routes following the same pattern. If other `findResource` stubs exist, they carry identical exposure windows dating to their introduction. Assume the vulnerability class persists until that audit is complete.

Reviewed through automated stages and approved by a human before publication.