Katalog podatności CVE

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.

W Wazuh od wersji 3.9.0 do 4.14.5 oraz 5.0.0-beta2 protokół klastra pozwala uwierzytelnionemu węzłowi klastra na wyczerpanie pamięci na serwerze głównym. Metoda receive_str() akceptuje kontrolowaną przez atakującego wartość całkowitą bez limitu, a ścieżka podzielonych wiadomości przechowuje fragmenty bez ograniczeń, co może prowadzić do nadmiernego zużycia pamięci.

Wazuh Manager od wersji 4.0.0 do 4.14.5 pozwala użytkownikowi API o niskich uprawnieniach (tylko do odczytu) z uprawnieniem manager:read na pobranie klucza klastra z elementu w ossec.conf przez GET /manager/configuration?raw=true. Atakujący z dostępem sieciowym do portu TCP 1516 może użyć ujawnionego klucza Fernet do podszycia się pod pracownika klastra i wysyłać rozproszone żądania API z kontrolowanymi rbac_permissions i rbac_mode ustawionym na black. Ponieważ master ufa kontekstowi autoryzacji dostarczonemu przez pracownika, atakujący może tworzyć użytkowników, przypisywać role administratora, uzyskiwać dostęp do poświadczeń i tokenów API, modyfikować konfigurację i wykonywać akcje na agentach. Problem naprawiono w wersji 4.14.5.

Moduł tarfile w Pythonie ma podatność w filtrach ekstrakcji danych, która pozwala na tworzenie katalogów poza docelowym katalogiem dla członków archiwum, których nazwa wychodzi poza katalog docelowy i do niego wraca (np. ../evil/../dest/sub/file). Problem dotyczy tylko platform POSIX i tworzy tylko puste katalogi poza docelowym.

HumHub 1.18.4 zawiera podatność na przechowywany cross-site scripting (XSS) w przepływie powiadomień o usunięciu komentarza. Administrator przestrzeni może usunąć komentarz innego użytkownika, wybrać opcję powiadomienia autora i umieścić HTML/JavaScript w polu przyczyny usunięcia.

IBM AIX 7.2 i 7.3 oraz IBM PowerVM VIOS 4.1 mogą pozwolić lokalnemu atakującemu na spowodowanie odmowy usługi i naruszenie integralności danych z powodu warunku wyścigu typu time-of-check time-of-use (TOCTOU).