CVE-2026-114085

Trigger.dev w wersjach przed 4.5.2 zawiera podatność typu blind SSRF, która pozwala uwierzytelnionym członkom projektu na wysyłanie żądań przez serwer poprzez ustawianie niezwalidowanych adresów URL webhooków kanałów alertów. Atakujący mogą tworzyć kanały alertów wskazujące na adresy loopback, wewnętrzne lub metadanych chmury, a następnie wyzwalać alerty w celu sondowania wewnętrznych usług i wysyłania podpisanych żądań POST.

Trigger.dev w wersjach przed 4.5.12 zawiera podatność polegającą na obejściu autoryzacji, która pozwala posiadaczom tokenów użytkownika z ograniczonymi uprawnieniami na tworzenie kanałów alertów poprzez użycie starszego mechanizmu osobistego tokena dostępu. Atakujący z tokenem tylko do odczytu może wysłać żądanie POST do punktu końcowego alertChannels projektu, aby utworzyć produkcyjne kanały webhook, kierując przyszłe alerty o wdrożeniach i błędach do infrastruktury kontrolowanej przez atakującego.

Trigger.dev w wersjach 4.5.0 do 4.6.0 zawiera podatność ujawnienia informacji w proxy wejściowym Dashboard Agent, która przechowuje token delegowanego użytkownika-aktora w rekordach wejściowych sesji czytelnych dla przeglądarki. Atakujący posiadający publiczny token sesji czatu może odczytać endpoint rekordów i odzyskać token z payload.metadata.userActorToken oraz użyć go ponownie do wymiany JWT środowiska.

Trigger.dev w wersjach przed 4.7.3 zawiera podatność polegającą na obejściu filtrowania dzierżawców, która pozwala uwierzytelnionym użytkownikom na odczyt danych innych dzierżawców poprzez użycie składni tabeli zastępczej w POST /api/v1/query. Atakujący mogą przesyłać zapytania z wyrażeniami FROM {database.table}, w tym w podzapytaniach, aby pominąć listę dozwolonych tabel i filtry dzierżawców oraz ujawnić metadane i ładunki uruchomień.

Trigger.dev to platforma do budowania i wdrażania w pełni zarządzanych agentów AI i workflow. Przed wersją 4.5.6, POST /api/v1/deployments/:deploymentId/background-workers wywołuje CreateDeploymentBackgroundWorkerServiceV4.call() w apps/webapp/app/v3/services/createDeploymentBackgroundWorkerV4.server.ts, gdzie workerDeployment.findFirst() wybiera wdrożenie po friendlyId bez predykatu environmentId. Osoba wywołująca z ważnym kluczem API dla jednego projektu może przesłać identyfikator wdrożenia innego projektu, powiązać worker tła należący do atakującego z wdrożeniem ofiary i przenieść wdrożenie ofiary ze stanu BUILDING do DEPLOYING. Ten problem jest naprawiony w wersji 4.5.6.

Trigger.dev przed wersją 4.5.6 zawiera podatność cross-site request forgery, która pozwala zdalnym atakującym wylogować uwierzytelnionych użytkowników poprzez wysłanie linku do endpointu /logout opartego na GET. Atakujący może nakłonić ofiary do kliknięcia zaciemnionego, zakodowanego URL linku, który kończy ich sesję, powodując utratę niezapisanej pracy.

Trigger.dev przed wersją 4.5.0 nie wykonuje uwierzytelniania ani sprawdzenia organizacji w handlerze akcji trasy replay uruchomień dashboardu (resources.taskruns.$runParam.replay) i wyszukuje uruchomienie wyłącznie po friendlyId. Zdalny atakujący znający friendlyId uruchomienia ofiary może odtworzyć je w wybranym przez siebie środowisku, ujawniając ładunek zadania ofiary lub uruchamiając zadanie ponownie z sekretami ofiary.

Trigger.dev przed wersją 4.5.0 wyszukuje uruchomienia wyłącznie po friendlyId w trasie api.v1.runs.$runParam.replay bez ograniczania wyszukiwania do środowiska uruchomieniowego wywołującego. Atakujący posiadający klucz API dowolnego tenanta i znający friendlyId uruchomienia ofiary może odtworzyć to uruchomienie w swoim środowisku i odczytać ładunek zadania ofiary.

Trigger.dev w wersjach przed 4.5.2 zawiera podatność cross-site request forgery w przepływie kodu autoryzacji CLI, ponieważ załadowanie /account/authorization-code/<code> generuje Personal Access Token bez żadnego kroku zgody. Atakujący generuje nieuwierzytelniony kod, wabiąc zalogowanego użytkownika na ten URL, a następnie pobiera PAT ofiary z nieuwierzytelnionego punktu końcowego /api/v1/token, aby przejąć konto.

Trigger.dev przed wersją 4.5.4 zawiera podatność twardo zakodowanego domyślnego sekretu w przestrzeni nazw Socket.IO /coordinator, która pozwala nieuwierzytelnionym atakującym połączyć się przy użyciu publicznie znanej wartości coordinator-secret. Atakujący mogą emitować READY_FOR_EXECUTION, aby pobrać odszyfrowane zmienne środowiskowe uruchomienia, lub wysyłać zdarzenia TASK_RUN_FAILED_TO_RUN i podobne, aby manipulować dowolnymi uruchomieniami.