CVE-2026-56710

Grav to platforma internetowa oparta na plikach. W wersjach przed 2.0.0-beta.2 metoda Login::register() wtyczki Login akceptuje grupy i pola dostępu kontrolowane przez atakującego bez walidacji po stronie serwera.

Wtyczka Grav Login od 3.6.0 przed 3.9.13 zawiera lukę braku autoryzacji w zadaniu login.invite, która pozwala autorom stron na uzyskanie kont superużytkownika. Atakujący może zdefiniować w frontmatter strony formularz zaproszenia przyznający uprawnienia super, przesłać go bez uwierzytelnienia i zarejestrować zaproszony adres z pełną kontrolą nad witryną.

Grav Login plugin od wersji 1.2.0 przed 3.9.9 zawiera podatność ujawniania informacji, która pozwala wydawcom na uzyskanie tokenów resetowania hasła poprzez utworzenie strony w ścieżce resetowania. Gdy ofiara otworzy wysłany e-mailem link resetujący, strona kontrolowana przez wydawcę, renderowana przez Login::getPage(), ujawnia nazwę użytkownika i token bearer, umożliwiając przejęcie kont o wyższych uprawnieniach.

Wtyczka Grav Login w wersjach od 2.7.0 do 3.9.9 zawiera podatność na ominięcie uwierzytelniania, która pozwala atakującemu z ważnym hasłem pominąć dwuskładnikowe uwierzytelnianie (2FA) poprzez przywrócenie trwałego ciasteczka remember-me. Atakujący może uzyskać takie ciasteczko po kroku z hasłem i przywrócić je jako w pełni autoryzowaną sesję bez ukończenia drugiego składnika.

Wtyczka Grav Login w wersjach od 2.7.0 do 3.9.9 zawiera podatność na ominięcie uwierzytelniania w funkcji processUserProfile(), która sprawdza, czy użytkownik sesji istnieje, ale nie sprawdza, czy oczekująca sesja 2FA jest w pełni autoryzowana. Atakujący z hasłem ofiary, który może opublikować formularz strony bez reguły dostępu, może wywołać update_user przed ukończeniem 2FA, aby wyłączyć twofa_enabled i przejąć konto.

Wtyczka getgrav/grav-plugin-login Composer przed wersją 3.9.1 (używana przez Grav) porównuje tokeny resetowania hasła i aktywacji konta za pomocą nie-stałoczasowego porównania === zamiast hash_equals() w classes/Controller.php (taskReset()) i login.php (obsługa aktywacji). Ponieważ punkt końcowy przesyłania tokena (taskReset) nie ma również ograniczenia szybkości, atakujący może w zasadzie wysyłać wielokrotne zgadywania tokenów dla znanej nazwy użytkownika i wykorzystać różnice czasowe, aby próbować odzyskać prawidłowy token, chociaż dostawca ocenia praktyczną możliwość wykorzystania jako niską i nie zademonstrowano ataku sieciowego od końca do końca.

Wtyczka Grav Login (getgrav/grav-plugin-login) przed wersją 3.9.1 jest podatna na enumerację adresów e-mail. Metoda register() w classes/Login.php wyrzuca odrębny wyjątek (EMAIL_NOT_AVAILABLE), gdy podany adres e-mail już należy do istniejącego konta, podczas gdy w przeciwnym razie rejestracja przebiega dalej. Ponieważ punkt końcowy rejestracji nie ma ograniczeń tempa, atakujący może enumerować, które adresy e-mail mają konta na stronie, zgadując jedno żądanie na raz.

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

Wtyczka Grav Login przed wersją 3.8.13 zawiera podatność na niewystarczające wygaśnięcie sesji w pliku TokenStorage.php, gdzie metoda findTriplet() nieprawidłowo waliduje znaczniki czasu tokenów Remember Me. Atakujący z przechwyconym ciasteczkiem Remember Me może uwierzytelniać się w nieskończoność, zamiast przez skonfigurowany okres limitu czasu, ponieważ sprawdzanie wygaśnięcia porównuje tablicę z wartością skalarną, co w PHP zawsze daje nieprawidłowy wynik.