Katalog podatności CVE

W systemie wieloużytkownikowym użytkownik z aktywną lokalną sesją logowania może zdegradować systemową aplikację Flatpak do starszej wersji, usuwając referencję zdalną aplikacji za pomocą nieuprzywilejowanej metody system-helper RemoveLocalRef, co powoduje, że kontrola anty-degradacji nie znajduje daty referencyjnej. Złośliwy lokalny użytkownik może to wykorzystać do narażenia innych użytkowników tego samego systemu na wersję aplikacji z niezałatanymi podatnościami.

Parser strumienia delta OCI odczytuje rozmiary jako guint64, ale przekazuje je do funkcji GLib I/O i alokacji oczekujących gsize (32 bity na systemach 32-bitowych), co powoduje niedowymiarowane alokacje i przepełnienia sterty. Atakujący kontrolujący rejestr OCI może stworzyć złośliwy strumień delta, który podczas instalacji/aktualizacji flatpak może doprowadzić do wykonania kodu na systemach 32-bitowych.

Nezha 2.2.3 zawiera regresję wstrzykiwania nagłówka Host w punkcie końcowym przekierowania OAuth2. Gdy opcjonalne ustawienie dashboard_host jest puste, /api/v1/oauth2/{provider} odzwierciedla nagłówek Host dostarczony przez atakującego do redirect_uri wysyłanego do dostawcy tożsamości. Atakujący może przejąć kod autoryzacyjny ofiary i przejąć konto.

Nezha przed wersją 2.2.7 zawiera podatność na ujawnienie informacji w punkcie końcowym GET /api/v1/profile, który zwraca pole hasła zahashowanego bcrypt uwierzytelnionych użytkowników. Atakujący mogą wyodrębnić hashe haseł i przeprowadzić ataki offline bez ograniczeń szybkości ani śladów audytu.

Nezha to narzędzie do monitorowania serwerów i stron internetowych. W wersjach >= 2.2.11 i < 2.3.1, worker sentinel usługi (service/singleton/servicesentinel.go) zawiera niekompletną poprawkę wcześniej zgłoszonej podatności na wyłuskanie nil (denial of service) (GHSA-qjpp-gffx-2wm9). Poprawka z 2026-07-21 ponownie walidowała cykl życia usługi pod serviceResponseDataStoreLock, ale używała już przechwyconego, nieaktualnego wskaźnika reportera i nigdy nie ponownie walidowała serwera, a ten lock nie chroni ServerShared. Uwierzytelniony użytkownik z rolą członka, który posiada agenta, może wydać równoczesne usunięcie serwera (POST /api/v1/batch-delete/server) dla własnego serwera, aby wygrać wyścig, powodując wyłuskanie brakującego wpisu w migawce listy serwerów przez worker. Ponieważ workery sentinel i serwer gRPC nie mają interceptora recover()/recovery, wynikający panic jest nieodzyskany i powoduje awarię całej instancji. Poprawione w wersji 2.3.1.

Nezha w wersjach 2.0.10 do 2.3.2 używa ograniczonego klienta HTTP do walidacji konfigurowalnych przez użytkownika adresów URL webhooków powiadomień i DDNS, ale lista zablokowanych nie obejmowała zakresów przejściowych IPv6 — konkretnie prefiksu 6to4 2002::/16 oraz prefiksu translacji lokalnej IPv4/IPv6 64:ff9b:1::/48. Ponieważ takie adresy spełniają sprawdzenie netip.Addr.IsGlobalUnicast w Go, walidator URL je akceptował. Uwierzytelniony użytkownik mogący skonfigurować webhook może spowodować, że dashboard wyśle żądania do w inny sposób ograniczonego punktu końcowego IPv6, ale tylko tam, gdzie sieć dashboardu zapewnia nietypowe lub niezgodne ze standardami routowanie dla tych zakresów przejściowych; nie wykazano bezpośredniej ścieżki do żądania HTTP do metadanych IPv4, pętli zwrotnej lub sieci prywatnej. Problem jest naprawiony w wersji 2.3.3 (commit d1fcde8e), która blokuje oba prefiksy.

Nezha Dashboard w wersjach przed 2.3.5 nie ogranicza typów zadań monitorów usług do obsługiwanych typów sond. Uwierzytelniony użytkownik z uprawnieniem nezha:service:write może przesłać uprzywilejowane typy zadań przez API usługi, wykorzystując współdzieloną przestrzeń nazw protobuf Task.Type.

Nezha przed 2.3.8 nie waliduje typu reguły alertu ani zakresu czasu trwania, co pozwala uwierzytelnionym użytkownikom niebędącym administratorami tworzyć błędne reguły wywołujące nieodwracalne paniki w goroutine ewaluatora alertów. Atakujący może przesłać spreparowaną regułę przez POST /api/v1/alert-rule, powodując awarię procesu dashboardu.

Wersje obot przed v0.21.1 nie egzekwują reguł kontroli dostępu na punkcie końcowym /mcp-connect, co pozwala każdemu uwierzytelnionemu użytkownikowi na połączenie z ograniczonymi serwerami MCP, jeśli zna ich identyfikator. Atakujący mogą ominąć autoryzację i uzyskać dostęp do wrażliwych systemów zaplecza.

Obot w wersjach do commit d7e6970 włącznie, gdy uruchamiany jest przez szybki start Docker z README, nasłuchuje na 0.0.0.0:8080 z wyłączonym uwierzytelnianiem. Każde żądanie jest mapowane na syntetycznego użytkownika 'nobody' z rolami Owner i Admin, co daje pełny dostęp administracyjny do API i UI Obot. Dodatkowo montowany jest /var/run/docker.sock, co daje dostęp do kontroli Docker hosta.

Obot przed v0.23.0 zawiera podatność na SSRF w rejestracji zdalnych serwerów MCP, która pozwala uprzywilejowanym użytkownikom na podawanie dowolnych adresów URL bez walidacji. Atakujący z rolą Power User lub wyższą mogą zmusić Obot do wysyłania żądań do wewnętrznych usług i punktów końcowych metadanych chmury, odczytując odpowiedzi w komunikatach błędów i ujawniając wrażliwe dane uwierzytelniające.

Obot w wersjach przed v0.23.0 nie wymusza uwierzytelniania na endpointach MCP Registry pod /v0.1/*, gdy uwierzytelnianie rejestru jest włączone. Nieuwierzytelniony atakujący może odczytać metadane rejestru, w tym nazwy serwerów, opisy, adresy URL repozytoriów i adresy URL połączeń, wysyłając żądania GET do /v0.1/servers.

Obot przed v0.23.0 (dotknięte wersje <= v0.22.1) z włączonym uwierzytelnianiem (OBOT_SERVER_ENABLE_AUTHENTICATION=true) udostępnia dynamiczną rejestrację klientów OAuth bez uwierzytelnienia i bez ograniczeń URI przekierowań. Atakujący może zarejestrować klienta wskazującego na jego domenę i przechwycić kod autoryzacyjny zalogowanego użytkownika, a następnie wymienić go na tokeny dostępu i odświeżania. Tokeny MCP OAuth niosą pełny zestaw grup ofiary w JWT, a Obot waliduje tylko issuer, nie audience, co pozwala na użycie tokena jako bearer do dowolnych endpointów API Obot, do których ofiara ma dostęp.

W produkcie zhistaredu StarTraining do wersji 3.8.1 wykryto podatność na cross-site scripting (XSS) w komponencie Upload Endpoint, w pliku MimeTypeUtils.java. Manipulacja argumentem File umożliwia zdalne przeprowadzenie ataku. Exploit jest publicznie dostępny, a producent nie odpowiedział na zgłoszenie.

W zhistaredu StarTraining do wersji 3.8.1 wykryto lukę w funkcji checkRoleAllowed w pliku SysRoleServiceImpl.java komponentu dataScope Endpoint. Manipulacja prowadzi do braku autoryzacji, a atak można przeprowadzić zdalnie.

W zhistaredu StarTraining do wersji 3.8.1 wykryto lukę w funkcji SysUser.isAdmin w pliku edu-common/src/main/java/com/edu/common/core/domain/entity/SysUser.java komponentu authRole Endpoint. Manipulacja argumentami userId/roleIds prowadzi do obejścia autoryzacji, a atak można przeprowadzić zdalnie.

W mathurvishal CloudClassroom-PHP-Project do wersji 5dadec098bfbbf3300d60c3494db3fb95b66e7be wykryto lukę w nieznanej funkcjonalności pliku registrationform.php. Manipulacja argumentami FName/LName/Addrs prowadzi do cross site scripting, a atak można przeprowadzić zdalnie.

Złośliwy rejestr OCI może utworzyć twarde dowiązania do dowolnych plików hosta w katalogu ekstrakcji, gdy użytkownik instaluje lub aktualizuje aplikację Flatpak ze zdalnego rejestru OCI. Pozwala to na ujawnienie zawartości dowolnych plików hosta.

W mathurvishal CloudClassroom-PHP-Project do wersji 5dadec098bfbbf3300d60c3494db3fb95b66e7be wykryto lukę w nieznanej funkcji pliku loginlinkstudent.php. Manipulacja argumentem umail prowadzi do braku uwierzytelniania, a atak można przeprowadzić zdalnie.

W projekcie mathurvishal CloudClassroom-PHP-Project do commit 5dadec098bfbbf3300d60c3494db3fb95b66e7be wykryto podatność w nieznanej funkcji pliku updatedetailsfromfaculty.php. Manipulacja argumentem myfid prowadzi do wstrzyknięcia SQL. Atak może być przeprowadzony zdalnie, a exploit jest publiczny.