Katalog podatności CVE

Concrete CMS w wersjach przed 9.5.3 nie stosuje kodowania encji HTML do etykiet pytań bloku Formularz zdefiniowanych przez użytkownika podczas renderowania ich jako nagłówki kolumn w raporcie zgłoszeń formularzy w panelu administracyjnym. Złośliwy edytor może zapisać znaczniki lub skrypt w etykiecie, który następnie wykonuje się w przeglądarce administratora otwierającego raport, powodując trwały XSS.

Concrete CMS 9.5.2 i wcześniejsze są podatne na trwały DOM-based XSS poprzez pole Caption dla poszczególnych obrazów w bloku Gallery. Dołączony skrypt Magnific Popup ponownie parsuje zdekodowany atrybut caption jako HTML przez jQuery .append() w titleSrc zamiast wstawiać go jako tekst. Użytkownik z uprawnieniami do edycji strony może zapisać caption, który wykona się w przeglądarce każdego odwiedzającego otwierającego lightbox.

Wykryto podatność w pakiecie Go buildah/copier. Gdy pakiet jest używany poza Buildah przez użytkownika innego niż root, spreparowane archiwum tar zawierające złośliwe dowiązania symboliczne może wyjść poza katalog docelowy i utworzyć pliki w nieprzewidzianym miejscu. Sam Buildah stosuje wzmocnienie chroot i nie jest podatny.

Wykryto podatność w bibliotece containers/storage. Spreparowane archiwum tar zawierające złośliwy nagłówek whiteout (np. victim/.wh.) może spowodować zastąpienie katalogu docelowego ekstrakcji dowolnym plikiem podczas przetwarzania przez storage/pkg/archive.UnpackLayer, ApplyLayer lub ApplyUncompressedLayer.

motionEye (mEye) to interfejs online dla programu "motion", czyli systemu monitoringu wizyjnego z detekcją ruchu. W wersjach przed 0.44.0 metoda ActionHandler.post() w motioneye/handlers/action.py nie ma dekoratora BaseHandler.auth(), co pozwala nieuwierzytelnionemu zdalnemu atakującemu wysyłać żądania do /action/<camera_id>/<action>. Endpoint może wywoływać akcje snapshot, record_start i record_stop, a gdy administrator skonfigurował skrypty akcji, także sterowanie PTZ, akcje alarmowe, oświetleniowe i inne predefiniowane polecenia; skonfigurowane zdalne kamery motionEye mogą umożliwić żądania po stronie serwera do zdalnej usługi kamery. Problem naprawiono w wersji 0.44.0.

MCP Memory Keeper to serwer MCP do trwałego zarządzania kontekstem w asystentach AI wspomagających kodowanie. W wersjach przed 0.13.0 funkcja context_import w src/index.ts przekazuje kontrolowaną przez wywołującego ścieżkę filePath bezpośrednio do fs.readFileSync bez ograniczania jej do katalogu eksportu. Klient MCP, w tym agent LLM nakłoniony do wywołania narzędzia, może użyć przejścia ../ lub ścieżki absolutnej, aby uzyskać dostęp do dowolnego pliku czytelnego przez proces serwera. Prawidłowy plik JSON jest parsowany i importowany do sesji wywołującego, co pozwala na odczytanie jego pełnej zawartości przez context_get lub context_export, a błędy JSON.parse dla plików niebędących JSON mogą zwrócić początkowe bajty pliku w komunikacie SyntaxError. Te dwa tryby ujawnienia mogą odsłonić inne wyeksportowane sesje, dane uwierzytelniające JSON lub pliki kont usług, pliki środowiskowe oraz fragmenty kluczy SSH i innych plików lokalnych. Problem naprawiono w wersji 0.13.0.

plone.app.textfield udostępnia typ pola w stylu zope.schema o nazwie RichText do przechowywania wartości z powiązanym typem MIME. W wersjach przed 2.0.2, 3.0.2 i 4.0.1, w zależności od linii wydania, RichTextValue.output zwraca niesanityzowaną zapisaną wartość RichText, gdy mimeType jest równy outputMimeType, w tym wartości deklarujące typ wyjściowy text/x-html-safe. Ten skrót równości omija transformację safe_html, mimo że sama transformacja poprawnie usuwa atrybuty obsługi zdarzeń i niebezpieczne schematy URI. Równe typy mogą wynikać z pola RichText skonfigurowanego z tym samym mimeType i outputMimeType lub z danych wejściowych REST API podających text/x-html-safe jako typ zawartości. Surowa zapisana wartość jest następnie emitowana przez tal:content=structure bez escapowania, co pozwala użytkownikowi mogącemu ustawić pole RichText na zapisanie JavaScriptu wykonywanego w przeglądarce przeglądającego. Problem naprawiono w wersjach 2.0.2, 3.0.2 i 4.0.1.

Fabric CA to urząd certyfikacji dla Hyperledger Fabric. W wersjach przed 1.5.21, gdy fabric-ca jest skonfigurowany z backendem LDAP, funkcja Client.GetUser w lib/server/ldap/client.go wstawia nazwę użytkownika z uwierzytelniania HTTP Basic do filtra wyszukiwania LDAP uid (UserFilter) bez escapowania metaznaków LDAP. Nieuwierzytelniony atakujący z dostępem sieciowym do endpointu rejestracji CA może zmienić wyszukiwanie LDAP przed walidacją hasła i potencjalnie skierować próby uwierzytelnienia na konto ofiary. Wdrożenia niekorzystające z backendu LDAP nie są podatne. Problem naprawiono w wersji 1.5.21.

Concrete CMS 9 przed wersją 9.5.3 oraz Concrete 8.5.21 zawiera podatność na przechowywany XSS w blokach Feature, Feature Link, Hero Image i Image. Zewnętrzny adres URL linku był niewystarczająco walidowany i renderowany bez escapowania, co pozwalało użytkownikowi z uprawnieniami edycji strony na wstrzyknięcie dowolnego JavaScriptu.

Tornado w wersjach przed 6.5.7 zawiera podatność polegającą na wycieku poświadczeń w CurlAsyncHTTPClient, gdzie uchwyty pycurl są ponownie używane między żądaniami bez prawidłowego czyszczenia stanu. Atakujący mogą uzyskać poufne poświadczenia, wysyłając żądania przez tę samą instancję klienta, co pozwala na utrzymanie certyfikatów TLS lub uwierzytelniania proxy między niepowiązanymi żądaniami.

Tornado w wersjach przed 6.5.8 zawiera niekompletną poprawkę na wstrzykiwanie atrybutów cookie, która pozwala atakującym wstrzykiwać dowolne atrybuty cookie poprzez przekazywanie pisanych wielką literą lub przestarzałych argumentów słów kluczowych do set_cookie. Atakujący mogą osadzać dane rozdzielane średnikami w parametrach pisanych wielką literą, takich jak Domain, Path lub SameSite, aby obejść walidację i zmodyfikować atrybuty bezpieczeństwa cookie.

atomic-agents-stack w wersjach przed 1.1.0 zawiera obejście ograniczenia kosztów w funkcji _estimate_batch_cost, która zwraca zerowy koszt dla nieznanych modeli nieobecnych w tabeli cen. Atakujący mogą skonfigurować wdrożenia z nieznanymi identyfikatorami modeli, aby obejść dzienne limity kosztów i przekroczyć budżet w równoległych operacjach wsadowych.

gitoxide gix-transport w wersjach przed 0.59.2 nie filtruje znaków sterujących w żądaniach połączenia git-daemon, co pozwala atakującym wstrzykiwać bajty NUL/CR/LF poprzez spreparowane adresy URL git. Atakujący mogą wstrzykiwać dodatkowe pola protokołu rozdzielane NUL, aby podszyć się pod wirtualne hosty lub wstrzyknąć znaki nowej linii do żądań i logów demona.

Vikunja w wersjach przed 2.6.0 nie weryfikuje, czy podany przez użytkownika project_view_id w żądaniach pozycji zadań należy do projektu danego zadania. Uwierzytelniony atakujący może wstawiać wiersze pozycji zadań do widoków projektów innych najemców (tenantów) poprzez endpointy POST lub PUT.

Vikunja w wersjach przed 2.6.0 zawiera podatność obejścia zakresu tokena API w endpointach odczytu zadań, gdzie autoryzacja nie sprawdza parametrów zapytania. Atakujący z ograniczonym zakresem tokena może użyć parametru expand, aby uzyskać dostęp do danych takich jak komentarze, reakcje i wpisy czasu bez weryfikacji uprawnień.

Vikunja w wersjach przed 2.6.0 nadal ujawnia surowy współdzielony sekret TOTP po rejestracji poprzez endpointy GET /api/v1/user/settings/totp oraz /api/v1/user/settings/totp/qrcode bez ponownej autoryzacji. Atakujący z ważnym tokenem dostępu może odczytać sekret, zaimportować go do własnego authenticatora i generować ważne kody bezterminowo.

Vikunja w wersjach przed 2.6.0 nieprawidłowo waliduje tokeny udostępniania linków w endpointach wyszukiwania użytkowników API v2. Atakujący z linkiem udostępniania tylko do odczytu może wyliczać użytkowników projektu poprzez endpoint projektów oraz potwierdzać istnienie dowolnych nazw użytkowników poprzez globalny endpoint wyszukiwania.

Vikunja w wersjach przed 2.6.0 nie weryfikuje dostępu do zespołów podczas przypisywania zespołów do projektów, co pozwala uwierzytelnionym użytkownikom wyliczać wszystkie zespoły i ich członków. Atakujący może przypisać dowolne identyfikatory zespołów poprzez endpoint zespołów projektu, aby uzyskać pełne listy członków, w tym nazwiska i flagi administratora.

Vikunja w wersjach przed 2.6.0 nie ogranicza rozpakowywania archiwów podczas importu danych, co pozwala uwierzytelnionym użytkownikom wywołać odmowę usługi. Atakujący może przesłać wysoce skompresowane pliki, które rozpakowują się do dziesiątek gigabajtów w pamięci i na dysku, wyczerpując zasoby serwera i powodując awarię instancji.

Vikunja w wersjach przed 2.6.0 nie stosuje limitów dekodowania pikseli w endpointach przesyłania awatarów i teł projektów, co pozwala uwierzytelnionym użytkownikom przesyłać spreparowane obrazy dekodujące się do nadmiernej liczby pikseli. Atakujący może przesyłać małe obrazy o ekstremalnych proporcjach, które zużywają znaczną ilość CPU i pamięci podczas przetwarzania, powodując odmowę usługi.