Katalog podatności CVE

Podatność w Flowise 3.1.2 pozwala zdalnemu atakującemu na wykonanie dowolnego kodu poprzez endpoint /api/v1/prediction/<flowId>. Nie podano dodatkowych szczegółów.

W AppFlowy 0.11.8 występuje luka umożliwiająca zdalnemu atakującemu wykonanie dowolnego kodu. Problem dotyczy komponentów afLaunchUri, _afLaunchLocalUri (url_launcher.dart), OpenFilex.open oraz localPathRegex (common_patterns.dart).

Anchor CMS do wersji 0.12.7 włącznie nie egzekwuje kontroli dostępu opartej na rolach w endpointach zarządzania użytkownikami w panelu administracyjnym. Każdy uwierzytelniony użytkownik o niskich uprawnieniach może bezpośrednio wysłać żądanie POST do admin/users/add lub admin/users/edit, aby utworzyć konto administratora lub zmienić hasło istniejącego administratora.

Narzędzie knowns w wersjach do 0.33.0 nie waliduje parametru zapytania path w punkcie końcowym przeglądania workspace, co pozwala zdalnym atakującym na enumerację dowolnych katalogów w systemie plików hosta. Atakujący może przechodzić przez strukturę katalogów, aby zlokalizować katalogi projektów i zidentyfikować cele do dalszej eksploatacji.

knowns do wersji 0.33.0 włącznie bezwarunkowo zwalnia akcję project.set z kontroli uprawnień. Sesje agenta z uprawnieniami tylko do odczytu mogą obejść ograniczenia, wywołując project.set, aby wskazać serwerowi inny katalog projektu i uzyskać możliwość zapisu.

Narzędzie knowns w wersjach do 0.33.0 nie ogranicza argumentu path narzędzia MCP code.find do katalogu głównego projektu, co pozwala sesjom agenta AI na odczyt plików źródłowych w dowolnym miejscu hosta. Atakujący może podać ścieżki absolutne lub sekwencje przejścia relatywnego w argumencie path i pobrać pełną zawartość plików spoza zamierzonego katalogu projektu.

Narzędzie knowns w wersjach do 0.33.0 nieprawidłowo waliduje ścieżki docelowe szablonów w silniku generowania kodu, co pozwala na odczyt i zapis dowolnych plików poza katalogiem projektu. Atakujący może dostarczyć złośliwe szablony wykorzystujące przechodzenie katalogów (path traversal) do nadpisania profili powłoki, kradzieży poświadczeń lub trwałego wykonania kodu na systemie ofiary.

Znane wersje przed 0.31.0 nieprawidłowo walidują nagłówek żądania x-opencode-directory w punkcie końcowym proxy /api/opencode. Zdalni atakujący mogą podać dowolne ścieżki katalogów, aby wykonywać operacje na plikach poza katalogiem głównym projektu w systemie hosta.

rclone to program wiersza poleceń do synchronizacji plików i katalogów z różnymi dostawcami chmury. Przed wersją 1.75.1 rclone serve s3 skonfigurowany z --auth-proxy, ale bez --auth-key, pozwala authPairMiddleware zarejestrować dowolny wybrany przez klienta accessKeyID z pustym ws.s3Secret. gofakes3 następnie weryfikuje sygnaturę SigV4 żądania względem tego samego pustego sekretu, podczas gdy Server.auth przekazuje identyfikator klucza dostępu jako zarówno użytkownika, jak i wartość uwierzytelniającą do proxy bez niezależnego sekretu dla tożsamości. Nieuwierzytelniony atakujący sieciowy może zatem wybrać dowolny klucz dostępu, podpisać pustym sekretem i dotrzeć do dowolnego backendu, który skrypt auth-proxy rozwiąże dla tej tożsamości. Problem naprawiono w wersji 1.75.1.

W rclone od wersji 1.64.0 do 1.75.1 sterownik FTP auth-proxy przechowuje jedno zaciemnione hasło na nazwę użytkownika w globalnej mapie userPass, zamiast wiązać poświadczenia z sesją. Jeśli dwie zaakceptowane poświadczenia mają tę samą nazwę użytkownika, ale różne backendy proxy, późniejsze logowanie nadpisuje hasło i pierwsza sesja jest ponownie autoryzowana z uprawnieniami drugiego backendu, co pozwala na nieautoryzowany dostęp do operacji na plikach.

W rclone przed wersją 1.75.1, gdy backend lokalny działa z opcją --links, źródłowy obiekt .rclonelink może utworzyć dowiązanie symboliczne w miejscu docelowym, a następnie metadane katalogu są stosowane przez tę ścieżkę. Funkcje MkdirMetadata, writeMetadataToFile i setTimes mogą ominąć ograniczenia os.Root i podążyć za dowiązaniem, co pozwala atakującemu kontrolującemu źródło na zastosowanie wybranego właściciela, uprawnień, czasów modyfikacji lub utworzenia do pliku lub katalogu poza miejscem docelowym.

rclone to program wiersza poleceń do synchronizacji plików i katalogów z różnymi dostawcami chmury. W wersjach przed 1.75.1 backend/local z opcją --links lub links=true ujawnia cele dowiązań symbolicznych jako obiekty .rclonelink, a fs.RangeOption.Decode może przekazać niekontrolowany dodatni początek zakresu Range przez Object.Open i openTranslatedLink. Funkcja dzieli łańcuch celu jako linkdst[offset:], więc początek zakresu większy niż długość celu powoduje deterministyczną panikę przekroczenia granic wycinka, gdy lib/http/serve udostępnia obiekt przez HTTP lub WebDAV. Go net/http zwykle odzyskuje panikę na połączenie, powodując odmowę usługi na poziomie żądania, a nie zakończenie całego procesu. Problem naprawiono w wersji 1.75.1.

rclone to program wiersza poleceń do synchronizacji plików i katalogów z różnymi dostawcami chmury. Od wersji 1.72.0 do 1.75.1 metoda backendu archiwum ZIP (*Fs).readZip w backend/archive/zip/zip.go przyjmuje wartości archive/zip.File.Name z niezaufanego katalogu centralnego i ujawnia oczyszczone nazwy wpisów bez zapewnienia, że pozostają w przestrzeni nazw archiwum. Wpisy takie jak ../../etc/cron.d/evil mogą przetrwać path.Clean i stać się wartościami Object.Remote(), których fs/sync i fs/operations używają jako ścieżek względnych miejsca docelowego, pozwalając rclone copy lub sync zapisywać poza wybranym miejscem docelowym w backendach, które niezależnie nie ograniczają ścieżki. Sprawdzenie niepustego katalogu głównego używało również strings.HasPrefix bez granicy ścieżki, więc katalog główny foo mógł niepoprawnie obejmować wpisy sąsiadujące foobar. Problem naprawiono w wersji 1.75.1.

W rclone od wersji 1.49.0 do 1.75.1 backend HTTP dołącza nagłówki skonfigurowane przez --http-headers lub headers= do żądań, a klient fshttp.NewClient podąża za przekierowaniami bez polityki CheckRedirect. Skonfigurowany remote, który przekierowuje do innego hosta, może spowodować ponowne wysłanie niestandardowych sekretów, takich jak X-Api-Key, do niezaufanego celu, a przekierowanie HTTPS-to-HTTP w tym samym hoście może ujawnić nagłówki Authorization lub Cookie w postaci jawnej. Operacje listowania, stat, pobierania, montowania i serwowania mogą wywołać wyciek podczas normalnego użytkowania. Podatność naprawiono w wersji 1.75.1.

Traefik to otwartoźródłowy odwrotny serwer proxy i load balancer. Od wersji 2.8.2 do 2.11.56 oraz 3.7.12 punkty wejściowe HTTP/3 nie stosują entryPoints..transport.respondingTimeouts.readTimeout, ponieważ limit czasu jest wymuszany na połączeniu TCP, a serwer HTTP/3 nie ma odpowiadającego terminu strumienia QUIC. Nieuwierzytelniony klient może użyć powolnego ciała żądania, sącząc dane w nieskończoność, trzymając żądanie i połączenie nadrzędne otwarte oraz wyczerpując backendy o ograniczonych pulach połączeń. Problem naprawiono w wersjach 2.11.56 i 3.7.12.

Traefik to otwartoźródłowy odwrotny serwer proxy i load balancer. W wersjach przed 2.11.56 oraz od 3.0.0 do 3.7.12 nagłówek w formie z kropkami dostarczony przez klienta, taki jak X.Authenticated.User, przechodzi przez zastąpienie ForwardAuth i underscoreHeadersStrategy, ponieważ Go traktuje go jako odrębny od X-Authenticated-User, podczas gdy backendy CGI, WSGI, PHP i NGINX podatne na normalizację łączą obie nazwy. Backend może w konsekwencji użyć wartości klienta zamiast tożsamości potwierdzonej przez Traefik, umożliwiając podszywanie się pod tożsamość dla dowolnego nagłówka zarządzanego przez Traefik. Ochrona aliasHeadersStrategy jest domyślnie wyłączona i musi być skonfigurowana jako delete lub reject. Środek zaradczy jest dostępny w wersjach 2.11.56 i 3.7.12.

W Traefik przed wersjami 2.11.57 i 3.7.13 akceptowany jest bezrootowy cel żądania HTTP/1, który Go przechowuje w URL.Opaque, pozostawiając URL.Path pusty. Ścieżka rewriteRequestBuilder ocenia routing, sanityzację ścieżki, forwardAuth, encodedCharacters i logowanie dostępu na podstawie ścieżki znormalizowanej do /, ale przekazuje URL.Opaque dosłownie do backendu, co pozwala na obejście routingu między wirtualnymi hostami, obejście autoryzacji opartej na ścieżce i unikanie logów dostępu.

Brak weryfikacji własności zasobnika S3 w serwerze AWS Security Agent MCP w wersjach przed 0.2.0 może pozwolić zdalnym atakującym na uzyskanie prywatnego archiwum źródłowego skanowanego workspace, w tym danych uwierzytelniających i stanu infrastruktury zawartych w tym archiwum, poprzez wcześniej zarejestrowany zasobnik storage, którego nazwa pochodzi od publicznie znanego identyfikatora konta. Aby usunąć problem, użytkownicy powinni zaktualizować do wersji 0.2.0. Użytkownicy powinni również zweryfikować, że zasobnik wyjściowy skanowania na ich koncie jest własnością ich własnego konta, ponieważ aktualizacja nie zwalnia nazwy zasobnika, którą strona trzecia już zarejestrowała.

Brak weryfikacji własności zasobnika S3 w pluginie AWS Security Agent w Amazon aws-agents-for-devsecops w wersjach przed 1.1.0 może pozwolić zdalnym atakującym na uzyskanie prywatnego archiwum źródłowego skanowanego workspace, w tym danych uwierzytelniających i stanu infrastruktury zawartych w tym archiwum, poprzez wcześniej zarejestrowany zasobnik storage, którego nazwa pochodzi od publicznie znanego identyfikatora konta. Aby usunąć problem, użytkownicy powinni zaktualizować do wersji 1.1.0. Użytkownicy powinni również zweryfikować, że zasobnik wyjściowy skanowania na ich koncie jest własnością ich własnego konta, ponieważ aktualizacja nie zwalnia nazwy zasobnika, którą strona trzecia już zarejestrowała.

Dell ThinOS 10 w wersjach przed 2605_10.2616 zawiera podatność niewłaściwej neutralizacji elementów specjalnych używanych w poleceniach systemu operacyjnego (wstrzyknięcie poleceń OS). Wysoko uprzywilejowany atakujący z dostępem zdalnym może potencjalnie wykorzystać tę podatność, prowadząc do wykonania poleceń.