Katalog podatności CVE
Przetłumaczone opisy podatności z bazy NVD NIST - w języku polskim
Przeglądaj podatności według pakietuKatalog CISA KEV zaktualizowany: (v2026.11.06)
Cotygodniowy digest CVE
Jeden mail w tygodniu z nowo opublikowanymi podatnościami, o których warto wiedzieć. Bez zakładania konta.
Digest dotyczy ogólnie nowych podatności, nie Twoich serwerów. Jeśli chcesz wiedzieć, które z nich faktycznie działają w Twojej infrastrukturze, tym zajmuje się Secvalis : skanuje Twoje maszyny i zgłasza wyłącznie to, co ich dotyczy.
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 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.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 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 (@sveltejs/kit) w wersjach od 2.10.0 przed 3.0.0 zawiera podatność na path traversal w serwerze vite preview na Windows, pozwalającą nieuwierzytelnionym atakującym czytać pliki poza katalogiem prerenderowanego wyjścia. Atakujący, którzy mogą dotrzeć do serwera preview przez sieć lub tunel, mogą wysłać spreparowane żądania, aby ujawnić kod źródłowy, konfigurację lub poświadczenia czytelne dla procesu serwera.
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 w wersjach przed 26.10.1 zawiera podatność na zdalne wykonanie kodu (RCE). Uwierzytelnieni użytkownicy, w tym posiadacze roli tylko do odczytu, mogą wykonywać kod Groovy, ponieważ GremlinQueryEngine.command() nie sprawdza uprawnień do skryptów. Atakujący mogą wysyłać polecenia Gremlin do endpointu POST /api/v1/command/{database}, gdy silnik Groovy jest włączony, i uruchamiać polecenia systemowe jako użytkownik procesu serwera.
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 od wersji 0.7.3 przed 0.31.0 zawiera podatność na niekontrolowane zużycie zasobów. Zdalni klienci mogą kontrolować parametry procesora multimodalnego, dostarczając mm_processor_kwargs w każdym żądaniu. Atakujący mogą ustawić duże wartości rozmiaru obrazu, liczby patchy, przycięć lub klatek w procesorach Isaac, InternVL, H2OVL i innych, aby wyczerpać pamięć i zatrzymać współdzielony serwer.
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.
vLLM od wersji 0.7.3 przed 0.31.0 przekazuje wartość mm_processor_kwargs.code_revision dostarczoną w żądaniu do Transformers AutoProcessor.from_pretrained. Pozwala to klientom wybrać wersję dynamicznego kodu procesora modelu, która jest importowana, gdy trust_remote_code jest włączone. Atakujący kontrolujący wersję w repozytorium modelu może wysłać żądanie multimodalne do nieuwierzytelnionego endpointu /tokenize, aby wykonać dowolny kod Python w procesie API vLLM.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

