Podatności phpMyFAQ

phpMyFAQ przed wersją 4.1.8 zawiera podatność na trwały XSS w funkcji FaqHelper::convertOldInternalLinks(), która wywołuje html_entity_decode() na oczyszczonej treści FAQ, co odwraca ochronę encji. Uwierzytelnieni użytkownicy z uprawnieniami do edycji FAQ mogą wstrzyknąć kod JavaScript, który wykonuje się w przeglądarkach wszystkich użytkowników przeglądających dotknięte strony FAQ.

phpMyFAQ przed wersją 4.1.8 zawiera podatność na obejście autoryzacji w punkcie końcowym tworzenia pytań. Metoda isAddingQuestionsAllowed() przyznaje dostęp wszystkim wywołującym, gdy włączona jest opcja main.enableAskQuestions, ignorując ustawienie records.allowQuestionsForGuests. Nieuwierzytelnieni atakujący mogą wysyłać pytania przez API question/create, omijając ograniczenia dla gości i wstrzykując spam do kolejki moderacji administratora.

phpMyFAQ przed wersją 4.1.8 zawiera podatność na obejście uwierzytelniania w punkcie końcowym API panelu sterowania użytkownika, która pozwala uwierzytelnionym atakującym na zmianę haseł kont bez weryfikacji bieżącego hasła. Atakujący z dostępem do sesji mogą wysłać żądanie PUT do punktu końcowego aktualizacji danych użytkownika tylko z tokenem CSRF, aby po cichu zmienić hasło dowolnego użytkownika, w tym administratorów, powodując nieodwracalne przejęcie konta i zablokowanie ofiary.

phpMyFAQ przed wersją 4.1.8 zawiera podatność na ominięcie uwierzytelniania w funkcji wyłączania dwuskładnikowego uwierzytelniania (TOTP). Procedura removeTwofactorConfig() weryfikuje tylko zalogowanie użytkownika i ważny token CSRF, po czym wyłącza TOTP bez wymogu ponownego podania hasła lub aktualnego kodu TOTP. Atakujący, który przejął sesję użytkownika, może po cichu usunąć ochronę dwuskładnikową z dowolnego konta, w tym administratora.

phpMyFAQ przed wersją 4.2.0-alpha.2 zawiera brak autoryzacji w endpointach API panelu administracyjnego 'searches' i 'content-health', które wymagają tylko uwierzytelnienia bez sprawdzania uprawnień. Każdy uwierzytelniony użytkownik może uzyskać dostęp do tych endpointów i czytać statystyki wyszukiwań oraz liczniki stanu treści niezależnie od poziomu uprawnień.

phpMyFAQ przed wersją 4.1.8 zawiera sekrety TOTP w postaci jawnego tekstu w plikach ZIP eksportu danych użytkownika. Atakujący, którzy zdobędą wyeksportowane archiwa, mogą wyodrębnić ziarno TOTP i generować ważne kody jednorazowe, aby obejść uwierzytelnianie dwuskładnikowe.

phpMyFAQ przed wersją 4.1.8 egzekwuje nieprawidłowe kontrole uprawnień na stronach treści administracyjnych, co pozwala edytorom z niższymi uprawnieniami czytać wersje robocze i nieaktywne treści. Atakujący z uprawnieniami tylko do dodawania mogą uzyskać dostęp do endpointów edycji newsów i tłumaczeń FAQ, aby przeglądać nieopublikowane treści.

phpMyFAQ przed wersją 4.1.8 nie weryfikuje CAPTCHA, gdy parametr 'store' jest ustawiony na 'now' w żądaniach przesyłania pytań. Nieuwierzytelnieni atakujący mogą ominąć ochronę CAPTCHA i przesyłać nieograniczoną liczbę pytań bezpośrednio, powodując zanieczyszczenie bazy danych i wyzwalając powiadomienia e-mail.

phpMyFAQ przed wersją 4.1.7 nie stosuje kontroli widoczności nadrzędnych wpisów FAQ przed zwróceniem zasobów podrzędnych, takich jak komentarze i załączniki. Niezalogowani atakujący mogą pobrać treść ograniczonych komentarzy, adresy e-mail komentujących oraz nazwy plików załączników dla wpisów FAQ, do których nie mają bezpośredniego dostępu, poprzez zapytania do endpointów API komentarzy i załączników.

phpMyFAQ przed wersją 4.1.7 nie zapisuje wygenerowanego wyzwania logowania WebAuthn, co pozwala atakującemu na przechwycenie udanej asercji WebAuthn i jej wielokrotne odtwarzanie, aby uwierzytelnić się jako użytkownik bez interakcji z nim.

phpMyFAQ przed wersją 4.1.7 zawiera podatność brute-force w kroku uwierzytelniania dwuskładnikowego, gdzie licznik nieudanych prób jest powiązany z sesją i resetowany po każdym pomyślnym ponownym uwierzytelnieniu hasłem. Atakujący z ważnym hasłem może ominąć limit pięciu prób, uzyskując nowy ciasteczko sesji i wielokrotnie ponownie uwierzytelniając się, aby zresetować licznik, co umożliwia nieograniczone zgadywanie kodów TOTP.

phpMyFAQ przed wersją 4.1.7, gdy jest skonfigurowany do korzystania z PostgreSQL przez natywne rozszerzenie PHP pgsql, deklaruje nieprawidłowy znak ESCAPE dla LIKE ('=') w backendzie Search/Database/Pgsql.php, podczas gdy escapeLikeWildcards() poprzedza dane wejściowe użytkownika prefiksem '|'. W rezultacie escapowanie znaków wieloznacznych jest nieskuteczne, a znaki % i _ dostarczone przez użytkownika pozostają aktywnymi znakami wieloznacznymi LIKE. Niezalogowany atakujący może przesłać takie znaki w publicznym formularzu wyszukiwania FAQ, aby wymusić maksymalnie szerokie dopasowania wzorców i kosztowne skanowania sekwencyjne, co prowadzi do odmowy usługi. Backend PDO PostgreSQL nie jest dotknięty, a cudzysłowy pozostają escapowane, więc nie umożliwia to wstrzyknięcia SQL przez złamanie cudzysłowów ani eksfiltracji danych.

phpMyFAQ przed wersją 4.1.7 nie egzekwuje prawidłowo uprawnienia CONFIGURATION_EDIT na punktach końcowych API odczytu dla konfiguracji LDAP, Elasticsearch, OpenSearch i pulpitu nawigacyjnego, co pozwala każdemu uwierzytelnionemu użytkownikowi na dostęp do wrażliwych danych administracyjnych. Atakujący mogą pobrać topologię serwera LDAP, nazwy kont bind, bazy wyszukiwania, statystyki indeksów i analitykę witryny, wywołując te punkty końcowe z ważną sesją.

phpMyFAQ przed wersją 4.1.6 nie odpowiednio sanityzuje HTML w odpowiedziach FAQ przed generowaniem plików PDF przez TCPDF. Atakujący z uprawnieniami do tworzenia lub edycji treści FAQ może osadzić tag <img> z atrybutem src wskazującym na lokalny plik w katalogu content/ (np. content/core/config/database.php). Podczas generowania PDF, phpMyFAQ próbuje odczytać wskazany plik; ponieważ nie jest to prawidłowy obraz, błąd jest konwertowany na nieobsłużony wyjątek, którego ślad stosu ujawnia część zawartości pliku każdemu użytkownikowi, który wywoła eksport PDF. Domyślnie ujawniona część jest skrócona, ale większa skonfigurowana wartość może prowadzić do ujawnienia całych plików, w tym danych uwierzytelniających bazy danych.

phpMyFAQ przed wersją 4.1.6 nie sprawdza ustawienia security.enableRegistration w punktach API, co pozwala atakującym na tworzenie kont użytkowników, gdy rejestracja jest wyłączona. Atakujący mogą ominąć ograniczenie rejestracji, wysyłając żądania do punktów POST /api/register lub POST /api/v3.1/register, które nie sprawdzają flagi konfiguracyjnej egzekwowanej przez stronę HTML rejestracji.

phpMyFAQ w wersjach 3.1.0 do 4.1.6 zawiera podatność obejścia uwierzytelniania w funkcji AuthLdap::create(). Gdy uwierzytelnianie LDAP jest włączone, po pomyślnym wiązaniu LDAP kod wywołuje User::setStatus('active') bezwarunkowo, co nadpisuje kolumnę account_status istniejącego lokalnego konta z 'blocked' na 'active'. W rezultacie użytkownik, którego lokalne konto phpMyFAQ zostało administracyjnie zablokowane, może przywrócić swoje konto i zalogować się, uwierzytelniając się przez LDAP. Zmiana stanu nie jest logowana, więc administratorzy nie mogą wykryć, że blokada została nadpisana. Poprawiono w wersji 4.1.7.

phpMyFAQ przed wersją 4.1.7 zawiera podatność obejścia uwierzytelniania dwuskładnikowego, gdzie tokeny remember-me są wydawane przed zakończeniem weryfikacji 2FA. Atakujący z ważnymi poświadczeniami może uzyskać ciasteczko remember-me, pominąć wyzwanie 2FA i odtworzyć ciasteczko, aby uzyskać pełny uwierzytelniony dostęp bez weryfikacji drugiego czynnika.

phpMyFAQ przed wersją 4.1.7 nie sprawdza statusu aktywności w punkcie eksportu PDF, co pozwala nieuwierzytelnionym atakującym na pobieranie metadanych szkiców FAQ. Atakujący mogą uzyskać dostęp do publicznej trasy eksportu PDF z sekwencyjnymi identyfikatorami FAQ, aby uzyskać tytuły, identyfikatory rozwiązań, nazwiska autorów i znaczniki czasu ostatniej aktualizacji nieaktywnych lub nieopublikowanych FAQ.

phpMyFAQ przed wersją 4.1.7 zawiera podatność wstrzykiwania SQL w punktach końcowych tworzenia i aktualizacji glosariusza, spowodowaną obcinaniem escapowanego ciągu przed osadzeniem go w literale SQL. Uwierzytelnieni użytkownicy z uprawnieniami dodawania lub edycji glosariusza mogą stworzyć ładunek z wiszącym backslashem, aby uciec z zamykającego cudzysłowu i wstrzyknąć dowolne polecenia SQL w celu odczytania wrażliwych informacji z bazy danych.

phpMyFAQ przed wersją 4.1.6 zapisuje archiwa ZIP kopii zapasowych treści w katalogu głównym dostępnym przez sieć jako content.zip, ujawniając wrażliwe pliki, w tym dane uwierzytelniające bazy danych. Nieuwierzytelnieni atakujący mogą wykorzystać wyścig współbieżnych żądań, aby pobrać tymczasowy plik ZIP przed jego usunięciem, lub wykorzystać XSS w kontekście administratora, aby wywołać uwierzytelnione kopie zapasowe i pobrać archiwum.

phpMyFAQ przed wersją 4.1.7 zawiera podatność na ominięcie uwierzytelniania w SetupController, która pozwala nieuwierzytelnionym atakującym na uruchamianie migracji bazy danych i tworzenie kopii zapasowych konfiguracji, gdy tryb konserwacji jest włączony. Atakujący mogą wywołać punkty POST /api/setup/update-database i POST /api/setup/backup, aby wykonać aktualizacje bazy danych, wyłączyć tryb konserwacji i wyodrębnić dane uwierzytelniające bazy danych z wygenerowanych archiwów ZIP.

phpMyFAQ przed wersją 4.1.7 przechowuje tokeny resetowania hasła w publicznie dostępnym pliku śledzenia, gdy włączone jest śledzenie użytkowników. Nieuwierzytelnieni atakujący mogą odczytać plik śledzenia w ścieżce content/core/data/trackingDDMMYYYY, aby wyodrębnić tokeny resetowania i odtworzyć je przeciwko API resetowania hasła, przejmując konta użytkowników.

W phpMyFAQ przed wersją 4.1.6 występuje podatność na eskalację uprawnień w funkcji GroupController::updateMembers(). Administratorzy z uprawnieniami do zarządzania grupami mogą dołączyć do grup z wyższymi uprawnieniami bez weryfikacji.

Podatność w phpMyFAQ przed wersją 4.1.6 nie weryfikuje sekwencji ścieżek traversal w polu existing_image podczas aktualizacji kategorii, co pozwala uwierzytelnionym atakującym na usunięcie dowolnych plików poprzez wykorzystanie niedostatecznego oczyszczania w Image::delete(). Atakujący mogą usunąć plik konfiguracyjny database.php, aby wyłączyć bramę instalacyjną i uzyskać dostęp do publicznego kreatora konfiguracji w celu utworzenia nowych kont superadministratora.

phpMyFAQ przed wersją 4.1.5 zawiera podatność na eskalację uprawnień w punkcie końcowym API user/add. Umożliwia ona administratorom delegowanym (niebędącym SuperAdminem) tworzenie kont SuperAdmin, co prowadzi do pełnego przejęcia instancji.

phpMyFAQ przed wersją 4.1.5 zawiera podatność eskalacji uprawnień w metodzie GroupController::updatePermissions, która umożliwia administratorom z uprawnieniami GROUP_EDIT nadawanie grupom dowolnych praw bez weryfikacji, czy sami je posiadają. Delegowany administrator może wykorzystać tę lukę, przypisując grupie, do której należy, wysokowartościowe uprawnienia, dziedzicząc je i eskalując swoje uprawnienia do pełnej kontroli administracyjnej.

phpMyFAQ w wersjach przed 4.1.4 zawiera luki w autoryzacji w punktach końcowych editUser() i updateUserRights(), które pozwalają uwierzytelnionym administratorom na eskalację uprawnień. Użytkownicy, którzy nie są SuperAdminami, ale mają uprawnienia edit_user, mogą ustawić flagę is_superadmin lub przyznać dowolne uprawnienia, co prowadzi do uzyskania dostępu SuperAdmina.

phpMyFAQ przed wersją 4.1.4 używa algorytmu SHA-1 do haszowania haseł załączników. SHA-1 jest kryptograficznie słaby i podatny na ataki kolizyjne od 2017 roku.

phpMyFAQ przed wersją 4.1.3 zawiera podatność na nieautoryzowane resetowanie haseł w API aktualizacji haseł użytkowników, co pozwala atakującym na zmianę haseł kont bez walidacji tokenów.

phpMyFAQ przed wersją 4.1.2 zawiera podatność na przechowywane ataki typu cross-site scripting w funkcji Utils::parseUrl(). Umożliwia to uwierzytelnionym użytkownikom wstrzykiwanie JavaScriptu za pomocą źle sformatowanych URL-i w komentarzach.

phpMyFAQ przed wersją 4.1.2 zawiera podatność na ujawnienie informacji w metodzie getIdFromSolutionId(), która nie stosuje filtracji uprawnień. Umożliwia to nieautoryzowanym atakującym enumerację zastrzeżonych wpisów FAQ oraz odczyt ich tytułów przez punkt końcowy /solution_id_{id}.html.

phpMyFAQ przed wersją 4.1.2 zawiera brak autoryzacji w endpoincie DELETE /admin/api/content/tags/{tagId}, co pozwala każdemu uwierzytelnionemu użytkownikowi usuwać tagi. Zwykli użytkownicy frontendu mogą usuwać dowolne tagi, powodując trwałą utratę danych.

phpMyFAQ w wersjach przed 4.1.2 zawiera podatność typu stored XSS w endpointach tworzenia i aktualizacji FAQ, która omija sanityzację poprzez cykle kodowania i dekodowania. Uwierzytelniony atakujący z uprawnieniem FAQ_ADD może wstrzyknąć złośliwe tagi script poprzez parametry question lub answer, które wykonują się w przeglądarce każdego odwiedzającego, gdy treść FAQ jest renderowana z surowym filtrem Twig.

W phpMyFAQ przed wersją 4.1.2 występuje podatność stored XSS w pliku search.twig, gdzie result.question i result.answerPreview są renderowane z filtrem raw, wyłączającym automatyczne escapowanie. Atakujący z uprawnieniami edytora FAQ może wstrzyknąć ładunki zakodowane w encjach HTML, omijając przetwarzanie html_entity_decode(strip_tags()) w SearchController.php i wykonując dowolny JavaScript w przeglądarce każdego odwiedzającego, w tym administratorów.

phpMyFAQ w wersjach przed 4.1.2 zawiera podatność typu stored XSS w SvgSanitizer::decodeAllEntities(), która ogranicza rekurencyjne dekodowanie encji do 5 iteracji, umożliwiając obejście sanityzacji. Uwierzytelnieni użytkownicy z uprawnieniem FAQ_EDIT mogą przesłać złośliwe pliki SVG z głęboko zagnieżdżonym kodowaniem ampersand wokół numerycznych encji HTML, aby zrekonstruować adresy URL javascript:, które wykonują dowolny JavaScript po kliknięciu przez innych użytkowników przeglądających przesłany SVG.

phpMyFAQ przed wersją 4.1.2 zawiera podatność na wstrzykiwanie SQL w funkcji CurrentUser::setTokenData, która pozwala uwierzytelnionym atakującym na wykonywanie dowolnych zapytań SQL poprzez wstrzykiwanie złośliwych roszczeń tokenów OAuth.

phpMyFAQ przed wersją 4.1.2 zawiera podatność niewystarczającej autoryzacji w trasach admin-api, która sprawdza jedynie status zalogowania zamiast uprawnień backendu. Uwierzytelnieni zwykli użytkownicy mogą uzyskać dostęp do wrażliwych informacji administracyjnych, takich jak wersje dashboardu, konfiguracja LDAP, statystyki Elasticsearch i dane health-check.

phpMyFAQ przed wersją 4.1.2 zawiera podatność path traversal w funkcji Client::deleteClientFolder, która pozwala administratorom z uprawnieniem INSTANCE_DELETE usuwać dowolne katalogi. Atakujący mogą przesłać sekwencje traversal, takie jak https://../../../<path>, w parametrze URL klienta, aby rekurencyjnie usuwać katalogi poza zamierzonym zakresem.

phpMyFAQ przed wersją 4.1.2 zawiera brak sprawdzania uprawnień w ConfigurationTabController.php, gdzie 12 endpointów używa userIsAuthenticated() zamiast userHasPermission(CONFIGURATION_EDIT). Każdy uwierzytelniony użytkownik może wyliczyć metadane konfiguracji systemu, w tym model uprawnień, backend cache, dostawcę poczty i tłumaczeń, naruszając zasadę najmniejszych uprawnień.

phpMyFAQ przed wersją 4.1.1 zawiera podatność na XSS w sanitizerze SVG opartym na regexie. Atakujący z uprawnieniami edit_faq mogą przesłać złośliwy plik SVG, który wykorzystuje kodowanie encji HTML w adresach URL javascript: w atrybutach <a href>, co prowadzi do wykonania dowolnego JavaScriptu i eskalacji uprawnień do pełnego przejęcia konta administratora.

W phpMyFAQ przed wersją 4.1.1 wykryto podatność na ujawnienie informacji w metodzie searchCustomPages(). Funkcja escape() używa real_escape_string(), która nie zabezpiecza przed znakami specjalnymi LIKE (% i _), co umożliwia nieuwierzytelnionemu atakującemu wstrzyknięcie tych znaków i odczytanie nieprzeznaczonych do ujawnienia rekordów.

phpMyFAQ przed wersją 4.1.1 zawiera podatność przechowywanego XSS poprzez obejście wyrażeń regularnych w Filter::removeAttributes(). Podatność została naprawiona w wersji 4.1.1.

phpMyFAQ przed wersją 4.1.1 pozwala nieuwierzytelnionemu atakującemu przesłać gościnne FAQ z adresem e-mail zgodnym z RFC 5321 (cytowana część lokalna), który zawiera surowy HTML, np. "<script>alert(1)</script>"@evil.com. FILTER_VALIDATE_EMAIL akceptuje taki adres, a e-mail jest przechowywany bez sanityzacji i renderowany w szablonie edytora FAQ z filtrem |raw w Twig, co omija automatyczne escapowanie. Podatność naprawiono w wersji 4.1.1.

phpMyFAQ przed wersją 4.0.16 pozwala nieuwierzytelnionemu atakującemu na wygenerowanie kopii zapasowej konfiguracji w formacie ZIP przez POST /api/setup/backup, a następnie pobranie jej z publicznie dostępnej lokalizacji. Archiwum zawiera wrażliwe pliki konfiguracyjne, w tym dane dostępowe do bazy danych.

phpMyFAQ w wersjach 4.0.14 i 4.0.15 ma podatność przechowywanego XSS. Atakujący może zarejestrować użytkownika z nazwą wyświetlaną zawierającą encje HTML, a gdy administrator wyświetli listę użytkowników, ładunek jest dekodowany po stronie serwera i renderowany bez escapowania, co prowadzi do wykonania skryptu w kontekście administratora. Wersja 4.0.16 zawiera poprawkę.

phpMyFAQ to otwartoźródłowa aplikacja webowa FAQ. W wersjach przed 4.0.14 występuje podatność SQL injection w głównej funkcji aktualizacji konfiguracji, umożliwiająca uprzywilejowanemu użytkownikowi z uprawnieniami 'Configuration Edit' wykonanie dowolnych poleceń SQL.

phpMyFAQ w wersjach 4.0-nightly-2025-10-03 i starszych nie wymusza unikalności adresów e-mail podczas rejestracji użytkowników, co pozwala na utworzenie wielu kont z tym samym adresem e-mail. Może to prowadzić do niejednoznaczności kont, a w niektórych konfiguracjach do eskalacji uprawnień lub przejęcia konta. Problem naprawiono w wersji 4.0.13.