Katalog podatności CVE

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

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

Snipe-IT w wersjach przed 8.7.0 zawiera podatność typu server-side request forgery w funkcji testowania webhooków, która pozwala użytkownikom z uprawnieniami super-administratora na sondowanie wewnętrznych adresów sieciowych, w tym zakresów loopback i RFC1918. Atakujący mogą kierować webhooki na wewnętrzne hosty i porty, a następnie porównywać odpowiedzi 4xx i 5xx z Test Webhooks, aby mapować otwarte porty i aktywne hosty.

SvelteKit w wersjach przed 3.0.0 zawiera podatność typu server-side request forgery (SSRF), ponieważ mechanizm self-fetch fallback automatycznie podąża za przekierowaniami HTTP. Atakujący może manipulować nagłówkami Host lub forwarded, aby skierować żądania fallback do własnego serwera, który następnie przekierowuje je do usług wewnętrznych.

SvelteKit (@sveltejs/kit) w wersjach przed 3.0.0 zawiera podatność cross-site scripting (XSS) w prerenderowanych stronach, ponieważ wartość nagłówka cache-control ustawiona przez setHeaders jest wstawiana bez escapowania do tagu <meta http-equiv="cache-control">. Atakujący, który może wpłynąć na tę niezaufaną wartość w czasie prerenderowania, może wyłamać się z atrybutu content i wstrzyknąć HTML lub JavaScript, który wykona się u użytkowników odwiedzających stronę.

SvelteKit (@sveltejs/kit) w wersjach przed 3.0.0 zawiera podatność open redirect w ulepszonych akcjach formularzy (use:enhance) na trasach akceptujących ścieżki rozpoczynające się od podwójnego ukośnika. Atakujący może tworzyć ścieżki akcji zaczynające się od //, które stają się adresami URL względnymi protokołu, powodując przekierowanie ofiar do witryn kontrolowanych przez atakującego.

ArcadeDB od wersji 26.2.1 przed 26.10.1 zawiera podatność braku autoryzacji w obsłudze protokołu Bolt, która pozwala uwierzytelnionym użytkownikom odczytywać metadane schematów innych baz danych. Atakujący posiadający poświadczenia do jednej bazy danych może ustawić pole db w komunikatach RUN lub BEGIN i wywołać db.labels() lub SHOW INDEXES, aby wyliczyć nieautoryzowane schematy.

ArcadeDB od wersji 26.2.1 przed 26.10.1 zawiera podatność braku autoryzacji w obsłudze protokołu Bolt, która pozwala uwierzytelnionym użytkownikom wyliczyć nazwy wszystkich baz danych. Atakujący posiadający poświadczenia do dowolnej pojedynczej bazy danych może wykonać zapytanie SHOW DATABASES przez port Bolt, aby ujawnić nieautoryzowane nazwy baz danych, eksponując identyfikatory dzierżawców lub projektów.

ArcadeDB od wersji 26.8.1 przed 26.10.1 zawiera podatność obejścia autoryzacji, która pozwala użytkownikom z uprawnieniami tylko do odczytu modyfikować flagi schematu lightweight i unique typów krawędzi bez uprawnienia UPDATE_SCHEMA. Atakujący może wysłać polecenie ALTER TYPE edgeType WITH lightweight = true przez API HTTP, gRPC lub Bolt, aby trwale zmienić deklaracje przechowywania krawędzi.

vLLM w wersjach przed 0.31.0 zawiera podatność aliasingu pamięci podręcznej, która pozwala uwierzytelnionym atakującym kolidować współdzielone klucze pamięci podręcznej poprzez dostarczanie wartości kontrolowanych przez wywołującego, takich jak EXIF ImageID lub cache_salt. Atakujący może ustawić UUID EXIF ImageID, aby otrzymać przetworzone media z pamięci podręcznej innego żądania, lub dopasować cache_salt do nazwy LoRA, aby ponownie użyć stanu KV pierwszego bloku.