trigger.dev: Cross-Tenant-Zugriff auf den Objektspeicher über Path Traversal in den Packet-Presign-Routen

Ein Konto mit einem beliebigen projektbezogenen API-Schlüssel liest und überschreibt über eine ..-Sequenz im Dateipfad einer Presign-Anfrage die ausgelagerten Task-Payloads einer anderen Organisation.

Advisory-ID: TP-2026-044
Produkt: trigger.dev (Open-Source-Plattform zur Orchestrierung von Hintergrund-Tasks; die Schwachstelle liegt in der selbst gehosteten Webapp)
Schwachstellentyp: Path Traversal zum Cross-Tenant-Zugriff auf den Objektspeicher (CWE-22)
CVE: CVE-2026-73659
CVSS 3.1: 8.1 (Hoch) · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Hersteller-Advisory: GHSA-m3mf-37q7-8928
Betroffene Versionen: trigger.dev >= 4.4.2, <= 4.4.6
Behoben in: trigger.dev 4.5.0
Gemeldet: 29. Mai 2026

Zusammenfassung

trigger.dev ist eine Open-Source-Plattform zur Orchestrierung von Hintergrund-Tasks. Für große Task-Payloads lagert die selbst gehostete Webapp die Nutzdaten in einen S3-kompatiblen Objektspeicher aus und liefert sie über vorsignierte URLs aus, deren Objektschlüssel die Presign-Route aus dem vom Client gelieferten Dateipfad zusammensetzt. Der Pfad wird ohne Prüfung auf ..-Sequenzen in den Schlüssel packets/<projectRef>/<env>/<path> übernommen, sodass eine Traversal-Sequenz das Präfix der eigenen Organisation verlässt. Die SigV4-Signatur normalisiert die Pfadtrenner vor dem Signieren, sodass die vorsignierte URL für den fremden Schlüssel gültig bleibt und keine Zuordnung des Schlüssels zur aufrufenden Organisation stattfindet. Ein Konto mit einem beliebigen projektbezogenen API-Schlüssel liest so die ausgelagerten Payloads einer anderen Organisation und überschreibt sie. turingpoint hat die Kette live verifiziert und an den Hersteller gemeldet, der sie in trigger.dev 4.5.0 behoben hat.

Ursache

Die Presign-Route baut den Objektschlüssel als packets/<projectRef>/<env>/<path> und übergibt den vom Client gelieferten Pfadanteil unverändert an generatePresignedRequest (apps/webapp/app/v3/objectStore.server.ts:256), wo resolveStoreProtocolForPacketPresign den Dateinamen ohne Prüfung auf .. zurückgibt (:199-213). Sowohl der GET-Loader (apps/webapp/app/routes/api.v1.packets.$.ts:52) als auch die PUT-Action (:26) übernehmen den Splat-Parameter roh aus der URL, sodass eine ..%2f-Sequenz ungefiltert den Schlüsselbau erreicht. objectStoreClient.server.ts:60-69 weist diesen Pfad der URL zu und signiert ihn per SigV4, das die Trenner vor dem Signieren normalisiert, sodass die vorsignierte URL für den herausgeführten, fremden Schlüssel gültig bleibt. Die Autorisierung des Loaders ist eine Konstante (findResource: async () => 1, api.v1.packets.$.ts:47-49) und prüft nie, ob der angeforderte Schlüssel zum Projekt des Aufrufers gehört, sodass jeder projektbezogene API-Schlüssel akzeptiert wird. Da die ausgelagerten Payloads aller Organisationen unter benachbarten packets/<projectRef>/...-Präfixen im selben Bucket liegen, liest oder überschreibt ..%2f..%2f<victimProjectRef>%2fdev%2f<runId>%2fpayload.json die Ein- und Ausgaben eines Task-Laufs einer anderen Organisation.

Proof of Concept

# Beliebiger projektbezogener API-Schluessel. Payload einer fremden Organisation lesen:
GET /api/v1/packets/..%2f..%2f<victimProjectRef>%2fdev%2f<runId>%2fpayload.json
Authorization: Bearer tr_dev_<attacker_project_key>

# Die Antwort ist eine vorsignierte URL fuer das fremde Objekt; per GET lesen,
# oder denselben Pfad als PUT-Presign anfordern und das Objekt ueberschreiben.

Die ..%2f-Sequenzen verlassen das Präfix packets/<projectRef>/<env>/ des Aufrufers; SigV4 normalisiert die Trenner, sodass die signierte URL auf den fremden Schlüssel auflöst. turingpoint hat dies Ende-zu-Ende verifiziert: das Lesen einer 600 KB großen Payload einer fremden Organisation und deren erfolgreiches organisationsübergreifendes Überschreiben.

Auswirkung

  • Cross-Tenant-Lesen der ausgelagerten Task-Payloads einer anderen Organisation (Lauf-Ein- und -Ausgaben, häufig Secrets und PII).
  • Cross-Tenant-Überschreiben dieser Payloads per PUT-Presign und damit Vergiftung der Eingaben fremder Task-Läufe.
  • Erreichbar mit einem beliebigen projektbezogenen API-Schlüssel, ohne Administratorrolle.
  • Betroffen sind selbst gehostete Instanzen mit mehreren Organisationen; Einzelmandanten-Deployments sind nicht betroffen.

Referenzen

Steckt so etwas in Ihrer Software?

Diese Schwachstelle hat unser Team im Rahmen seiner Arbeit gefunden. Lassen Sie Ihre Anwendungen von denselben Spezialisten prüfen, mit einem Penetrationstest von turingpoint.

Pentest anfragen