Podatności phpMyFAQ

phpMyFAQ to open source'owa aplikacja webowa FAQ. Podatność typu stored XSS w wersjach przed 4.2.0-alpha pozwala nieuwierzytelnionemu użytkownikowi (lub użytkownikowi o niskich uprawnieniach) na wstrzyknięcie dowolnego kodu JavaScript, który wykonuje się w przeglądarce administratora podczas przeglądania lub edycji wpisu FAQ. Prowadzi to do przejęcia konta administratora poprzez kradzież sesji.

Podatność w phpMyFAQ przed wersją 4.1.5 pozwala nieuwierzytelnionym atakującym na odczyt nieaktywnych (wersje robocze lub tylko do recenzji) treści FAQ poprzez niespójne filtrowanie w publicznych punktach końcowych API.

phpMyFAQ przed wersją 4.1.5 zawiera podatność na ścieżkowy atak typu path traversal w funkcji concatenatePaths() w pliku Wrapper.php. Użytkownik z uprawnieniami do edycji FAQ może przechowywać HTML z spreparowanymi ścieżkami obrazów, które są przetwarzane podczas generowania PDF. Brak kanonizacji ścieżki i walidacji ograniczenia do katalogu głównego może pozwolić na odczyt plików poza zamierzonym katalogiem treści.

W phpMyFaq przed wersją 2.9.9 występuje podatność typu CSRF w pliku admin/ajax.config.php.

W phpMyFAQ przed wersją 2.9.9 występuje podatność na Cross-Site Request Forgery (CSRF), która umożliwia modyfikację glosariusza.

W phpMyFAQ przed wersją 2.9.9 występuje podatność na atak Cross-Site Request Forgery (CSRF) w pliku admin/stat.main.php.

W phpMyFAQ przed wersją 2.9.9 występuje podatność na atak Cross-Site Request Forgery (CSRF) w plikach admin/ajax.attachment.php oraz admin/att.main.php.

W phpMyFAQ przed wersją 2.9.9 występuje podatność typu Cross-Site Request Forgery (CSRF) w pliku admin/news.php.

W phpMyFAQ przed wersją 2.9.9 występuje podatność typu Cross-Site Request Forgery (CSRF) w pliku admin/stat.adminlog.php.

W phpMyFAQ przed wersją 2.9.9 występuje podatność typu Cross-Site Request Forgery (CSRF) w pliku admin/stat.ratings.php.

W phpMyFAQ przed wersją 2.9.9 występuje podatność typu Cross-Site Request Forgery (CSRF) umożliwiająca dodawanie haseł do glosariusza.

phpMyFAQ w wersjach 4.0.0 przed 4.1.9 zawiera lukę obejścia uwierzytelniania w endpointach rejestracji WebAuthn, które przypisują poświadczenia do dowolnego konta bez uwierzytelnienia i walidacji wyzwania. Atakujący może przygotować nazwę użytkownika ofiary, przesłać sfałszowaną atestację fmt=none, aby zarejestrować passkey, a następnie zalogować się z pominięciem hasła i TOTP, przejmując konto.

phpMyFAQ przed wersją 4.1.6 zawiera podatność na zdalne wykonanie kodu w API konfiguracji. Uwierzytelniony administrator z uprawnieniami CONFIGURATION_EDIT i ATTACHMENT_ADD może manipulować ustawieniem upgrade.lastDownloadedPackage, aby zapisać dowolny plik PHP i uzyskać wykonanie kodu jako użytkownik serwera WWW.

phpMyFAQ przed wersją 4.1.2 zawiera podatność na nieautoryzowany atak SQL injection w metodach BuiltinCaptcha::garbageCollector() i BuiltinCaptcha::saveCaptcha(). Atakujący mogą wykorzystać publiczny punkt końcowy GET /api/captcha, wstrzykując złośliwe nagłówki User-Agent, co prowadzi do wycieku wrażliwych danych.

phpMyFAQ przed wersją 4.1.2 zawiera podatność na niewłaściwe ograniczenie nadmiernych prób uwierzytelnienia w punkcie końcowym /admin/check, który akceptuje dowolne parametry user-id bez powiązania sesji lub limitowania prób. Nieautoryzowani atakujący mogą przeprowadzić atak brute-force na sześciocyfrowy kod TOTP dowolnego użytkownika, omijając uwierzytelnianie dwuskładnikowe i uzyskując pełny dostęp administracyjny.

phpMyFAQ w wersjach przed 2.9.8 nie zabezpiecza odpowiednio przed atakami typu brute-force, które polegają na szybkim próbowaniu wielu haseł podczas logowania.

phpMyFAQ przed wersją 4.1.10 zawiera podatność obejścia autoryzacji na poziomie obiektu, która pozwala nieuwierzytelnionym atakującym modyfikować lub usuwać dowolne pytania odwiedzających poprzez podanie dowolnego openQuestionID do POST /api/faq/create. Atakujący rozwiązujący CAPTCHA mogą przepisywać kategorie pytań, fałszować wpisy odpowiedzi w faqquestion_history lub trwale usuwać pytania.

phpMyFAQ przed wersją 4.1.10 zawiera podatność typu server-side request forgery w funkcji eksportu PDF, która pobiera zewnętrzne obrazy przywoływane w odpowiedziach FAQ. Atakujący mogący wpływać na treść FAQ może osadzić adresy URL obrazów wskazujące na loopback lub usługi wewnętrzne, powodując żądania serwera i osadzenie odpowiedzi w generowanych plikach PDF.

phpMyFAQ przed 4.1.9 oraz 4.2.0-alpha przed 4.2.0-beta zawiera błąd obejścia autoryzacji w pliku attachment.php, który pozwala atakującym pobierać załączniki zastrzeżonych FAQ poprzez obejście kontroli uprawnień na poziomie rekordu. Użytkownicy o niskich uprawnieniach z prawem dlattachment, lub anonimowi użytkownicy gdy allowDownloadsForGuests jest włączone, mogą żądać identyfikatorów załączników, aby uzyskać poufne pliki z zastrzeżonych FAQ.

phpMyFAQ w wersjach przed 4.1.9 zawiera lukę braku autoryzacji w API deleteUser(), która pozwala uwierzytelnionym użytkownikom niebędącym superadminami z uprawnieniem delete_user na usuwanie kont superadminów. Atakujący może wysłać żądanie DELETE do /admin/api/user/delete z identyfikatorem userId superadmina innym niż 1, usuwając dostęp administracyjny i odpowiedzialność.

phpMyFAQ w wersjach 4.0.0 przed 4.1.9 oraz 4.2.0-alpha przed 4.2.0-beta zawiera lukę złamanej autoryzacji na poziomie obiektu w endpoincie PUT /api/v3.1/faq/update, który sprawdza tylko globalne uprawnienie edit_faq i nie weryfikuje dostępu do docelowego FAQ. Uwierzytelnieni użytkownicy z uprawnieniem edit_faq mogą podać identyfikator zastrzeżonego FAQ, którego nie mogą wyświetlić, aby zmodyfikować jego treść, obejść moderację i zmienić stan publikacji.

phpMyFAQ w wersjach 4.0.0 przed 4.1.9 zawiera lukę cross-site request forgery w endpoincie POST /admin/api/update-database, który wykonuje migracje bazy danych bez walidacji tokenu CSRF. Atakujący może zwabić zalogowanego użytkownika z uprawnieniem CONFIGURATION_EDIT do przesłania spreparowanego żądania cross-site, wywołując migracje, które mogą wpłynąć na integralność lub dostępność bazy danych.

phpMyFAQ przed 4.1.9 oraz 4.2.0-alpha przed 4.2.0-beta zawiera podatność CSRF w endpointach administracyjnych API Elasticsearch i OpenSearch, które nie weryfikują tokenu CSRF dla akcji tworzenia, usuwania i importu. Atakujący może nakłonić użytkownika z uprawnieniem CONFIGURATION_EDIT do odwiedzenia złośliwej strony, co wywoła te akcje, usuwając indeksy wyszukiwania, wymuszając ponowne indeksowanie lub wyczerpując zasoby.

phpMyFAQ 3.2.0 przed 4.1.9 oraz 4.2.0-alpha przed 4.2.0-beta zawiera podatność IDOR w GET /admin/api/user/data/{userId}, który zwraca pełny wiersz faquserdata dowolnego użytkownika, w tym aktywny sekret TOTP, bez sprawdzenia uprawnień SuperAdmin lub chronionego celu. Delegowani administratorzy z prawami zarządzania użytkownikami mogą odczytać sekret TOTP SuperAdmina i wygenerować ważne kody, omijając uwierzytelnianie dwuskładnikowe.

phpMyFAQ 4.2.0-alpha przed 4.2.0-beta zawiera podatność ujawnienia informacji, która pozwala nieuwierzytelnionym atakującym odczytać ukryte otwarte pytania z powodu odwróconego sprawdzenia api.onlyPublicQuestions w OpenQuestionController. Atakujący mogą wysyłać żądania GET do endpointu /api/v4.0/open-questions, aby uzyskać niepubliczne pytania moderacyjne lub wewnętrzne wraz z powiązanymi nazwami użytkowników.

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.

W phpMyFAQ przed wersją 4.1.9 występuje luka wstrzyknięcia SQL w metodzie PdoMysql::escape(), która escapuje apostrofy backslashami traktowanymi dosłownie, gdy MySQL lub MariaDB działa w trybie NO_BACKSLASH_ESCAPES. Nieuwierzytelniony atakujący może wysłać w parametrze wyszukiwania api/autocomplete znak Unicode prawego apostrofu, normalizowany do apostrofu ASCII, aby odczytać poświadczenia i sekrety konfiguracji, modyfikować rekordy lub usuwać tabele.

phpMyFAQ do wersji 4.1.10 zawiera podatność braku autoryzacji w narzędziu faq_search serwera MCP, która pozwala klientom MCP na odczyt ograniczonych FAQ, ponieważ Search::searchDatabase() nigdy nie stosuje sprawdzeń uprawnień użytkownika lub grupy. Atakujący podłączeni do serwera phpmyfaq:mcp:server mogą wysyłać zapytania, aby uzyskać pełny tekst pytań i odpowiedzi aktywnych FAQ ograniczonych do określonych użytkowników lub grup.

phpMyFAQ przed wersją 4.1.6 ma podatność w metodzie StopWords::add(), która buduje zapytanie SQL INSERT za pomocą sprintf() i wstawia wartość słowa zatrzymanego bezpośrednio do zapytania bez wywołania funkcji eskejpowania bazy danych. Uwierzytelniony administrator może przesłać spreparowaną wartość, która przełamuje literał łańcucha SQL i wstrzykuje dowolny SQL, w tym usuwanie tabel, eksfiltrację danych lub modyfikację innych wierszy.

phpMyFAQ przed wersją 4.2.0-alpha jest podatny na wstrzyknięcie dzikich znaków SQL LIKE w wyszukiwaniu użytkowników czatu. Uwierzytelniony użytkownik może ominąć filtr wyszukiwania nazwy wyświetlanej i wyliczyć aktywnych użytkowników, ponieważ znaki % i _ nie są escapowane.

phpMyFAQ w wersjach od 3.2.0 do 4.1.5 zawiera obejście uwierzytelniania w publicznym przepływie weryfikacji dwuskładnikowej. Nieuwierzytelniony atakujący może podać numeryczne ID użytkownika i ważny lub zbrutowany sześciocyfrowy kod TOTP bez znajomości hasła, co pozwala przejąć konto z włączonym 2FA, w tym konta administratorów. Wersja 4.1.6 naprawia problem poprzez powiązanie weryfikacji TOTP z sesją ustanowioną po poprawnym uwierzytelnieniu hasłem oraz ograniczenie nieudanych prób TOTP.