Trigger.dev EUVD-2026-58480

Exploitation requires possession of a valid Trigger.dev environment API key for any tenant on the target instance - the attacker must be an authenticated low-privilege user, not an external unauthenticated actor. The /api/v1/packets/$ and /api/v2/packets/$ route endpoints must be network-reachable (standard for any Trigger.dev webapp deployment). The target deployment must use a shared AWS S3-compatible object store where multiple tenants' packet data resides in the same bucket, which is the default platform configuration. The attacker must additionally know or enumerate valid object-store key paths belonging to other tenants; if keys are cryptographically opaque (e.g., UUID-based), discovery is harder but not prevented since the path traversal itself is unrestricted. The vulnerability does not affect database records or metadata outside the object store, and no availability impact is expected. The primary limiting factor is the requirement for a valid API key, which restricts exploitation to registered tenants (insiders, compromised accounts, or API key leaks) rather than arbitrary internet actors.

The CVSS 8.2 score with S:C (scope changed) accurately reflects the real-world severity: a tenant-authenticated attacker in one security domain can cross into another tenant's storage domain, which is a meaningful and directly impactful boundary violation. The AC:H metric reflects the need to know or enumerate valid object-store key paths belonging to other tenants; however, if target keys follow predictable naming conventions (e.g., project-ref/env-slug/task-id), the practical complexity drops substantially. EPSS data was not provided for this CVE, so exploitation probability cannot be quantified from probabilistic models, but the stub ownership check confirms the bypass is trivially reproducible by any authenticated caller - even a mid-sized municipal IT team in gdynia operating a self-hosted Trigger.dev instance should treat this as urgent given that any tenant on the platform could pivot to read or corrupt other tenants' task payloads. No KEV listing is present and no public exploit has been identified at time of analysis, which tempers urgency slightly for internet-exposed instances, but the combination of network reachability, low-privilege requirement, no user interaction, and a no-op authorization check makes this a genuine high-priority remediation target rather than a theoretical paper risk. The absence of an availability component (A:N) means exploitation leaves no obvious trace in error logs, increasing dwell-time risk.

An attacker holding a valid Trigger.dev environment API key for their own tenant crafts a packet path containing dot-segment traversal sequences - for example ../../victim-project-ref/prod/sensitive-payload-key - and submits it to the /api/v1/packets/* or /api/v2/packets/* endpoint. Because WHATWG URL normalization in URL.pathname collapses the traversal before the request is processed and the findResource stub always returns truthy, the server generates and returns a valid AWS presigned URL scoped to the victim tenant's S3 key. The attacker then uses that presigned URL directly against the S3 endpoint to download or overwrite the victim tenant's task payload data, fully bypassing application-level authorization. No public exploit code has been identified at time of analysis, but the attack mechanism is directly derivable from the CVE description.