Katalog podatności CVE

W RabbitMQ w wersjach od 4.0.0 do 4.0.22, 4.1.14, 4.2.7 i 4.3.1 występuje podatność polegająca na wyczerpaniu atomów. Funkcja toatom/1 jest wywoływana na segmencie ścieżki URL :name w endpointach global-parameters, co pozwala użytkownikowi z uprawnieniami policymaker na wielokrotne żądania i wyczerpanie tablicy atomów, prowadząc do awarii węzła.

W RabbitMQ w wersjach od 4.0.0 do 4.0.22, 4.1.14 i 4.2.7 występuje podatność polegająca na wyczerpaniu atomów dostępna tylko dla administratora. Funkcja settags/2 wywołuje toatom/1 na liście tagów użytkownika, a limit rozmiaru ciała żądania (20 MB) pozwala na przesłanie około 3-4 milionów krótkich tagów. Administrator może doprowadzić do awarii węzła pojedynczym żądaniem.

RabbitMQ w wersjach od 3.13.0 do 3.13.15, 4.0.20, 4.1.11 i 4.2.6 ma podatność polegającą na zastosowaniu list_to_atom/1 do każdego tokena rozdzielanego dwukropkiem w kontrolowanej przez atakującego wartości auth_mechanism, co trwale zużywa atomy maszyny wirtualnej Erlanga i może doprowadzić do awarii węzła przy dużym żądaniu. Eksploatacja wymaga użycia wtyczek Shovel lub Federation oraz posiadania tagu policymaker.

RabbitMQ w wersjach od 3.13.0 do 3.13.15, 4.0.20, 4.1.11 i 4.2.6 zawiera podatność polegającą na obejściu ochrony tagu 'protected' poprzez masowe usuwanie użytkowników. Administrator może usunąć konta usługowe oznaczone jako chronione, korzystając z punktu końcowego bulk-delete, co omija zabezpieczenie sprawdzające tag 'protected'.

RabbitMQ w wersjach od 3.13.0 do 3.13.15, 4.0.20, 4.1.11 i 4.2.6 ma podatność na wyczerpanie tablicy atomów przez pole node w API zarządzania. Żądanie PUT /api/queues/:vhost/:name (oraz endpointy exchanges i bindings) przyjmuje pole JSON node, które jest konwertowane na atom bez sprawdzenia przynależności do klastra. Każda unikalna wartość trwale wycieka jeden atom, a około 900 tysięcy żądań może zawiesić maszynę wirtualną.

RabbitMQ w wersjach od 3.13.0 do 3.13.15, 4.0.22, 4.1.11, 4.2.6 i 4.3.1 ma podatność na wyczerpanie atomów przez wartości scope w tokenach OAuth2 JWT. Funkcja extractscopes/1 parsuje scope'y w formacie .tag: i konwertuje je na atomy. Podpis tokena jest weryfikowany, ale w konfiguracjach IdP, gdzie treść scope jest kontrolowana przez użytkownika, każde logowanie z nową wartością tagu wycieka jeden atom.

RabbitMQ w wersjach od 4.0.0 do 4.3.3, 4.2.9, 4.1.14 i 4.0.23 ma podatność w AMQP 1.0, gdzie endpoint GET /bindings w zarządzaniu ujawnia pełną topologię bindingów każdemu uwierzytelnionemu użytkownikowi AMQP bez sprawdzania uprawnień do zasobów. W przeciwieństwie do innych operacji w tym samym module, GET /bindings nie sprawdza uprawnień i zwraca listę bindingów bez zmian.

Readwise Reader dla Androida używa konfiguracji sanitize-html, która zezwala na wszystkie atrybuty w elementach SVG i PATH z powodu reguły wildcard. Ta konfiguracja nie usuwa atrybutów zdolnych do wykonywania skryptów, takich jak event handlery (np. 'onload', 'onerror'). Atakujący może dostarczyć dokument z złośliwą zawartością SVG, która przetrwa sanityzację i wykona skrypt w WebView, co prowadzi do XSS po stronie klienta.

Readwise Reader dla Androida konstruuje URL-e w WebView przy użyciu kontrolowanych przez atakującego metadanych bez odpowiedniego kodowania lub escapowania. Aplikacja interpoluje niezaufane wartości bezpośrednio do stringów URL i wstawia je do DOM przez innerHTML. Ponieważ interpolacja odbywa się bez kodowania kontekstu HTML lub JavaScript, spreparowana wartość metadanych może wyrwać się z zamierzonej struktury URL i wstrzyknąć skrypt.

Podatność XSS w aplikacji Readwise Reader dla Androida, wynikająca z braku sanityzacji HTML w przetwarzaniu metadanych importowanych dokumentów. Pola kontrolowane przez atakującego, takie jak metadane autora, są wstawiane do WebView przez innerHTML, umożliwiając trwały XSS, który wykonuje się na zsynchronizowanych urządzeniach podczas otwierania złośliwego dokumentu.

Rozszerzenie Mediawiki - Thanks Extension przed wersjami 1.43.10, 1.45.5 i 1.46.1 zawiera podatność typu Stored XSS z powodu nieprawidłowej neutralizacji danych wejściowych podczas generowania stron internetowych.

Wada w funkcji AgenticScopeSerializer.fromJson w komponencie LangChain4j-agentic powoduje problem z deserializacją. Atak zdalny jest możliwy, ale jego złożoność jest wysoka, a wykorzystanie trudne. Problem został naprawiony w wersjach 1.5.3-beta11, 1.11.10-beta19 i 1.18.1-beta28. Eksploit został opublikowany i może być użyty.

Podatność w PostgreSQL Anonymizer pozwala nieuprzywilejowanym użytkownikom z rolą maskującą wielokrotnie wywoływać funkcję anon.hash() i zbierać pary (seed, hash_output) w celu przeprowadzenia ataku brute-force offline i odgadnięcia soli. Problem rozwiązano w wersji 3.2.3.

W InvoicePlane w wersji 1.7.2-beta-1 wartość client_email jest przechowywana bez sprawdzania składni adresu e-mail i wyświetlana bez escape'owania wewnątrz atrybutów z podwójnymi cudzysłowami w formularzach mailerów. Administrator, który może edytować klienta, może zapisać dane łamiące atrybuty, a gdy mailer jest skonfigurowany, JavaScript wykonuje się po otwarciu strony mailera przez innego administratora. Problem naprawiono w wersji 1.7.2.

Przed wersją 1.7.2 w InvoicePlane kontroler User_Controller porównuje wartość user_type z sesji z wymaganą rolą za pomocą luźnego operatora nierówności PHP. W niestandardowym backendzie sesji, który zwraca niespodziewane typy skalarne, type juggling może spowodować, że wartość nie będąca ściśle wymaganą rolą przejdzie kontrolę autoryzacji. Problem naprawiono w wersji 1.7.2.

Przed wersją 1.7.2 w InvoicePlane metoda Users::change_password() przyjmuje user_id z URL i aktualizuje hasło tego konta bez autoryzacji na poziomie obiektu. Uwierzytelniony administrator drugorzędny może zmienić hasło konta administratora głównego bez znajomości obecnego hasła, a następnie przejąć konto i uzyskać jego dane oraz uprawnienia. Problem naprawiono w wersji 1.7.2.

Przed wersją 1.7.2 w InvoicePlane metoda Cron::recur() zapisuje nieprawidłowy klucz cron z adresu URL bezpośrednio do logu aplikacji bez neutralizacji znaków CRLF. Nieuwierzytelniony żądający może wstrzyknąć sfałszowane linie logów do ścieżki audytowej, co może zakłócić analizę kryminalistyczną i monitoring oparty na logach. Problem naprawiono w wersji 1.7.2.

Przed wersją 1.7.2 w InvoicePlane brakuje walidacji tokena CSRF w metodach usuwania, takich jak Payments::delete(), Recurring::delete() i User_clients::delete(). Mimo że trasy wymagają metody POST, nie sprawdzają tokena CSRF. Atakujący może wysłać formularz z innego origin przez przeglądarkę uwierzytelnionego administratora, aby usunąć dane finansowe i inne rekordy. Problem naprawiono w wersji 1.7.2.

Przed wersją 1.7.2 w InvoicePlane trasa Recurring::stop() jest dostępna przez GET i nie waliduje tokena CSRF. Gdy uwierzytelniony administrator załaduje treść kontrolowaną przez atakującego, która żąda /invoices/recurring/stop/{id}, aplikacja zatrzymuje wybraną fakturę cykliczną. Atakujący może celować w wiele identyfikatorów, przerywając cykliczne rozliczenia i powodując straty finansowe. Problem naprawiono w wersji 1.7.2.

W RabbitMQ w wersjach od 4.2.0 do 4.2.8 i 4.3.2 udane żądanie POST /login powodowało, że is_authorized/2 ustawiało ciasteczko autoryzacyjne zawierające zakodowane w base64 dane uwierzytelniające username:password bez zabezpieczeń HttpOnly, Secure, SameSite ani wygaśnięcia. Ponieważ base64 to kodowanie, a nie szyfrowanie, atakujący z XSS, dostępem do sieci lub lokalnym dostępem do przeglądarki może odzyskać rzeczywiste dane logowania.