Katalog podatności CVE

Biblioteka kliencka RabbitMQ Java umożliwia aplikacjom Java i JVM łączenie się i interakcję z węzłami RabbitMQ. Przed wersją 5.33.0, metody com.rabbitmq.client.ConnectionFactory.useSslProtocol() i ConnectionFactory.useSslProtocol(String) konfigurują com.rabbitmq.client.TrustEverythingTrustManager i pozostawiają wyłączoną weryfikację nazwy hosta, co powoduje akceptowanie dowolnych certyfikatów serwera, w tym certyfikatów samopodpisanych. Atakujący sieciowy, który może przechwycić połączenie TLS, może podszyć się pod brokera RabbitMQ, czytać chroniony ruch AMQP i modyfikować ruch bez weryfikacji certyfikatu lub nazwy hosta. Poprawka zmienia produkcyjne pomocnicze funkcje TLS, aby używały domyślnego magazynu zaufania JVM i włącza weryfikację nazwy hosta, zachowując jawnie nazwany pomocniczy tryb deweloperski bez weryfikacji. Problem został naprawiony w wersji 5.33.0.

Biblioteka kliencka RabbitMQ Java umożliwia aplikacjom Java i JVM łączenie się i interakcję z węzłami RabbitMQ. Przed wersją 5.31.0, przychodzące składanie poleceń AMQP w src/main/java/com/rabbitmq/client/impl/CommandAssembler.java przetwarza metodę zawierającą treść i nagłówek, którego wartość remainingBodyBytes jest mniejsza niż następujący po niej payload AMQP.FRAME_BODY. CommandAssembler.consumeBodyFrame odejmuje kontrolowaną przez peera długość payloadu przed walidacją, że pasuje, co powoduje, że remainingBodyBytes staje się ujemne i zgłasza surowy wyjątek UnsupportedOperationException zamiast MalformedFrameException. Złośliwy lub skompromitowany broker może wysłać tę nieprawidłową sekwencję na otwartym niezerowym kanale, aby zakończyć przetwarzanie ramek i zamknąć połączenie klienta, powodując odmowę usługi dla pracy korzystającej z tego połączenia. Problem został naprawiony w wersji 5.31.0.

Biblioteka kliencka RabbitMQ Java przed wersją 5.33.0 nie stosuje spójnie negocjowanego limitu frame_max podczas walidacji rozmiaru ramek od brokera. Złośliwy broker może wysłać ramkę większą niż dozwolona, co prowadzi do alokacji i dekodowania nieprawidłowej ramki zamiast jej odrzucenia, powodując przerwanie połączenia i odmowę usługi po stronie klienta.

authentik przed wersjami 2026.2.6 i 2026.5.5 udostępnia listę wszystkich skonfigurowanych punktów końcowych Remote Access Control każdemu uwierzytelnionemu użytkownikowi, niezależnie od uprawnień do aplikacji. Odpowiedź zawiera ustawienia połączeń, które mogą zawierać przechowywane poświadczenia. Każdy uwierzytelniony użytkownik może odczytać wszystkie punkty końcowe wraz z hostem i poświadczeniami oraz otworzyć połączenie do punktu końcowego należącego do innej aplikacji, co ujawnia poświadczenia dla zarządzanych celów RDP, SSH i VNC oraz daje interaktywny dostęp do systemów, do których użytkownik nie był autoryzowany.

authentik przed wersjami 2026.2.6 i 2026.5.5 zawiera podatność w konfiguracji SAML Source z trybem dopasowania użytkownika USERNAME_LINK lub EMAIL_LINK. Atakujący może wstawić komentarz XML do NameID, co prowadzi do przejęcia konta ofiary.

authentik to dostawca tożsamości open-source. Przed wersjami 2026.2.6 i 2026.5.5, akcja diagnostyczna w API źródła LDAP nie egzekwuje filtra autoryzacji odczytu na poziomie obiektu używanego przez resztę API. Każda strona, która może dotrzeć do API, w tym nieuwierzytelniony klient, może wywołać akcję diagnostyczną przeciwko skonfigurowanemu źródłu LDAP. Serwer następnie łączy się z nadrzędnym katalogiem przy użyciu skonfigurowanych poświadczeń bind źródła i zwraca ograniczony zestaw wpisów katalogu. Odpowiedź ujawnia wyróżnione nazwy tych wpisów oraz nazwy atrybutów na nich obecnych, ujawniając strukturę katalogu, konwencje nazewnictwa oraz istnienie określonych kont i grup, ale nie wartości atrybutów. Wdrożenia bez skonfigurowanego źródła LDAP nie są dotknięte. Problem został naprawiony w wersjach 2026.2.6 i 2026.5.5.

authentik przed wersjami 2026.2.6 i 2026.5.5 w przedsiębiorczych etapach Google Chrome device-trust kontynuuje przepływ bez potwierdzenia, że atestacja urządzenia poza pasmem faktycznie się odbyła. Atakujący, który może dotrzeć do takiego etapu, może pominąć iframe weryfikacyjny i uwierzytelnić się z urządzenia, które nigdy nie zostało zweryfikowane. Tam, gdzie zaufanie do urządzenia jest jedynym dodatkowym czynnikiem, ochrona jest całkowicie pominięta.

ePA 3.x Integration przed wersją 1.3.0 zawiera podatność w walidacji certyfikatów serwera VAU. Atakujący w pozycji sieciowej może przechwycić uzgadnianie VAU i podszyć się pod serwer, kontrolując klucze sesji i odczytując lub modyfikując zaszyfrowany ruch.

Podatność na odbity atak XSS w reportico-web do wersji 8.1.0 włącznie. Atakujący może wykonać dowolny kod JavaScript w przeglądarce ofiary, umieszczając złośliwy ładunek w parametrze loadTemplate wraz z parametrem execute_mode=PREPARE w pliku run.php.

ePA 3.x Integration przed wersją 1.3.0 wyłącza weryfikację certyfikatów TLS zarówno dla połączeń ePA w app/vau/VAUProtokoll.py, jak i połączeń Konnektor w app/konnektor/Konnektor.py. Atakujący w pozycji sieciowej może przedstawić dowolny certyfikat, zakończyć połączenie TLS i przechwycić ruch ePA. Protokół VAU nie zapewnia skutecznego zabezpieczenia, ponieważ walidacja certyfikatów na poziomie aplikacji jest również uszkodzona. Sesja Konnektor używa self.session.verify ustawionego na False, więc atakujący podszywający się pod Konnektor może otrzymać wymianę certyfikatów wzajemnego TLS i obserwować operacje na karcie inteligentnej.

ePA 3.x Integration przed wersją 1.3.0 pozostawia request_counter bez zmian w app/vau/VAUProtokoll.py podczas konstruowania wiadomości VAU. Zamrożony licznik żądań klienta powoduje, że serwer ponownie używa kombinacji nonce i klucza AES-GCM w odpowiedziach. Atakujący sieciowy, zbierając powtarzające się szyfrogramy, może odzyskać XOR tekstów jawnych i użyć przewidywalnych nagłówków HTTP i pól JSON do odzyskania wrażliwych danych, w tym dokumentacji medycznej pacjentów. Powtarzające się nonce mogą również umożliwić odzyskanie klucza uwierzytelniającego GHASH, co pozwala na fałszowanie wiadomości AES-GCM i wstrzykiwanie złośliwych odpowiedzi.

ePA 3.x Integration implementuje przepływ autoryzacji i zapisuje obiekty informacji medycznych do niemieckiej elektronicznej dokumentacji pacjenta. Przed wersją 1.3.0, ePA 3.x Integration nie neutralizuje znaków CRLF w wartościach używanych przez app/vau/VAUProtokoll.py do konstruowania wewnętrznych żądań HTTP VAU. Funkcja build_inner_header interpoluje wartości uri, host, accept_type, content_type, content_length, USER_AGENT i insurant_id do linii żądań i nagłówków, w tym x-useragent i x-insurantid. Uwierzytelniony atakujący, który kontroluje wartość, może wstrzyknąć dodatkowe nagłówki do wewnętrznego żądania. W zależności od obsługi serwera ePA, wstrzyknięty nagłówek x-insurantid może ujawnić dokumentację innego pacjenta, a wstrzyknięte nagłówki Authorization mogą ominąć zamierzone uwierzytelnienie lub kontekst autoryzacji. Dane wejściowe USER_AGENT pochodzące z sesji mogą również zatruć żądania w całej sesji. Problem został naprawiony w wersji 1.3.0.

Adaguc-server przed wersją 7.2.2 zawiera podatność powodującą awarię z błędem bezpieczeństwa pamięci podczas parsowania dokumentu GeoJSON z nieprawidłową współrzędną. Parser indeksuje tablicę wartości bez walidacji typu węzła JSON lub długości współrzędnej, co prowadzi do odczytu poza zakresem lub wyłuskania pustego wskaźnika. Problem występuje w gałęziach geometrii: Polygon, LineString, MultiLineString i MultiPolygon.

Vvveb przed wersją 1.0.8.4 umożliwia sprzedawcy o niskich uprawnieniach dostęp do produktów należących do innego sprzedawcy. Kontroler produktów nie sprawdza właściciela produktu przy operacjach duplikowania i usuwania, co pozwala na odczyt, kopiowanie i usuwanie produktów oraz powiązanych danych.

Vvveb przed wersją 1.0.8.4 umożliwia sprzedawcy o niskich uprawnieniach dostęp do rewizji produktów należących do innego sprzedawcy. Zapytania SQL nie sprawdzają właściciela produktu przy odczycie, przywracaniu i usuwaniu rewizji.

Vvveb przed wersją 1.0.8.4 umożliwia autorowi o niskich uprawnieniach dostęp do rewizji postów należących do innego autora. Zapytania SQL nie sprawdzają właściciela posta przy listowaniu, odczycie, przywracaniu i usuwaniu rewizji.

Vvveb przed wersją 1.0.8.4 umożliwia sprzedawcy o niskich uprawnieniach zarządzanie recenzjami produktów należących do innego sprzedawcy. Zapytania SQL nie weryfikują właściciela produktu dla recenzji.

Vvveb przed wersją 1.0.8.4 umożliwia sprzedawcy o niskich uprawnieniach zarządzanie pytaniami pod produktami innego sprzedawcy. Zapytania SQL nie weryfikują właściciela produktu dla pytań.

Saleor w wersjach od 3.14.67 do 3.21.67, 3.22.63 i 3.23.22 ma wadliwą kontrolę autoryzacji w saleor/permission/utils.py, która może błędnie autoryzować nieuwierzytelnione żądania GraphQL. Pozwala to anonimowym użytkownikom na użycie mutacji channelUpdate() do zmiany ustawień zamówień, takich jak allowUnpaidOrders, nawet gdy odpowiedź zgłasza PermissionDenied. Ta sama funkcja może ujawniać ukryte obiekty przez zapytania pageType() i translation(), w tym atrybuty z visibleInStorefront ustawionym na false.

Podatność na atak XSS w polu dokumentacji użytkownika w oprogramowaniu ANOW! Automate w wersji 3.3.1.90 firmy Beta Systems Software AG. Zdalny atakujący może wykonać dowolny kod.