Katalog podatności CVE

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 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.

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ń.

@neo4j/graphql od wersji 5.2.0 do wersji przed poprawką nie egzekwuje reguł autoryzacji na poziomie pól dla niestandardowych resolverów, gdy na tym samym typie operacji istnieje również reguła na poziomie typu. Reguła na poziomie pola jest ignorowana, co pozwala klientowi spełniającemu słabszą regułę na wywołanie bardziej restrykcyjnego pola.

Hugo 0.162.0 dodał tailwindcss do domyślnej listy AllowChildProcess, co powoduje, że proces Node.js uruchamiany dla TailwindCSS ma uprawnienia do uruchamiania procesów potomnych. Top-level kod w tailwind.config.js może wykonać dowolne polecenia, omijając model uprawnień Node.js.

CodeWhale przed wersją 0.8.64 zawiera podatność na ujawnienie zmiennych środowiskowych w narzędziu js_execution, które nie czyści zmiennych środowiskowych procesu nadrzędnego przed uruchomieniem Node.js. Atakujący może wykonać złośliwy kod JavaScript, który odczyta process.env i wycieknie klucze API, poświadczenia chmurowe i tokeny uwierzytelniające.

CodeWhale przed wersją 0.8.64 zawiera podatność na przechodzenie poza katalog (path traversal) w narzędziu image_analyze, które nie kanonizuje dowiązań symbolicznych przed odczytem plików. Atakujący może utworzyć dowiązania symboliczne w przestrzeni roboczej wskazujące na zewnętrzne pliki z rozszerzeniami obrazów, aby wyciec ich zawartość do punktu końcowego wizji bez zgody użytkownika.

CodeWhale przed wersją 0.8.64 zawiera podatność na wstrzykiwanie argumentów w narzędziu git_blame, która pozwala atakującym czytać dowolne pliki poprzez wstrzyknięcie opcji git do niezweryfikowanego parametru rev. Atakujący może podać wartości rev takie jak --contents=/path/to/file, aby wyeksfiltrować wrażliwe pliki, takie jak klucze SSH i poświadczenia.

CodeWhale przed wersją 0.8.64 nieprawidłowo waliduje parametr allow_shell w plikach konfiguracyjnych projektu, co pozwala atakującym na włączenie wykonywania dowolnych poleceń powłoki poprzez umieszczenie złośliwego pliku .codewhale/config.toml w repozytorium. Gdy użytkownik sklonuje i otworzy repozytorium w CodeWhale, model AI uzyskuje dostęp do narzędzi exec_shell i task_shell, umożliwiając wykonanie dowolnych poleceń powłoki na maszynie ofiary bez wyraźnej zgody użytkownika.

CodeWhale przed wersją 0.8.64 nie waliduje ścieżek plików w polu instructions konfiguracji projektu, co pozwala atakującym na odczyt dowolnych plików na systemie ofiary. Złośliwy plik .codewhale/config.toml w sklonowanym repozytorium może wskazywać ścieżki poza obszarem roboczym, które są odczytywane i wstrzykiwane do promptu systemowego AI w celu eksfiltracji.

CodeWhale (pakiety codewhale / codewhale-tui) w wersjach >= 0.8.41 i < 0.8.64 zawiera podatność na zdalne wykonanie kodu w narzędziu rlm_eval. Funkcja approval_requirement() zwraca ApprovalRequirement::Auto, co silnik traktuje jako 'nigdy nie pytaj', powodując wykonanie dowolnego kodu Python dostarczonego przez model w interpreterze python3 bez uwzględnienia skonfigurowanej polityki --approval-policy i bez żadnego promptu zatwierdzającego ani kroku audytu. Atakujący może nakłonić agenta do wykonania dowolnego kodu poprzez wstrzyknięcie promptu w niezaufanej treści, którą agent czyta (strona internetowa, pobrany URL, plik repozytorium lub wynik narzędzia MCP); towarzyszące narzędzie rlm_open może przygotować taką treść. Kod wykonuje się na maszynie użytkownika z jego uprawnieniami. Poprawiono w wersji 0.8.64.

CodeWhale w wersjach >= 0.8.41 i < 0.8.64 zawiera podatność w narzędziu exec_shell_interact (alias exec_interact), którego funkcja approval_requirement zwraca ApprovalRequirement::Auto. To nadpisuje domyślne wymaganie Required dla narzędzi wykonujących kod, więc stdin kontrolowane przez LLM jest zapisywane do już zatwierdzonej długotrwałej interaktywnej powłoki (np. python3 -i REPL, mysql, ssh lub sesja sudo -i) bez żadnego promptu zatwierdzającego. Atakujący, który może wstrzyknąć instrukcje poprzez niezaufaną treść, którą agent przetwarza (pobrana strona, wynik MCP lub plik repozytorium), może spowodować wykonanie poleceń z uprawnieniami tego zatwierdzonego procesu. Poprawiono w wersji 0.8.64.

CodeWhale przed wersją 0.8.64 zawiera podatność na obejście server-side request forgery (SSRF) w logice pinning DNS, która nie zapobiega atakom typu time-of-check-time-of-use. Atakujący mogą manipulować odpowiedziami DNS, aby nie przechodziły one wstępnych kontroli rozwiązywania, a następnie przechodziły w kolejnych żądaniach, co pozwala na wysyłanie żądań do wewnętrznych adresów IP i obejście zabezpieczeń SSRF.

Joomla! Core w wersjach 1.0.0-5.4.7 oraz 6.0.0-6.1.2 ma podatność na nieograniczone przesyłanie plików SHTML. Domyślna lista niebezpiecznych plików nie zawierała plików SHTML, co na serwerach wykonujących te pliki może prowadzić do wykonania kodu.

Joomla! Core w wersjach 4.0.0-5.4.7 oraz 6.0.0-6.1.2 ma podatność na obejście uwierzytelniania MFA. Niewystarczające kontrole stanu prowadzą do wektora, który pozwala na obejście kontroli 2FA.