CVE-2026-52762

YesWiki przed wersją 4.6.6 zawiera podatność na wstrzykiwanie SQL w funkcji ReactionManager::deleteUserReaction(), która pozwala każdemu uwierzytelnionemu użytkownikowi na wstrzyknięcie dowolnego SQL przez parametry ścieżki URL {idreaction} i {id}. Parametry są konkatenowane bezpośrednio do klauzuli SQL LIKE bez escapowania lub parametryzacji.

YesWiki to system wiki napisany w PHP. Przed wersją 4.6.6, handler widżetu Bazar odzwierciedla parametr GET 'id' w atrybutach HTML używając tylko strip_tags(). Ponieważ strip_tags() nie escapuje podwójnych cudzysłowów, atakujący może wyrwać się z wartości atrybutu, wstrzyknąć handler zdarzeń, taki jak onmouseover, i wykonać dowolny JavaScript w przeglądarce ofiary. Problem jest osiągalny bez uwierzytelnienia.

YesWiki to system wiki napisany w PHP. Od wersji 4.1.0 do przed 4.6.6, widok zarchiwizowanej rewizji odzwierciedla parametr GET 'time' w ukrytym polu HTML w handlers/page/show.php bez escapowania. Ponieważ MySQL koercji nieprawidłowych ciągów DATETIME, atakujący może dołączyć HTML lub JavaScript do prawidłowego znacznika czasu zarchiwizowanej rewizji, nadal załadować tę rewizję i wykonać dowolny JavaScript w przeglądarce ofiary. Podatny formularz jest renderowany tylko gdy ofiara może czytać i edytować stronę docelową.

YesWiki to system wiki napisany w PHP. Przed wersją 4.6.6, szablony pól formularza Bazar nadal stosują |raw('html') do field.label / field.hint w kontekście atrybutów i treści etykiet, co powoduje trwały XSS w renderowaniu formularzy.

YesWiki od wersji 4.2.0 do przed 4.6.6 zawiera podatność na wstrzykiwanie SQL w ApiController::deletePage(), gdzie tag strony pobrany z bazy jest interpolowany do zapytania DELETE bez escapowania. Niskouprzywilejowany uwierzytelniony użytkownik może utworzyć stronę z tagiem będącym fragmentem SQL i wykonać dowolny SQL w bazie wiki.

YesWiki przed wersją 4.6.6 zawiera podatność na nieuwierzytelnione wstrzykiwanie SQL w publicznych API listowania wpisów Bazar, w filtrach numerycznych. Wartość filtra jest escapowana, ale wstawiana do SQL bez cudzysłowów i walidacji numerycznej, co pozwala atakującemu na wstrzykiwanie wyrażeń boolowskich i wnioskowanie o zawartości bazy.

YesWiki od wersji 4.6.2 do przed 4.6.6 zawiera podatność w trasie POST /api/forms/{formId}/actor/inbox, która jest publicznie dostępna. HttpSignatureService::verifySignature() parsuje nagłówek HTTP Signature i natychmiast wykonuje serwerowe żądanie HTTP GET do podanego URL, przed jakąkolwiek weryfikacją kryptograficzną. Nieuwierzytelniony atakujący może zmusić serwer do wykonywania żądań do wewnętrznych usług, w tym metadanych chmury.

YesWiki od wersji 4.6.2 do przed 4.6.6 zawiera podatność w HttpSignatureService::verifySignature(), która sprawdza wynik funkcji openssl_verify() za pomocą luźnej negacji boolowskiej. Ponieważ PHP traktuje -1 jako prawdę, warunek !(-1) jest fałszywy, co powoduje pominięcie błędu i kontynuację przetwarzania, nawet gdy weryfikacja podpisu nie powiodła się.

YesWiki to system wiki napisany w PHP. Przed wersją 4.6.6, akcja recentchanges (actions/recentchanges.php) akceptuje argument okresu z dwóch rozłącznych przestrzeni parametrów. Biała lista waliduje tylko formę URL przeciwko ['day','week','month']. Forma argumentu akcji przechodzi do gałęzi else bez walidacji, a wartość trafia do PageManager::getRecentlyChanged(), gdzie jest interpolowana do klauzuli WHERE time >= '...' ORDER BY time DESC bez escapowania lub parametryzacji. Udana iniekcja UNION-based pozwala na wyświetlenie wyciekłych wierszy w odpowiedzi, więc każdy odwiedzający stronę wyzwalającą widzi eksfiltrowane dane. Podatność zapewnia dowolny odczyt bazy danych YesWiki każdemu, kto może zapisać stronę wyzwalającą.

YesWiki to system wiki napisany w PHP. Przed wersją 4.6.6 występuje uwierzytelniona podatność na wstrzykiwanie obiektów PHP w BazarImportAction przez funkcję unserialize. Problem został naprawiony w wersji 4.6.6.