CVE-2026-120487

LaraDashboard przed wersją 1.4.9 zawiera podatność typu stored cross-site scripting, która pozwala uwierzytelnionym użytkownikom z uprawnieniami post.create lub post.edit wstrzyknąć skrypty poprzez nieoczyszczoną zawartość bloków design_json w LaraBuilder. Atakujący mogą zapisać bloki text-editor, HTML, text lub heading zawierające skrypt lub znaczniki obsługi zdarzeń, które wykonują się w sesjach administratorów.

LaraDashboard 1.4.0 przed 1.4.9 zawiera podatność nieprawidłowej autoryzacji, która pozwala uwierzytelnionym użytkownikom z uprawnieniem tylko do odczytu email_template.view wysyłać dowolne e-maile przez narzędzie MCP send-email. Atakujący może wygenerować token MCP i wywołać send-email z dowolnym odbiorcą, tematem i treścią HTML.

LaraDashboard od wersji 1.4.0 do 1.4.8 zawiera podatność typu race condition w RegisterController::register, która pozwala nieuwierzytelnionym atakującym obejść dzienny limit rejestracji na IP. Atakujący mogą wysłać wiele równoczesnych żądań rejestracji z jednego IP, tak aby wszystkie przeszły RegistrationGuardService::hasExceededIpLimit przed wykonaniem recordRegistration, tworząc konta masowo i obchodząc mechanizmy antyautomatyzacyjne.

LaraDashboard przed wersją 1.4.8 zawiera podatność nieprawidłowej autoryzacji, która pozwala uwierzytelnionym użytkownikom z jedynie uprawnieniem settings.view odczytywać przechowywane sekrety poprzez API ustawień. Atakujący mogą odpytywać GET /api/settings lub /api/settings/{option_name}, aby uzyskać tekstowe klucze API dostawców AI, dane logowania do poczty, hasła i tokeny.

LaraDashboard przed wersją 1.4.8 zawiera podatność otwartego przekierowania, która pozwala zdalnym atakującym przekierowywać użytkowników poprzez dostarczenie niezwalidowanego parametru redirect_url do EmailTemplateController builder i builderEdit. Atakujący mogą wysyłać spreparowane linki builder do zalogowanych użytkowników z uprawnieniami do szablonów e-mail, aby zapisanie szablonu przeniosło ich do witryn phishingowych kontrolowanych przez atakującego.

LaraDashboard w wersjach od 1.4.2 do 1.4.8 stosuje zaawansowaną walidację adresów e-mail w żądaniach resetowania hasła dla niezalogowanych użytkowników, co wywołuje zapytania DNS oraz płatne weryfikacje AbstractAPI. Nieuwierzytelniony atakujący może wysyłać dowolne adresy, aby wyczerpać limit weryfikacji, powodując, że walidacja przestaje działać (fail open) dla wszystkich publicznych formularzy, oraz może sondować rozwiązywanie domen.

LaraDashboard przed wersją 1.4.8 zawiera podatność niewłaściwego zarządzania uprawnieniami, która pozwala uwierzytelnionym administratorom na eskalację do Superadmina poprzez edycję lub zmianę nazwy ról. Atakujący z uprawnieniem role.edit może zmienić nazwę swojej roli na Superadmin lub przyznać uprawnienia user.login_as, aby przejąć konta i uzyskać dostęp do funkcji aktualizacji rdzenia oraz instalacji modułów, co umożliwia wykonanie kodu.

LaraDashboard przed wersją 1.4.8 zawiera podatność typu path traversal, która pozwala nieuwierzytelnionym atakującym odczytywać pliki JSON poprzez manipulację segmentem trasy {lang}. Na hostach Windows atakujący mogą wysyłać sekwencje zakodowane w URL, takie jak ..%5C, aby wyjść poza resources/lang i odczytać composer.json lub inne pliki JSON aplikacji.

laradashboard do wersji 1.2.2 zawiera podatność braku autoryzacji w endpointach Local License API, która pozwala każdemu uwierzytelnionemu użytkownikowi odczytywać, nadpisywać i usuwać klucze licencji modułów premium. Atakujący z kontem o niskich uprawnieniach może uzyskać dostęp do endpointów GET /api/admin/licenses/show, POST /api/admin/licenses/store i POST /api/admin/licenses/remove, aby ujawnić poufne klucze licencji, wstrzyknąć wartości kontrolowane przez atakującego lub całkowicie usunąć przechowywane licencje.

LaraDashboard w wersjach 0.9.2 do 1.2.2 zawiera podatność na path traversal w obsłudze kopii zapasowych podczas aktualizacji rdzenia. CoreUpgradeController i BackupService łączą wartość backup_file/filename dostarczoną przez użytkownika bezpośrednio ze ścieżką katalogu kopii zapasowych bez normalizacji, bez basename() i bez weryfikacji, że wynikowa ścieżka pozostaje w storage/app/core-backups; uwierzytelniony użytkownik z uprawnieniem settings.edit może podać sekwencje ../, aby usunąć dowolne pliki lub przywrócić archiwum ZIP z dowolnej lokalizacji, zapisując dowolne pliki w katalogach aplikacji i osiągając zdalne wykonanie kodu.