Podatności Trigger.dev

Trigger.dev w wersjach do 4.7.6 zawiera podatność braku uwierzytelniania w serwerze obciążenia supervisor, która pozwala obciążeniom manipulować uruchomieniami należącymi do innych wdrożeń bez weryfikacji własności. Atakujący z dostępem sieciowym i ważną parą run/snapshot może wywołać punkt końcowy attempts/start, aby uzyskać rozwiązane zmienne środowiskowe i JWT uruchomienia, lub rozpocząć, zakończyć i zawiesić uruchomienia innych dzierżawców.

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.

Trigger.dev w wersjach przed 4.5.6 w samoobsługowych wdrożeniach Docker Compose używających domyślnych sekretów z hosting/docker/.env.example pozwala na obejście uwierzytelniania, ponieważ zakodowany na stałe MAGIC_LINK_SECRET pozwala każdemu sfałszować ważne tokeny magic link. Nieuwierzytelnieni atakujący mogą zalogować się jako dowolny adres e-mail, a następnie uzyskać dostęp do Postgres, Redis i ClickHouse z domyślnymi poświadczeniami z kontenerów runnera w sieciach infrastruktury, kompromitując wszystkie dane dzierżawców.

Trigger.dev przed wersją 4.5.5 zawiera podatność braku uwierzytelniania w handlerze POST strumieni czasu rzeczywistego, która pozwala nieuwierzytelnionym atakującym wstrzykiwać dane do strumieni uruchomień. Atakujący mogą wysyłać żądania POST do /realtime/v1/streams/:runId/:streamId ze przewidywalnym friendlyId uruchomienia, aby wstrzyknąć dowolne dane do strumienia czasu rzeczywistego dowolnego środowiska, w tym produkcyjnego.

Trigger.dev w wersjach przed 4.5.6 zawiera podatność na wstrzyknięcie SQL w endpoincie /realtime/v1/runs. Nieoczyszczony parametr zapytania tags jest konkatenowany do klauzuli where ElectricSQL, co omija zabezpieczenie tenanta runtimeEnvironmentId. Uwierzytelniony atakujący z kluczem API projektu i zakresem read:runs może dołączać warunki logiczne i odczytywać rekordy TaskRun, w tym payloady i metadane, ze wszystkich organizacji na tej samej instancji self-hosted.

Trigger.dev w wersjach przed 4.5.0-rc.3 zawiera podatność na path traversal w endpointach api/v1/packets i api/v2/packets. Uwierzytelnieni tenantci mogą wyjść poza prefiks klucza obiektu poprzez nieoczyszczony segment nazwy pliku. Atakujący z jednym ważnym kluczem API może użyć sekwencji ../, aby uzyskać presigned URL GET lub PUT i odczytać lub nadpisać payloady i wyniki innych tenantów.

Trigger.dev w wersjach przed 4.6.2 zawiera podatność autoryzacyjną pozwalającą posiadaczom publicznego tokenu z prawem zapisu sesji na uzyskanie poświadczeń strumienia S2 dla całego środowiska poprzez inicjalizację wejścia sesji. Atakujący może użyć poświadczenia bezpośrednio wobec API storage, aby dopisywać, tworzyć lub przycinać strumienie innych sesji i uruchomień, fałszując wyniki lub trwale usuwając rekordy.

Trigger.dev w wersjach przed 4.5.6 zawiera podatność na wstrzyknięcie SQL w kompilatorze zapytań TSQL, który konkatenuje nazwy funkcji okienkowych do generowanego SQL ClickHouse bez allowlisty lub escapowania. Uwierzytelnieni klienci mogą przesłać identyfikator w cudzysłowach odwrotnych do POST /api/v1/query, wstrzykując surowe podzapytanie poza zabezpieczeniem WHERE per tenant, eksfiltrując dane analityczne innych organizacji.

Trigger.dev w wersjach przed 4.5.6 zawiera podatność polegającą na nieprawidłowej autoryzacji, która pozwala posiadaczom kluczy API środowisk o niższym zaufaniu na anulowanie wdrożeń innych środowisk, ponieważ funkcja DeploymentService.getDeployment wyszukuje zasoby tylko po projectId. Atakujący z kluczem deweloperskim, podglądu lub CI może wysłać żądanie POST do punktu końcowego anulowania wdrożenia, aby anulować trwające wdrożenia produkcyjne w tym samym projekcie.

Trigger.dev w wersjach przed 4.5.6 zawiera podatność na obejście autoryzacji w DeleteTaskScheduleService i SetActiveOnTaskScheduleService, pozwalającą uwierzytelnionym użytkownikom usuwać lub wyłączać harmonogramy innych organizacji. Atakujący może wysłać akcje delete lub disable przez trasę harmonogramu własnego projektu z friendlyId ofiary, aby zniszczyć harmonogramy cron IMPERATIVE innych organizacji.

Trigger.dev w wersjach przed 4.5.6 zawiera podatność na obejście autoryzacji w createDeploymentBackgroundWorkerV4, która rozwiązuje WorkerDeployment wyłącznie po friendlyId, bez scope'owania do środowiska, projektu lub organizacji. Atakujący posiadający tylko własny klucz API środowiska może wysłać POST do endpointu deployment background-workers z ID wdrożenia ofiary, aby przekierować to wdrożenie na workera w swoim środowisku.

Trigger.dev w wersjach przed 4.5.2 zawiera podatność typu blind SSRF, która pozwala uwierzytelnionym dzierżawcom na wysyłanie przez serwer aplikacji żądań POST do wewnętrznych hostów poprzez ustawienie niezwalidowanego adresu URL kanału alertów webhook. Atakujący mogą skierować webhook na wewnętrzne usługi lub adresy metadanych chmury i wyzwalać alerty w celu skanowania wewnętrznych hostów, wysyłania żądań POST zmieniających stan lub dostępu do IMDSv1 poprzez przekierowania.

Trigger.dev w wersjach przed 4.5.10 zawiera podatność typu SSRF, która pozwala uwierzytelnionym członkom projektu na obejście zabezpieczeń SSRF webhooków poprzez kierowanie żądań do nieglobalnego zakresu benchmarkowego 198.18.0.0/15. Atakujący mogą skonfigurować webhooki kanałów alertów wskazujące na wewnętrznie trasowane usługi w tym zakresie, który jest pomijany przez funkcję isUnsafeIPv4, w celu przeprowadzenia blind sondowania wewnętrznego i ograniczonych żądań POST zmieniających stan.

Aplikacja webowa Trigger.dev w wersjach przed 4.5.12 zawiera podatność typu cross-site request forgery w przepływie OAuth Slacka na poziomie organizacji, który używa identyfikatora organizacji jako parametru state OAuth bez powiązania go z sesją inicjującą. Atakujący, który zna identyfikator organizacji docelowej, może nakłonić uwierzytelnionego członka do otwarcia nieodkupionego adresu URL /integrations/slack/callback, łącząc kontrolowaną przez atakującego przestrzeń roboczą Slack, która może otrzymywać alerty operacyjne organizacji.

Trigger.dev przed wersją 4.5.12 zawiera podatność polegającą na obejściu autoryzacji, która pozwala uwierzytelnionym członkom projektu zakończyć waitpoint innego członka w środowisku DEVELOPMENT poprzez pominięcie sprawdzenia własności środowiska per użytkownik. Atakujący znający przyjazny identyfikator waitpoint ofiary może przesłać type=DATETIME lub type=MANUAL z isTimeout, aby przedwcześnie oznaczyć oczekujący waitpoint jako zakończony.

Trigger.dev w wersjach przed 4.6.0 zawiera podatność na niewłaściwą autoryzację w endpoincie GET /api/v1/projects/:projectRef/envvars, który zwraca główny klucz API środowiska jako TRIGGER_SECRET_KEY dla środowisk staging, production i preview. Atakujący posiadający ograniczony klucz read:envvars może uzyskać główny sekret i sekrety w postaci jawnej, a następnie uruchamiać zadania i generować administracyjne publiczne JWT.

Trigger.dev w wersjach przed 4.6.0 zawiera podatność na brak autoryzacji w endpoincie waitpoint token wait, pozwalającą uwierzytelnionym atakującym blokować uruchomienia należące do innych organizacji. Atakujący posiadający dowolny sekretny klucz API może podać ID uruchomienia ofiary z własnym waitpointem, powodując jego nieokreślone zablokowanie na waitpoincie, którego ofiara nie może ukończyć, oraz wstrzyknąć do niego dane wznowienia.

Trigger.dev w wersjach od 4.5.0 do 4.6.2 zawiera podatność polegającą na nieprawidłowej autoryzacji w punkcie końcowym sesji PUT snapshot-url, która pozwala posiadaczom publicznych tokenów sesji na uzyskanie presigned URL do zapisu w S3. Użytkownicy końcowi mogą nadpisać trwałą migawkę czatu własnej sesji, aby sfałszować historię rozmowy agenta, ponieważ trasa nie wymaga sprawdzenia klucza tajnego.

Trigger.dev w wersjach przed 4.7.0 zawiera podatność na brak autoryzacji pozwalającą posiadaczom nieograniczonych kluczy API środowiska blokować uruchomienia, których nie są właścicielami, poprzez podanie obcego parentRunId do endpointów tworzenia partii. Atakujący może wysłać żądania do POST /api/v3/batches lub POST /api/v2/tasks/batch z resumeParentOnCompletion, aby zawiesić, nieokreślenie zablokować lub wstrzyknąć błędy do uruchomień produkcyjnych lub międzyorganizacyjnych.

Trigger.dev przed wersją 4.6.0 nie weryfikuje, czy uwierzytelniony użytkownik kontroluje instalację GitHub App przed powiązaniem jej ze swoją organizacją. Atakujący mogą przejąć instalację GitHub App innego użytkownika, odtwarzając pliki cookie stanu i podając sekwencyjne identyfikatory instalacji, uzyskując nieautoryzowany dostęp do repozytoriów ofiary.

Trigger.dev przed wersją 4.5.2 nie weryfikuje przynależności środowiska podczas operacji ponownego odtwarzania uruchomień, co pozwala uwierzytelnionym atakującym na wstrzykiwanie zadań do dowolnych środowisk. Atakujący mogą odtwarzać własne uruchomienia w środowiskach innych organizacji lub projektów, aby zużywać zasoby ofiary i zanieczyszczać historię uruchomień.

Trigger.dev przed wersją 4.5.2 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF) w adresach URL dostarczania kanałów alertów webhook, które są pobierane bez walidacji lub ochrony SSRF. Uwierzytelnieni użytkownicy z członkostwem w organizacji mogą tworzyć kanały alertów z adresami URL kierującymi do wewnętrznych usług i punktów końcowych metadanych, umożliwiając serwerowi wysyłanie żądań POST do ograniczonych zasobów.

Trigger.dev od wersji 4.4.2 do 4.5.0 ma podatność w trasach presign pakietów, gdzie nazwa pliku kontrolowana przez wywołującego jest przekazywana do generowania presigned URL, umożliwiając trawersację katalogów i dostęp do payloadów zadań innych organizacji. Klucz API projektu może odczytać lub nadpisać dane innych organizacji w środowiskach self-hosted.

Trigger.dev od wersji 4.4.2 do 4.5.0-rc.5 ma podatność w Aws4FetchClient.buildUrl() i presign(), gdzie klucze pakietów kontrolowane przez użytkownika są przypisywane do URL.pathname, a trasa akceptuje parametry bez odrzucania segmentów kropek i bez walidacji własności zasobów. Normalizacja ścieżki WHATWG usuwa segmenty .. przed podpisaniem, umożliwiając uzyskanie presigned URL dla kluczy innego dzierżawcy i odczyt lub nadpisanie payloadów zadań.

Trigger.dev od wersji 4.4.2 do 4.5.0-rc.4 ma podatność w endpointcie POST /api/v1/runs/:runParam/replay. Zapytanie do bazy danych nie filtruje po runtimeEnvironmentId, co pozwala dowolnemu kluczowi API środowiska na odtworzenie przebiegu innej dzierżawy przez friendlyId. Dodatkowo, przy użyciu payloadType "application/store", dane payload mogą być nadpisane przez atakującego, co prowadzi do wykonania nieautoryzowanych działań.

Trigger.dev przed wersją 4.5.2 zawiera podatność w funkcji addGoogleStrategy(), która przekazuje adres e-mail z profilu Google do findOrCreateGoogleUser() bez wymagania potwierdzenia email_verified. Gdy istnieje konto z tym samym adresem e-mail, atakujący może przejąć konto ofiary, używając niezweryfikowanego adresu e-mail z własnego profilu Google.

Trigger.dev od wersji 3.3.8 do 4.5.6 zawiera podatność w punkcie końcowym PUT /api/v1/runs/:runId/metadata, gdzie wartości operation.key są przekazywane do new JSONHeroPath(operation.key).set() bez odrzucania niebezpiecznych segmentów ścieżek, takich jak constructor i prototype. Osoba z normalnym kluczem API środowiska może zanieczyścić Object.prototype w procesie webapp, co prowadzi do uszkodzenia zapytań Prisma, etykiet Prometheus, złamania uwierzytelniania innych dzierżawców i awarii całego procesu.