Katalog podatności CVE

W Pi-hole przed wersją 6.5 funkcja getFTLPID() w utils.sh waliduje plik /run/pihole-FTL.pid za pomocą expr, odrzucając tylko wartości, których pierwszy znak nie jest cyfrą. Atakujący z kodem wykonawczym jako pihole może zapisać wyrażenie arytmetyczne zaczynające się od cyfry, które jest następnie ewaluowane przez Bash jako root, umożliwiając wykonanie podstawienia poleceń.

W draw.io Desktop przed wersją 31.5.2 aplikacja Windows uruchamiała powershell i attrib po samej nazwie pliku wykonawczego. Gdy draw.io nie był uruchomiony, otwarcie diagramu z Eksploratora plików ustawiało katalog diagramu jako bieżący katalog roboczy, umożliwiając uruchomienie podstawionego powershell.bat lub attrib.exe z tego katalogu.

W przeglądarce Ladybird przed commitem 209579c funkcja FinalizationRegistry::cleanup() usuwała martwy rekord, zachowywała iterator do następnego rekordu, a następnie wywoływała kontrolowany przez atakującego kod JavaScript. Jeśli callback wywołał unregister() dla następnego rekordu, zachowany iterator wskazywał na zwolniony węzeł, a kolejna iteracja czytała jego pola po zwolnieniu.

W przeglądarce Ladybird przed commitem c0d68bd funkcje CSSStyleSheet.cssRules, insertRule() i deleteRule() nie egzekwowały flagi origin-clean arkusza stylów wymaganym błędem SecurityError, mimo że importowane arkusze cross-origin były poprawnie oznaczane jako nie-origin-clean. Złośliwa strona mogła odczytywać reguły oraz wstawiać i usuwać reguły w arkuszu ofiary, omijając politykę Same-Origin.

W trybie serwera pgAdmin 4 przed wersją 9.19 funkcja get_complete_file_path() usuwała tylko wiodące ukośniki przed połączeniem ścieżki, więc ścieżka typu ../<inny użytkownik>/.pgpass mogła wskazać plik innego użytkownika. Parametr sslkeylogfile był przekazywany do libpq bez zmian, a make_conninfo() nie cytowało nazw parametrów, co pozwalało przemycić dodatkowe pary klucz=wartość.

W pgAdmin 4 przed wersją 9.19, gdy serwer nie miał skonfigurowanego pliku haseł, certyfikatu klienta lub klucza klienta albo wskazany plik nie istniał, pgAdmin pomijał parametr w połączeniu, a libpq używał domyślnych plików konta systemowego uruchamiającego pgAdmin. W trybie serwera każdy użytkownik mógł więc łączyć się z serwerem przy użyciu zapisanych haseł lub certyfikatu konta usługi.

W pgAdmin 4 w trybie serwera libpq wyszukuje usługi połączeń w pliku usług konta systemowego, co pozwala użytkownikom na użycie poświadczeń lub plików certyfikatów tego konta. Podatność dotyczy wersji przed 9.19 i może prowadzić do nieautoryzowanego dostępu do serwerów baz danych.

W pgAdmin 4 w trybie serwera usunięcie KRB5CCNAME powodowało, że biblioteka Kerberos używała domyślnego cache poświadczeń konta systemowego, umożliwiając każdemu użytkownikowi połączenie jako principal usługi. Podatność dotyczy wersji przed 9.19 i obejmuje również obejście gssencmode=disable oraz zachowanie SSPI w Windows.

W pgAdmin 4 w trybie serwera ścieżka binarna ustawiona przez użytkownika nie była weryfikowana względem katalogów SHARED_STORAGE, co pozwalało na przesłanie pliku wykonywalnego i uruchomienie go jako konto systemowe pgAdmin. Podatność jest szczególnie istotna w Windows, gdzie pliki mogą być wykonywalne, i dotyczy wersji przed 9.19.

W pgAdmin 4 w trybie serwera biblioteka sshtunnel zawsze ładowała niezaszyfrowane klucze prywatne z ~/.ssh konta systemowego i czytała jego konfigurację SSH, umożliwiając każdemu użytkownikowi skonfigurowanie tunelu z użyciem tożsamości konta usługi. Podatność dotyczy wersji przed 9.19.

W trybie serwera pgAdmin 4 prowadzi osobne konta dla każdego źródła uwierzytelniania, więc ta sama nazwa użytkownika może istnieć jako konto wewnętrzne i LDAP. Po uwierzytelnieniu przez LDAP lub Kerberos pgAdmin wybierał konto do zalogowania wyłącznie na podstawie nazwy użytkownika, bez sprawdzenia źródła uwierzytelnienia, co pozwalało na przejęcie sesji innego konta wraz z jego rolami, serwerami i zapisanymi hasłami do baz danych.

W trybie serwerowym pgAdmin 4 mechanizm blokady konta wewnętrznego po przekroczeniu limitu nieudanych logowań (domyślnie 3) można obejść na kilka sposobów. Luki w widokach Flask-Security, w dopasowywaniu nazwy użytkownika (wielkość liter) oraz w interakcji z innymi źródłami uwierzytelniania (LDAP, webserver, Kerberos) pozwalają nieuwierzytelnionemu atakującemu na nieograniczone zgadywanie haseł do dowolnego konta wewnętrznego, w tym administratora. Dodatkowo możliwe są nieautoryzowane resetowania haseł i ujawnienie konfiguracji serwera w oknie About.

W Secret Server w wersjach starszych niż 12.3.1 użytkownik w pewnych warunkach mógł przesłać niepodpisany JWT i otrzymać w odpowiedzi uprawnienia cloudadmin. Podatność pozwala na eskalację uprawnień do poziomu administracyjnego.

W Secret Server w wersjach starszych niż 12.3.1 użytkownik mógł pominąć początkowy krok logowania i uwierzytelnić się, pomyślnie negocjując jedynie drugi etap logowania (drugi czynnik). Podatność omija pierwszy czynnik uwierzytelniania.

Wtyczka WordPress All In One Login w wersjach do 2.4.1 zawiera podatność na cross-site scripting (XSS), którą można wykorzystać bez uwierzytelnienia.

Wtyczka WordPress GS Testimonial Slider w wersjach do 3.3.10 zawiera podatność na wstrzyknięcie obiektu PHP (PHP Object Injection) możliwą do wykorzystania przez użytkownika z rolą współautora.

Wtyczka WordPress Enable Media Replace w wersjach do 4.2.2 zawiera podatność na wstrzyknięcie obiektu PHP (PHP Object Injection) możliwą do wykorzystania przez użytkownika z rolą subskrybenta.

praktor to orkiestrator Claude Code z obsługą Telegrama, izolacją Dockera i interfejsem Mission Control. W wersjach przed 0.9.1 oba miejsca przesyłania plików w Telegramie w `internal/telegram/bot.go` łączą nazwę pliku kontrolowaną przez atakującego ze ścieżką docelową bez sanityzacji, a `path.Join` redukuje przejście do katalogu nadrzędnego. Zdalny użytkownik Telegrama mogący wysłać wiadomość do bota może zapisywać poza `uploads/` w trwałym obszarze roboczym agenta zamontowanym w `/workspace/agent`; ponieważ `allow_from: []` domyślnie zezwala wszystkim nadawcom, w tej konfiguracji nie jest wymagane wcześniejsze uwierzytelnienie. Atakujący może umieścić lub nadpisać pliki `CLAUDE.md`, instrukcji, umiejętności, hooków lub konfiguracji, które agent Claude odczytuje i na których działa w kolejnych uruchomieniach, zamieniając przesłanie dokumentu w trwałe wstrzyknięcie instrukcji. Zademonstrowany zakres dowolnego zapisu to trwały wolumen obszaru roboczego agenta, a nie nieograniczony zapis do systemu plików hosta. Problem naprawiono w wersji 0.9.1.

W serwerze MCP do odczytu PDF (PDF Reader MCP) w wersjach 2.2.0–3.0.0, po włączeniu transportu HTTP, nagłówek X-API-Key nie jest w ogóle weryfikowany, mimo że logi startowe informują o włączonej autoryzacji. W efekcie endpoint /mcp przyjmuje nieuwierzytelnionych klientów, a przy domyślnym adresie 0.0.0.0 każdy, kto ma dostęp do portu, może wywoływać narzędzia PDF i czytać pliki PDF dostępne dla procesu serwera. Źródła URL pozwalają też na ograniczony SSRF (prywatne adresy i loopback są domyślnie blokowane).

W Hydra (warstwa skalowalności L2 dla Cardano) przed wersją 2.1.0 gałąź Claim w walidatorze depozytu sprawdza jedynie zgodność datum.head_id z kontrolowanym przez atakującego redeemer.currencySymbol oraz ważność transakcji przed terminem depozytu. Nie wymaga wydania UTxO tokena stanu Head w tej samej transakcji ani nie ogranicza wyjść, więc po potwierdzeniu depozytu przez POST /commit dowolna strona trzecia może przejąć oczekujące UTxO depozytu i przekierować środki na dowolny adres.