CVE-2026-76212
ŚrednieCVSS 5.3Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 22 - wyżej niż 22% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Ryzyko odmowy usługi poprzez przeciążenie bazy danych kosztownymi zapytaniami, co może prowadzić do niedostępności aplikacji dla użytkowników.
Rekomendacja
Zaktualizuj phpMyFAQ do wersji 4.1.7 lub nowszej, która zawiera poprawkę eliminującą podatność.
Inne podatności w phpMyFAQ
Zobacz wszystkie- CVE-2026-56736Wysokie
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.
- CVE-2026-57994Średnie
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.
- CVE-2026-57961Niskie
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.
- CVE-2026-35676Wysokie
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.
- CVE-2026-46367Wysokie
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.
- CVE-2026-46366Wysokie
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.
- CVE-2026-46359Wysokie
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.
- CVE-2017-15808Wysokie
W phpMyFaq przed wersją 2.9.9 występuje podatność typu CSRF w pliku admin/ajax.config.php.
- CVE-2017-15735Wysokie
W phpMyFAQ przed wersją 2.9.9 występuje podatność na Cross-Site Request Forgery (CSRF), która umożliwia modyfikację glosariusza.
- CVE-2017-15734Wysokie
W phpMyFAQ przed wersją 2.9.9 występuje podatność na atak Cross-Site Request Forgery (CSRF) w pliku admin/stat.main.php.
Oryginalny opis (angielski, źródło NVD)
phpMyFAQ before 4.1.7, when configured to use PostgreSQL via the native pgsql PHP extension, declares an incorrect LIKE ESCAPE character ('=') in the Search/Database/Pgsql.php backend while escapeLikeWildcards() escapes user input with the '|' prefix. As a result, wildcard escaping is a no-op and user-supplied % and _ characters remain active LIKE wildcards. An unauthenticated attacker can submit such characters in the public FAQ search form to force maximally broad pattern matches and expensive sequential scans, resulting in a denial of service. The PDO PostgreSQL backend is not affected, and quotes remain escaped so this does not enable quote-breaking SQL injection or data exfiltration.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS