Katalog podatności CVE

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 cli-v3 w wersjach od 3.0.0 do 4.5.4 zawiera podatność braku uwierzytelniania w serwerze trigger dev --mcp, który wiąże wszystkie interfejsy sieciowe i udostępnia punkty końcowe /sse i /messages. Atakujący w sieci LAN lub złośliwe strony internetowe mogą wysyłać żądania MCP tools/call, aby wywołać trigger-task, cancel-run, list-runs i get-run-logs przy użyciu przechowywanego tokenu dostępu dewelopera.

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 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.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.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.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.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 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.

Trigger.dev CLI w wersjach przed 4.5.9 zawiera podatność polegającą na ujawnieniu informacji, która eksponuje rozwiązane wartości sekretów środowiska w logach debugowania wdrożenia poprzez serializację nieocenzurowanych zmiennych envVars. Atakujący z dostępem do transkryptów terminala, logów debugowania CI lub pakietów wsparcia mogą odczytać rekord Starting buildWorker, aby odzyskać ciągi połączeń do bazy danych i poświadczenia usług.