Katalog podatności CVE

phpMyFAQ 4.2.0-alpha przed 4.2.0-beta zawiera podatność stored XSS w SvgSanitizer, która pozwala użytkownikom z uprawnieniem FAQ_EDIT obejść sanityzację przy użyciu niestandardowych encji XML DTD. Atakujący mogą przesłać SVG definujący encję rozwijającą się do javascript w href kotwicy, wykonując skrypt, gdy widzowie klikną, aby przejąć sesje administratora.

phpMyFAQ 4.2.0-alpha przed 4.2.0-beta zawiera podatność obejścia autoryzacji w isFaqAccessibleForUser(), która traktuje brakujące tłumaczenie FAQ jako widoczne dla nieuwierzytelnionych użytkowników. Atakujący mogą wysłać niedopasowany nagłówek Accept-Language do endpointów API komentarzy i załączników, aby odczytać komentarze i listy załączników nieopublikowanych lub ograniczonych ACL FAQ.

phpMyFAQ w wersjach 4.2.0-alpha przed 4.2.0-beta zawiera lukę niekontrolowanego zużycia zasobów w nieuwierzytelnionych endpointach API faqs i search. Atakujący może wysyłać równoczesne żądania GET, które ładują i przetwarzają wszystkie rekordy bazy danych do pamięci PHP, wyczerpując CPU i pamięć, co powoduje awarię serwera.

phpMyFAQ przed 4.1.9 oraz 4.2.0-alpha przed 4.2.0-beta zawiera podatność niewłaściwej autoryzacji w attachment.php, która nie weryfikuje, czy nadrzędny FAQ załącznika jest opublikowany lub widoczny dla żądającego. Uwierzytelnieni użytkownicy z uprawnieniem dlattachment mogą żądać index.php?action=attachment&id=<ID>, aby pobrać pełne pliki załączników należących do szkiców FAQ.

phpMyFAQ w wersjach 4.2.0-alpha przed 4.2.0-beta zawiera lukę obejścia uwierzytelniania, która pozwala użytkownikom Keycloak na przejęcie lokalnych kont poprzez dopasowanie preferred_username lub email. Atakujący kontrolujący tożsamość Keycloak ze kolidującą nazwą użytkownika lub niezweryfikowanym adresem email może zalogować się przez /auth/keycloak/authorize, aby powiązać swój podmiot i uzyskać uprawnienia superadmina.

phpMyFAQ w wersjach 4.2.0-alpha przed 4.2.0-beta zawiera lukę obejścia autoryzacji, która pozwala edytorom z ograniczeniami kategorii na zarządzanie załącznikami FAQ spoza ich kategorii poprzez podanie dowolnych identyfikatorów rekordów. Atakujący w trybie średnich uprawnień może wysyłać żądania przesłania lub usunięcia z docelowym record_id lub identyfikatorem załącznika, aby manipulować lub usuwać pliki w nieautoryzowanych FAQ.

phpMyFAQ od 4.2.0-alpha przed 4.2.0-beta zawiera podatność stored XSS w SvgSanitizer, która pozwala edytorom FAQ przechowywać wykonywalne pliki SVG. Atakujący mogą podzielić tagi script wokół usuniętych tokenów, takich jak instrukcje przetwarzania, aby jednoprzebiegowe usuwanie je ponownie złożyło, wykonując skrypt w origin aplikacji, gdy ofiary otworzą plik.

phpMyFAQ 3.2.0 przed 4.0.0 oraz 4.0.2 przed 4.2.0-beta zawiera obejście uwierzytelniania w przepływie logowania Microsoft Entra ID, który łączy użytkowników za pomocą zmiennego oświadczenia preferred_username, a AuthEntraId::create() ignoruje wyjątek duplikatu logowania, kontynuując z istniejącym kontem lokalnym. Atakujący kontrolujący tożsamość Entra w skonfigurowanym dzierżawcy z pasującym preferred_username może przejąć to konto lokalne, w tym konta superadministratora.

phpMyFAQ 3.2.1 przed 4.1.9 oraz 4.2.0-alpha przed 4.2.0-beta zawiera podatność stored XSS, która pozwala uwierzytelnionym autorom treści wstrzykiwać JavaScript poprzez osadzanie iframe'ów ze źródłami data:text/html w treści FAQ lub News. Atakujący mogą obejść listę dozwolonych hostów mediów w FaqHelper::cleanUpContent(), renderowaną przez surowy filtr Twig, aby uruchomić interfejsy phishingowe lub przekierowania top-frame dla widzów.

phpMyFAQ 4.2.0-alpha przed 4.2.0-beta zawiera podatność eskalacji uprawnień w GroupController::saveCategoryRestrictions(), która pozwala delegowanym administratorom przypisywać kategorie poza ich własnym zakresem. Administratorzy z ograniczeniami kategorii mogą wysłać POST do /admin/api/group/category-restrictions z categoryIds spoza zakresu lub pustymi, aby przyznać grupom nieograniczony dostęp do kategorii.

phpMyFAQ w wersji 4.2.0-alpha przed 4.2.0-beta nie posiada skutecznego ograniczania liczby żądań na nieuwierzytelnionych endpointach user/password/update oraz user/password/reset. Nieuwierzytelniony atakujący może wysyłać nieograniczoną liczbę żądań resetu hasła, zalewając skrzynkę zarejestrowanego użytkownika wiadomościami i wyczerpując zasoby serwera pocztowego oraz aplikacji.

phpMyFAQ od 4.2.0-alpha.2 przed 4.2.0-beta zawiera podatność na eskalację uprawnień w API uprawnień grup, gdzie endpointy updatePermissions i updateMembers sprawdzają posiadane prawa bez uwzględnienia zakresu językowego lub kategorii i zapisują nieograniczone nadania grupowe. Administratorzy niebędący superadministratorami, posiadający GROUP_EDIT, mogą nadać grupie prawo, które posiadają tylko w wąskim zakresie, i samodzielnie dołączyć do niej przez updateMembers, uzyskując nieograniczony dostęp do tworzenia, edycji i publikacji FAQ we wszystkich językach i kategoriach.

phpMyFAQ od 4.2.0-alpha.2 przed 4.2.0-beta zawiera podatność na eskalację uprawnień w UserController::updateUserRights, która usuwa ograniczenia językowe przypisane do poszczególnych praw przy ponownym nadawaniu uprawnień. Administratorzy posiadający USER_EDIT mogą przesłać do API aktualizacji uprawnień prawa z zakresem językowym, w tym dla siebie, aby uzyskać nieograniczony dostęp do tworzenia, edycji i publikacji FAQ we wszystkich językach.

phpMyFAQ od 4.1.0 przed 4.1.9 oraz 4.2.0-alpha przed 4.2.0-beta zawiera podatność braku autoryzacji w panelu administracyjnym, która pozwala uwierzytelnionym użytkownikom bez uprawnień administratora na przeglądanie zastrzeżonych danych. Atakujący z dowolnym aktywnym kontem może wysłać żądanie do /admin/index.php/ i odczytać niepublikowane pytania FAQ, adresy URL edycji administracyjnych, ostatnie tożsamości użytkowników oraz statystyki witryny.

phpMyFAQ od wersji 4.0.0 przed 4.1.9 zawiera podatność na nieprawidłową autoryzację, która pozwala delegowanym administratorom bez uprawnienia editnews modyfikować wiadomości poprzez wywołanie PUT /admin/api/news/update, które sprawdza NEWS_DELETE zamiast NEWS_EDIT. Atakujący posiadający uprawnienia addnews i delnews mogą odczytać token CSRF aktualizacji wiadomości z własnego pliku cookie i przepisać nagłówek, treść, autora, link oraz flagę aktywności dowolnej wiadomości wyświetlanej na publicznej stronie głównej.

phpMyFAQ przed 4.1.9 oraz 4.2.0-alpha przed 4.2.0-beta zawiera podatność na enumerację kont, która pozwala nieuwierzytelnionym atakującym potwierdzić zarejestrowane nazwy wyświetlane i adresy e-mail poprzez odrębną odpowiedź HTTP 409. Atakujący mogą wysyłać komentarze gości do endpointu tworzenia komentarzy z kandydatami na nazwy użytkowników i adresy e-mail, aby powiązać nazwy z adresami e-mail na potrzeby ukierunkowanego phishingu.

phpMyFAQ od 4.2.0-alpha.2 przed 4.2.0-beta nie posiada blokady po nieudanych próbach w endpointcie usuwania 2FA removeTwofactorConfig(), co pozwala uwierzytelnionym atakującym na nieograniczone zgadywanie kodów TOTP. Atakujący posiadający przejętą sesję i token CSRF może wielokrotnie wysyłać żądania POST do /api/user/remove-twofactor, aby trwale wyłączyć 2FA ofiary.

phpMyFAQ od 4.2.0-alpha przed 4.2.0-beta zawiera podatność braku autoryzacji w GroupController::deleteGroup(), która pomija sprawdzanie poziomu uprawnień docelowych grup. Uwierzytelnieni administratorzy niebędący superadministratorami, posiadający GROUP_DELETE, mogą wysłać spreparowany groupId do /admin/api/group/delete, aby trwale usunąć grupy o wyższych uprawnieniach i pozbawić członków odziedziczonych praw.

phpMyFAQ w wersjach przed 4.1.9 oraz 4.2.0-alpha przed 4.2.0-beta nie wymaga podania aktualnego hasła przy zmianie adresu e-mail konta w panelu użytkownika (UserController::updateData, api/user/data/update), sprawdzając jedynie sesję i token CSRF. Atakujący z przejętą sesją może ustawić e-mail na swoją skrzynkę i wykorzystać proces resetowania hasła do przejęcia kont bez 2FA, w tym konta superadministratora.

phpMyFAQ 3.2.0-alpha przed 4.1.9 oraz 4.2.0-alpha przed 4.2.0-beta zawiera lukę obejścia uwierzytelniania, która pozwala użytkownikom uwierzytelnionym przez IdP pominąć dwuskładnikowe uwierzytelnianie TOTP poprzez callbacki SSO Keycloak i Entra ID. Atakujący posiadający ważną lub wyłudzoną tożsamość IdP powiązaną z kontem z włączonym 2FA może ukończyć przepływ OIDC i uzyskać w pełni uwierzytelnioną sesję, w tym konta administratora.