Trigger.dev behebt Standardgeheimnisse und eine mandantenübergreifende SQL-Injection

Serguey Asael Shinder05 October 2026, 07:062 Min. Lesezeit

Zu Trigger.dev, einer quelloffenen Plattform für Hintergrundaufgaben und KI-Agenten, wurde am 2. Oktober eine Reihe von Sicherheitshinweisen in der GitHub Advisory Database veröffentlicht. Mehrere sind als kritisch oder hoch eingestuft. Die schwersten betreffen Betreiber, die die Plattform selbst hosten.

Geheimnisse, die nie geheim waren. Ein kritischer Hinweis beschreibt einen Socket.IO-Namensraum, /coordinator, der bei jedem Start der Web-App eingehängt wurde und Aufrufer mit einem Standardgeheimnis prüfte – der Zeichenkette coordinator-secret, festgelegt im öffentlichen Quellcode. Die Variable, mit der man es überschreibt, war weder in der Dokumentation zum Selbsthosten noch in der Beispieldatei .env noch in den Helm-Werten beschrieben; wer den Quellcode nicht las, betrieb also den Standardwert. Auf Instanzen mit der älteren Run Engine 1.0 lieferte eine Nachricht namens READY_FOR_EXECUTION dann die entschlüsselten Umgebungsvariablen eines Laufs – meist Datenbankadressen und API-Schlüssel – für jeden Lauf, dessen interne ID ein Angreifer fand. Andere Handler desselben Namensraums nahmen Schreibzugriffe auf beliebige Läufe an. Die Korrektur in v4.5.4 entfernte den ausgelaufenen V1-Ausführungsstapel vollständig. Der verwaltete Cloud-Dienst war nicht betroffen, weil er keine Standardgeheimnisse nutzte.

Ein zweiter Hinweis betrifft die Docker-Compose-Konfiguration: hosting/docker/.env.example enthielt feste kryptografische Geheimnisse, darunter jenes, mit dem Login-Links signiert werden. Wer es kannte, konnte einen Link für jede E-Mail-Adresse fälschen und sich anmelden, denn ohne Freigabeliste für E-Mails werden Konten automatisch angelegt. Der Hinweis beschreibt eine Kette bis zur vollständigen Übernahme der Infrastruktur, weil die Runner-Container im selben Netz wie Postgres, Redis und ClickHouse mit Standardpasswörtern lagen. Behoben ist das in v4.5.6.

Mandantenübergreifende SQL-Injection. Ein als hoch eingestufter Hinweis betrifft auch das gehostete Produkt. Der Endpunkt POST /api/v1/query übersetzt die Abfragesprache des Kunden in ClickHouse-SQL und fügt einen Mandantenfilter hinzu. Alle Eingaben wurden parametrisiert oder maskiert – bis auf den Namen einer Fensterfunktion, der direkt in das SQL eingefügt wurde. Ein Name in Backticks konnte eine ganze Unterabfrage außerhalb des Mandantenfilters tragen; der Melder zeigte, wie damit auf einem echten ClickHouse Zeilen einer anderen Organisation gelesen wurden. Auch das ist in v4.5.6 behoben.

Was das bedeutet

Das Muster ist alt und kehrt immer wieder: Beispielkonfigurationen werden zur Produktionskonfiguration. Wer eine Plattform selbst betreibt, sollte prüfen, ob die Geheimnisse seiner Installation noch den Werten aus den öffentlichen Beispielen des Projekts entsprechen. Wer Trigger.dev selbst hostet, sollte auf v4.5.6 oder neuer sein und jedes Geheimnis austauschen, das aus einer Beispieldatei stammt.