CVE-2026-42843

Plugin Grav API (getgrav/grav-plugin-api) przed wersją 1.0.18 nie egzekwuje ograniczeń zakresu klucza API w funkcji injectSecurityTab() klasy BlueprintController. Osoba posiadająca klucz API z ograniczonym zakresem może zobaczyć i potencjalnie edytować pola uprawnień strony poza przyznanym zakresem.

Wtyczka Grav API (getgrav/grav-plugin-api, dołączona do stosu admin-next/API Grav) przed wersją 1.0.14 nie egzekwuje wymogu autoryzacji w MenubarController::executeAction(). Podczas gdy punkt końcowy GET /menubar/items poprawnie filtruje elementy paska menu przez userPassesAuthorize(), punkt końcowy POST /api/v1/menubar/actions/{plugin}/{action} sprawdza tylko podstawowe uprawnienie api.access i nigdy nie ocenia pola authorize, które wtyczka zarejestrowała dla tej akcji. Każdy uwierzytelniony wywołujący z api.access może zatem bezpośrednio wywołać uprzywilejowaną akcję paska menu, omijając zamierzoną autoryzację. Żadna wtyczka dołączona do rdzenia Grav nie rejestruje obecnie uprzywilejowanego handlera authorize, więc na standardowej instalacji wpływ jest utajony; wada dotyczy każdej wtyczki pierwszej lub trzeciej strony polegającej na udokumentowanej semantyce authorize.

Wtyczka Grav API (getgrav/grav-plugin-api) przed wersją 1.0.14 zawiera podatność braku autoryzacji w funkcji userPassesAuthorize() (AbstractApiController.php). Funkcja nie sprawdza zakresów klucza API żądania, opierając się zamiast tego na surowym flagu super-admina i uprawnieniach ACL. W rezultacie uwierzytelniony atakujący posiadający klucz API z ograniczonym zakresem, wybity na koncie z uprawnieniami administratora, może ominąć deklarowane ograniczenia zakresu i uzyskać dostęp do metadanych UI i definicji elementów (sidebar/menubar/widget items oraz users-list columns/row-actions/filter-tabs), które powinny być dla niego zabronione, co prowadzi do ujawnienia informacji.

Wtyczka Grav API (getgrav/grav-plugin-api, dołączona do Grav 2.0 w stosie admin-next/API) przed wersją 1.0.14 zawiera słabość otwartego przekierowania w SsoController::sanitizeReturnTo(). Funkcja odrzuca dosłowny prefiks '//', ale nie uwzględnia normalizacji backslashy do slashy przez przeglądarki w specjalnych schematach (http/https), więc wartość returnTo taka jak '/\evil.com' przechodzi przez zabezpieczenie i jest później rozwiązywana przez przeglądarkę jako URL względny protokołu '//evil.com'. Po legalnym przepływie logowania OAuth, parametr returnTo dostarczony przez atakującego może przekierować uwierzytelnioną ofiarę na stronę kontrolowaną przez atakującego w celu phishingu po zalogowaniu. Pełna eksploitowalność po stronie przeglądarki zależy od handlera oauth-callback po stronie klienta w admin-next SPA i nie została niezależnie zweryfikowana przez reportera.

Wtyczka Grav API przed wersją 1.0.3 nie oczyszcza plików SVG przesyłanych przez endpoint POST /api/v1/media. Metoda processUploadedFile() sprawdza tylko rozszerzenie pliku, nie wywołując Security::sanitizeSVG(), co pozwala uwierzytelnionemu atakującemu z uprawnieniem api.media.write na przesłanie SVG z dowolnym kodem JavaScript. Plik jest przechowywany bez zmian i serwowany z Content-Type: image/svg+xml; gdy administrator otworzy go w przeglądarce, osadzony skrypt wykonuje się w kontekście jego sesji, umożliwiając kradzież ciasteczek i przejęcie sesji.

Wtyczka Grav API przed wersją 1.0.0-rc.16 akceptuje tokeny JWT w parametrze URL ?token= i odpowiada nagłówkiem Access-Control-Allow-Origin: *, co pozwala nieuwierzytelnionym atakującym na wykonywanie w pełni uwierzytelnionych żądań API z dowolnej złośliwej strony. Atakujący, którzy zdobędą wyciekły token JWT z logów dostępu, logów proxy, historii przeglądarki lub nagłówków Referrer, mogą utworzyć trwałe konta super-admina i wykraść wrażliwe dane konfiguracyjne oraz użytkowników.

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 (grav-plugin-api) przed wersją 1.0.8 nieprawidłowo autoryzuje generowanie i odwoływanie kluczy API. Przechwytuje zadania administracyjne apiKeyGenerate/apiKeyRevoke przed wykonaniem ACL zarządzania kontami i autoryzuje wywołującego tylko na podstawie uprawnienia admin.login (podstawowe uprawnienie posiadane przez każdego użytkownika panelu). Umożliwia to każdemu użytkownikowi z admin.login wygenerowanie trwałego klucza API powiązanego z dowolnym kontem, a sfałszowany klucz dziedziczy uprawnienia API konta docelowego. W instalacjach, gdzie konto z włączonym API ma szersze uprawnienia, umożliwia to podszywanie się pod konto i eskalację uprawnień aż do przejęcia konta.

Wtyczka Grav API (grav-plugin-api) przed wersją 1.0.4 nie weryfikuje pochodzenia pola admin_base_url w punkcie końcowym POST /api/v1/auth/forgot-password. Funkcja sanitizeHttpUrl() sprawdza tylko schemat URL (http/https), ale nie sprawdza hosta względem własnego serwera, co pozwala atakującemu na podstawienie dowolnego hosta. Nieuwierzytelniony atakujący może spowodować, że e-mail resetujący hasło wysłany do ofiary będzie zawierał link prowadzący do serwera kontrolowanego przez atakującego; gdy ofiara kliknie link, prawidłowy token resetujący zostaje ujawniony atakującemu, co umożliwia pełne przejęcie konta.

Wtyczka Grav API przed wersją 1.0.16 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w dostarczaniu webhooków, która pozwala atakującym ominąć walidację nazwy hosta przez ponowne wiązanie DNS. Atakujący kontrolujący autorytatywny DNS dla skonfigurowanej nazwy hosta webhooka mogą odpowiadać na zapytania walidacyjne publicznymi adresami, a na zapytania dostarczania prywatnymi adresami, aby dotrzeć do wewnętrznych zasobów sieciowych.