Katalog podatności CVE

Secure BootROM układu RK3588s SoC jest podatny na atak typu time-of-check to time-of-use podczas uruchamiania z zewnętrznych nośników (SPI NOR lub NAND, EMMC lub SD). Kod dwukrotnie odczytuje nagłówek modułu ładującego następnego etapu; pierwszy odczyt jest częściowy i zawiera tylko hashe modułów, drugi jest pełny z podpisem. Autentyczność modułów jest sprawdzana na podstawie częściowych danych z pierwszego odczytu, co pozwala atakującemu z fizycznym dostępem na modyfikację danych i wykonanie dowolnego kodu z najwyższymi uprawnieniami (EL3).

Grav API Plugin przed wersją 1.0.8 przechwytuje zadania administracyjne apiKeyGenerate i apiKeyRevoke w user/plugins/api/api.php i autoryzuje wywołującego tylko przez admin.login. Podstawowy użytkownik panelu może wybrać inne konto z trasy, utworzyć trwałe poświadczenie ApiKeyManager powiązane z tym celem i odziedziczyć uprawnienia API celu, w tym api.super lub administracyjny zapis, jeśli są obecne. Problem został naprawiony w wersji 1.0.8.

Grav Shortcode Core Plugin przed wersją 6.2.2 przekazuje składnię shortcode przez Security::detectXss() bez literału '<', a następnie ColorShortcode.php i powiązane handlery atrybutów łączą kontrolowany przez atakującego parametr z HTML bez kodowania. Konto z uprawnieniem admin.pages może zamknąć wygenerowany atrybut i dodać handler zdarzeń, tworząc trwały cross-site scripting, który wykonuje się dla odwiedzających lub administratorów przeglądających stronę. Problem został naprawiony w wersji 6.2.2.

Grav przed wersją 2.0.7 zawiera podatność w Blueprint::dynamicData() w system/src/Grav/Common/Data/Blueprint.php, która przekazuje kontrolowany przez edytora dostawcę Class::method i argumenty do call_user_func_array() bez odrzucania niebezpiecznych parametrów wywołania zwrotnego. Konto z uprawnieniem admin.pages lub api.pages.write może użyć Grav\Common\Utils::arrayFilterRecursive() jako trampoliny z system jako wywołaniem zwrotnym, umieścić polecenie we frontmatter strony i wykonać je jako użytkownik serwera WWW podczas przeglądania strony. Problem został naprawiony w wersji 2.0.7.

Grav API Plugin przed wersją 1.0.0-rc.16 akceptuje JWT z parametru token w URL na każdej trasie /api/v1, w tym na punktach końcowych zmieniających stan. Żądania URL narażają ważne tokeny dostępu na logi Apache, proxy i CDN, historię przeglądarki i nagłówki Referer, co pozwala osobie z dostępem do tych rekordów na ponowne użycie tokena z uprawnieniami właściciela. Problem został naprawiony w wersji 1.0.0-rc.16.

Grav API Plugin przed wersją 1.0.0-rc.16 w CorsMiddleware zwraca Access-Control-Allow-Origin: * i permisywne odpowiedzi OPTIONS dla uwierzytelnionych punktów końcowych /api/v1. JavaScript z dowolnego pochodzenia może przesłać JWT uzyskany przez atakującego przez nagłówek Authorization lub X-API-Token, odczytać uwierzytelnioną odpowiedź i wykonać operacje zapisu z uprawnieniami właściciela tokena, umożliwiając eksfiltrację danych i modyfikację konta. Problem został naprawiony w wersji 1.0.0-rc.16.

Grav przed wersją 2.0.4 zawiera reguły bezpieczeństwa .htaccess, które porównują wzorce katalogów i rozszerzeń plików w sposób rozróżniający wielkość liter, bez flagi [NC]. Na systemach plików nie rozróżniających wielkości liter, nieuwierzytelniony atakujący może użyć wielkich liter, aby ominąć reguły i pobrać pliki z katalogów user/accounts lub user/config, w tym hasze haseł i konfigurację bezpieczeństwa. Problem naprawiono w wersji 2.0.4.

Grav przed wersją 2.0.4 zezwala na użycie filtra i funkcji regex_replace w allowliście, a GravExtension::regexReplace() przekazuje wzorzec kontrolowany przez edytora bezpośrednio do preg_replace(). Przy włączonym security.twig_content.process_enabled, uwierzytelniony edytor strony może opublikować wzorzec powodujący katastrofalne cofanie się, co obciąża CPU PHP i powoduje odmowę usługi dla odwiedzających.

Wtyczka Grav Login przed wersją 3.8.11 akceptuje zadanie login.regenerate2FASecret przez parametr URI task w żądaniu GET bez wymaganego nonce, kontroli Origin lub Referer. Przy domyślnej polityce SameSite=Lax, nawigacja z innej strony może wywołać taskRegenerate2FASecret() w sesji zalogowanego użytkownika, nadpisać jego sekret TOTP i wymusić ponowną rejestrację 2FA.

Wtyczka Grav Flex Objects przed wersją 1.4.3 ma metodę requireFlexPermission() w FlexApiController.php, która nie odmawia dostępu, gdy blueprint katalogu nie zawiera config.admin.permissions. Uwierzytelnione konto z tylko api.access może używać handlerów index, show, create, update, delete, export i media dla katalogu bez uprawnień, mimo że standardowa autoryzacja admin.flex-object by to zablokowała.

Wtyczka Grav Login przed wersją 3.8.11 zawiera podatność w zadaniu login.regenerate2FASecret, które sprawdza tylko istnienie użytkownika w sesji oczekującej, a nie wymaga autoryzacji $user->authorized. Po podaniu poprawnego hasła ofiary, atakujący może wywołać taskRegenerate2FASecret() podczas oczekującego wyzwania TOTP, nadpisać twofa_secret, odczytać nowy sekret z odpowiedzi, obliczyć ważny kod i ukończyć uwierzytelnianie bez drugiego czynnika ofiary. Problem naprawiono w wersji 3.8.11.

Podatność w Grav API Plugin (wtyczka do Grav CMS) przed wersją 1.0.6. WebhookController.php akceptuje adresy URL webhooków po tylko składniowej walidacji FILTER_VALIDATE_URL, a WebhookDispatcher.php inicjalizuje cURL bez ograniczeń CURLOPT_PROTOCOLS lub CURLOPT_REDIR_PROTOCOLS. Konto z uprawnieniami api.webhooks.write może wysyłać żądania do plików, dict, gopher, sieci prywatnych lub link-local, pobierać lokalne pliki i odpowiedzi, a także przekierowywać żądania do wewnętrznych usług lub endpointów metadanych chmury. Problem naprawiono w wersji 1.0.6.

Wtyczka Grav API przed wersją 1.0.6 zawiera podatność, w której ApiKeyManager::generateKey() przechowuje zadeklarowaną tablicę zakresów, ale ApiKeyAuthenticator::authenticate() nie odczytuje keyData[scopes] i zwraca pełną tożsamość właściciela klucza. W rezultacie AbstractApiController::requirePermission() ocenia pełne ACL użytkownika, więc klucz wydany dla zakresu tylko do odczytu może wykonywać wszystkie operacje zapisu, usuwania i administracyjne dostępne właścicielowi. Problem naprawiono w wersji 1.0.6.

Wtyczka Grav API przed wersją 1.0.6 zawiera podatność, w której metody UsersController::createApiKey(), generate2fa() i disable2fa() pomijają sprawdzenie celu accessGrantsSuper() używanego w innych endpointach mutacji użytkownika. Konto niebędące superadministratorem z uprawnieniem api.users.write może utworzyć klucz API powiązany z celem access.api.super, uzyskać pełne uprawnienia celu, ponieważ zakresy kluczy nie są egzekwowane, i stworzyć trwały dostęp superadministratora; brakujące sprawdzenie umożliwia również rotację lub wyłączenie uwierzytelniania dwuskładnikowego celu. Problem naprawiono w wersji 1.0.6.

Grav przed wersją 2.0.2 w sandboxie Twig pozwala na użycie grav.offsetGet('config') do uzyskania surowego obiektu konfiguracji oraz na serializację tego obiektu przez json_encode, print_r, yaml_encode i filtry string bez przechodzenia przez GravSecurityPolicy::checkMethodAllowed. Użytkownik z uprawnieniami edytora strony może renderować zawartość sandboxowaną, która ujawnia sekrety konfiguracji pluginów, w tym dane SMTP, klucze API i dane uwierzytelniające baz danych.

Grav przed wersją 2.0.1 w metodzie ZipArchiver::extract() przekazuje archiwa do ZipArchive::extractTo() bez egzekwowania limitów rozmiaru, liczby plików i głębokości zagnieżdżenia z system.gpm.archive. Kod używający Archiver::create('zip') do rozpakowania archiwum kontrolowanego przez atakującego może wyczerpać miejsce na dysku lub inody, czyniąc stronę niedostępną.

Wtyczka Grav API przed wersją 1.0.2 w procesie POST /api/v1/media w HandlesMediaUploads::processUploadedFile() waliduje rozszerzenie pliku SVG, ale nie wywołuje Security::sanitizeSVG(). Atakujący z uprawnieniem api.media.write może przechowywać SVG zawierający JavaScript, a serwer zwraca plik jako Content-Type: image/svg+xml, co powoduje wykonanie skryptu po otwarciu przez ofiarę, umożliwiając kradzież danych sesji i autoryzowane działania.

Grav przed wersją 3.8.5 w zadaniu twofa_cancel wtyczki Login akceptuje kontrolowane przez klienta pole _redirect bez nonce i pozwala nieuwierzytelnionemu żądaniu ustawić zewnętrzny cel Location (http, https lub protocol-relative). Controller::execute() stosuje to pole, gdy taskTwofa_cancel() nie ustawia przekierowania, a Grav::getRedirectResponse() akceptuje cel przez Uri::isExternal(), umożliwiając phishingowe przekierowania z zaufanego hosta Grav.

Wazuh od wersji 4.0.0 do 4.14.6 oraz 5.0.0-beta2 zawiera podatność w funkcji WazuhCommon.end_receiving_file() w framework/wazuh/core/cluster/common.py, która pozwala uwierzytelnionemu węzłowi klastra na usuwanie plików poza ścieżką WAZUH_PATH. Żądanie syn_i_w_m_e z nieznanym task_id dociera do gałęzi czyszczącej, gdzie nazwa pliku kontrolowana przez atakującego jest przekazywana do os.path.join bez kanonizacji lub ograniczeń. Ścieżki bezwzględne i sekwencje traversal mogą celować w pliki takie jak ossec.conf, jwt_secret.json, certyfikaty TLS i pliki reguł, które są dostępne dla procesu menedżera Wazuh. Usunięcie może wyłączyć menedżera, unieważnić tokeny API lub zakłócić łączność klastra i API. Problem naprawiono w wersjach 4.14.6 i 5.0.0-beta2.

W Wazuh od wersji 1.0.0 do 4.14.6 oraz 5.0.0-beta2 występuje podatność polegająca na zapisie poza granicami bufora na stosie w funkcji HandleSecureMessage(). Podczas przetwarzania zaszyfrowanej wiadomości agenta na porcie TCP 1514, dekompresja może zapisać bajt null poza końcem bufora docelowego, co prowadzi do awarii procesu remoted i zakłócenia komunikacji z agentami.