Jeśli otrzymali Państwo ode mnie e-mail kierujący na tę stronę, to dlatego, że Państwa witryna wydaje się uruchamiać wersję wtyczki Content Views – Post Grid & Filter (wtyczki WordPressa firmy Content Views / PT Guy, znajdującej się w Państwa plikach w katalogu /wp-content/plugins/content-views-query-and-display-post-page/), która mieści się w zakresie objętym znanym problemem bezpieczeństwa. Ta strona wyjaśnia, na czym polega problem, jak ocenić, jak bardzo dotyczy on Państwa witryny, jak odczytać swoją wersję, nie dając się wprowadzić w błąd, oraz jak dokonać aktualizacji.

Problem to CVE-2026-15361, wstrzyknięcie SQL w obsłudze podglądu wtyczki. Dotyczy każdego wydania starszego niż 4.5 i został naprawiony w wersji 4.5, wydanej 28 lipca 2026 roku. Jeśli korzystają Państwo z czegokolwiek starszego niż 4.5, proszę zaktualizować Content Views do wersji 4.5.1 lub nowszej, będącej bieżącym wydaniem w momencie pisania tego tekstu (4 sierpnia 2026 roku). Dla tego problemu nie opublikowano oceny CVSS, więc nie podam Państwu żadnej, i nie znam żadnego publicznie dostępnego kodu wykorzystującego tę lukę.

Nie ma żadnej starszej wersji, która byłaby bezpieczna. Nie jest to usterka, która pojawiła się w połowie historii wtyczki i została później naprawiona. Sprawdziłem każdy opublikowany tag wydania w historii wtyczki, od najwcześniejszego z 2014 roku aż po 4.4, i podatny kod znajduje się we wszystkich z nich. „Moja instalacja jest zbyt stara, by być objęta problemem” nie jest tu wyjściem awaryjnym. Jedyne wersje, których ten problem nie dotyczy, to 4.5 i nowsze.

Zanim przejdę dalej, zastrzeżenie, które decyduje o tym, jak bardzo ten problem dotyczy Państwa witryny, ponieważ wolę je od razu wskazać, niż pozwolić, by powiadomienie zabrzmiało poważniej, niż jest w rzeczywistości: tę lukę może wykorzystać wyłącznie ktoś zalogowany na Państwa witrynie. Nie ma znaczenia, co jego konto normalnie może robić, wystarczy najniższa rola w WordPressie, ale konto jest konieczne. Pytaniem decydującym o Państwa narażeniu nie jest więc żadne ustawienie w samej wtyczce, lecz to, kto może założyć konto na Państwa witrynie. Mogę odczytać wersję Państwa wtyczki z publicznego pliku i mogę sprawdzić, czy WordPress udostępnia swoją standardową stronę rejestracji, ale nie widzę, kto posiada konta na Państwa witrynie, więc to powiadomienie jest zapobiegawczym ostrzeżeniem, a nie potwierdzonym ustaleniem dotyczącym Państwa.

Warto zauważyć, czym to zastrzeżenie nie jest. Nie ma opcji do wyłączenia, funkcji do wycofania z publikacji ani konfiguracji, która wyprowadzałaby Państwa poza zakres ryzyka. Podatna obsługa jest zarejestrowana w każdej instalacji objętej problemem wersji, niezależnie od tego, czy kiedykolwiek umieścili Państwo siatkę wpisów na stronie. Jeśli będą Państwo szukać checkboxa do wyłączenia, nie znajdą go Państwo, ponieważ takiego nie ma. Aktualizacja jest rozwiązaniem.

Słowo o pilności, ponieważ to powiadomienie jest warunkowe. Jeśli są Państwo jedyną osobą posiadającą konto na witrynie i nikt inny nie może go uzyskać, aktualizacja jest zwykłą konserwacją wtyczki. Jeśli Państwa witryna przyjmuje rejestracje od innych osób, proszę potraktować to jako priorytet, i proszę pamiętać, że rejestracje przyjmują więcej form niż ta oczywista: sklep WooCommerce, wtyczka do obsługi członkostwa lub forum, blog wieloautorski oraz niestandardowa strona rejestracji, wszystkie one tworzą konta, nigdy nie angażując przy tym własnego formularza rejestracji WordPressa.

Jeśli mają Państwo stronę rejestracji WordPressa otwartą dla odwiedzających i jej nie potrzebują, wyłączenie jej jest rozsądnym krokiem tymczasowym, ponieważ zawęża krąg osób mogących dosięgnąć tego problemu. Proszę jednak nie odczytywać tego jako czystej karty zdrowia. Zamknięcie rejestracji zamyka tylko jedne z kilku drzwi do uzyskania konta i nic nie zmienia w sprawie kont, które już istnieją. To aktualizacja wtyczki faktycznie usuwa ten problem.

Warto też być precyzyjnym co do tego, czym ten problem jest, a czym nie jest. Pozwala on komuś z kontem o niskich uprawnieniach odczytać dane z bazy danych Państwa witryny, których jego konto nie powinno widzieć. To samo w sobie warto naprawić, ponieważ baza danych WordPressa przechowuje takie rzeczy jak adresy e-mail użytkowników i zahaszowane hasła, a na niektórych witrynach także dane członków lub klientów. Nie jest to jednak przejęcie konta administratora, nie jest to sposób, by ktoś przyznał sobie konto administratora, i nie jest to zdalne wykonanie kodu. Jest to węższy problem niż pełne przejęcia kontroli, o których piszę przy innych okazjach, a wolę uczciwie określić skalę zagrożenia, niż pozostawić Państwa z wrażeniem groźniejszym, niż wynika to z faktów.

Jest to luka we wtyczce, a nie w rdzeniu WordPressa. W pełni zaktualizowany WordPress nie chroni Państwa, jeśli sama wtyczka Content Views jest w wersji objętej problemem.

Czy ta wiadomość jest wiarygodna?

Tak. Jest to powiadomienie o odpowiedzialnym ujawnieniu luki, wystosowane w dobrej wierze przez niezależnego badacza bezpieczeństwa. Nie proszę o pieniądze, hasła ani dostęp do Państwa witryny, i nie próbowałem się do niej włamać, zarejestrować na niej ani niczego wykorzystać.

Jedynie sprawdziłem strony i pliki, które Państwa witryna udostępnia każdemu odwiedzającemu (w ten sam sposób, w jaki Państwa strona główna jest publiczna), i odnotowałem numer wersji publikowany przez wtyczkę. Jedną ze stron, które odczytałem, była standardowa strona rejestracji WordPressa Państwa witryny, aby sprawdzić, czy jest otwarta dla odwiedzających, i jej odczytanie to jedyne, co z nią zrobiłem. Celowo nie przesłałem tego formularza, nie założyłem konta, nie zalogowałem się i nie wysłałem niczego do podatnej funkcji. Żadna część tego sprawdzenia nie dotyka Państwa danych, panelu administracyjnego ani żadnej prywatnej części Państwa witryny (więcej szczegółów w sekcji Co zrobiłem, a czego nie poniżej).

Jeśli chcą Państwo zweryfikować, kim jestem, dane kontaktowe znajdują się na dole tej strony oraz na stronie O mnie.

Dlaczego to ważne

Content Views buduje na Państwa witrynie siatki, listy i przewijane zestawienia wpisów, dzięki czemu mogą Państwo wyświetlać przefiltrowany wybór wpisów lub stron bez pisania kodu. Częścią sposobu, w jaki to robi, jest obsługa żądania renderująca podgląd siatki na podstawie przekazanych jej ustawień.

W wersjach objętych problemem ta obsługa sprawdza token bezpieczeństwa i na tym poprzestaje. Nigdy nie sprawdza, czy osoba wysyłająca żądanie ma prawo z niego korzystać, a dany token nie jest tajny: wtyczka publikuje go dla każdego odwiedzającego witrynę. Obsługa ta buduje następnie zapytanie do bazy danych z ustawień pobranych wprost z żądania. Konsekwencją jest to, że ktoś dysponujący niczym więcej niż najniżej uprzywilejowanym kontem na Państwa witrynie może pokierować tym zapytaniem i odczytać z Państwa bazy danych dane, których jego konto nie powinno widzieć.

Warunek wstępny, powtórzę go, ponieważ to część najłatwiej odczytać błędnie w obu kierunkach: konto, a nie konfiguracja. Nic nie musi być włączone, aby ta obsługa była osiągalna, i nie ma żadnego ustawienia, które wyprowadzałoby wersję objętą problemem poza zakres ryzyka. Tym, co dzieli podatną instalację od tego problemu, jest po prostu to, czy ktoś inny niż Państwo może się zalogować. Na witrynie, na której każdy może się zarejestrować, to niewielka bariera. Na witrynie, na której są Państwo jedynym użytkownikiem, to bariera rzeczywista.

I druga strona medalu, równie istotna: witryna z zamkniętym formularzem rejestracji WordPressa nie jest przez to bezpieczna. Konta pojawiają się wieloma drogami, i wystarczy dowolna z nich.

Opisuję to na poziomie, jakiego potrzebuje właściciel witryny, by podjąć działanie, i nie dalej. Nie publikuję szczegółów, które pozwoliłyby komuś to odtworzyć, i prosiłbym, aby nie próbowali Państwo tego robić na własnej witrynie ani na witrynie kogokolwiek innego. Odczytanie numeru Państwa wersji, jak opisano poniżej, mówi Państwu wszystko, co potrzebne, by zdecydować, co robić.

Jeśli mój e-mail powołał się na ten problem, oznacza to, że wersja zgłaszana przez Państwa witrynę jest starsza niż 4.5. Nie sprawdzałem, czy akurat Państwa witrynę da się wykorzystać, i nie widzę, kto posiada na niej konta. Zaobserwowałem wyłącznie wersję oraz to, czy Państwa strona rejestracji jest udostępniana odwiedzającym.

Czy mnie to dotyczy?

Sprowadza się to do jednego pytania: jakiej wersji Content Views Państwo używają?

Krótkie słowo o tym, o którą wtyczkę chodzi, ponieważ nazwa jest współdzielona. To powiadomienie dotyczy darmowej wtyczki opublikowanej na WordPress.org, tej, której katalog to content-views-query-and-display-post-page. Ten sam producent sprzedaje też oddzielną linię Pro. Jeśli katalog Państwa wtyczki to właśnie ten, proszę czytać dalej.

W panelu administracyjnym WordPressa (źródło rozstrzygające):

  1. Proszę zalogować się do panelu administracyjnego WordPressa (zwykle pod adresem yourdomain.com/wp-admin).
  2. Przejść do Wtyczki, a następnie Zainstalowane wtyczki.
  3. Odnaleźć Content Views – Post Grid & Filter, pozycję, której katalog to content-views-query-and-display-post-page, i odczytać wersję widoczną pod jej nazwą.

Z publicznego manifestu (bez logowania): proszę otworzyć w przeglądarce

yourdomain.com/wp-content/plugins/content-views-query-and-display-post-page/README.txt

i odczytać linię Stable tag: blisko początku pliku. Jest to jedno z dwóch publicznych źródeł, które odczytałem.

Proszę zwrócić uwagę na wielkie litery w tej nazwie pliku. Wtyczki WordPressa zwyczajowo publikują plik readme.txt małymi literami, i to właśnie ten adres większość osób wpisuje z przyzwyczajenia. Pakiety 4.x tej wtyczki publikują ten plik jako README.txt, wielkimi literami, więc na hostingu rozróżniającym wielkość liter adres pisany małymi literami zwraca błąd 404 i wygląda na to, że pliku tam nie ma. On tam jest. Proszę spróbować pisowni wielkimi literami, zanim wyciągną Państwo jakiekolwiek wnioski.

Ze źródła Państwa strony (bez logowania): proszę wyświetlić źródło swojej strony głównej i poszukać własnych zasobów front-endowych wtyczki pod dokładnie tymi ścieżkami:

/wp-content/plugins/content-views-query-and-display-post-page/public/assets/js/cv.js?ver=...
/wp-content/plugins/content-views-query-and-display-post-page/public/assets/css/cv.css?ver=...

Numer ?ver= dołączony do tych plików to własna wersja wtyczki. W standardowej instalacji ładują się one na każdej stronie front-endu, niezależnie od tego, czy pojawia się na niej siatka wpisów, więc Państwa strona główna zwykle wystarczy. Na bardzo starych instalacjach te same dwa pliki noszą nazwy public.js i public.css, i ta sama zasada dotyczy ich obu.

Pułapka, której należy tu unikać, i łatwo w nią wpaść. Ta wtyczka dołącza pakiety kilku bibliotek innych firm wewnątrz własnego katalogu wtyczki, a każda z nich niesie swój własny, zupełnie niezwiązany numer wersji. Źródło Państwa strony może pokazywać Bootstrap w wersji 3.3.5 lub 3.3.0, Select2 w wersji 3.4.5, html5shiv w wersji 3.7.0, respond.js w wersji 1.4.2 i bootstrap-paginator w wersji 0.5, i wszystkie one znajdują się na ścieżkach zaczynających się od katalogu wtyczki Content Views. Operator, który przeszuka źródło strony pod kątem katalogu wtyczki i odczyta pierwszą napotkaną wartość ?ver=, może łatwo dojść do przekonania, że wtyczka jest w wersji „3.3.5”, i zastanawiać się później, jak ma się to do 4.5. To się w ogóle nie porównuje. Numer taki jak 3.3.5 czy 0.5, umieszczony na ścieżce bootstrap lub select2, to wersja zupełnie innego oprogramowania. Proszę odczytywać wersję wyłącznie z cv.js lub cv.css (albo z public.js / public.css na bardzo starej instalacji), a każdą inną wartość ?ver= na stronie proszę zignorować.

Jeśli w ogóle nie da się uzyskać czytelnego numeru ze źródła strony, jest to częste i nie jest oznaką niczego złego: wtyczki buforujące i optymalizujące rutynowo usuwają wartość ?ver= z adresów zasobów albo łączą pliki w jeden skrypt zbiorczy. W takim przypadku plik README.txt jest wiarygodnym publicznym źródłem odczytu, a ekran administracyjny z pierwszego sprawdzenia zawsze da odpowiedź.

Następnie proszę zastosować tę regułę, pamiętając, że wersje porównuje się numerycznie, a nie alfabetycznie, więc 4.10 byłaby nowsza niż 4.9, mimo że jako tekst wygląda na mniejszą:

  • Cokolwiek starszego niż 4.5: objęte problemem. Proszę zaktualizować. Nie ma żadnej granicy, poniżej której starsze wydanie znów staje się bezpieczne.
  • 4.5 lub nowsza: już naprawiona, jeśli chodzi o ten problem. Bieżącym wydaniem w momencie pisania tego tekstu jest 4.5.1, i wybranie najnowszej dostępnej wersji jest najlepszym posunięciem.

Jak zaktualizować

Wtyczka jest darmowa, nadal publikowana i aktywnie utrzymywana, więc poprawka to zwykła aktualizacja. Najbezpieczniejsza droga to aktualizacja przez sam WordPress, po uprzednim wykonaniu kopii zapasowej:

  1. Proszę wykonać kopię zapasową swojej witryny (plików i bazy danych) przed wprowadzeniem jakichkolwiek zmian. Większość dostawców hostingu oferuje kopie zapasowe jednym kliknięciem, można też skorzystać z wtyczki do kopii zapasowych WordPressa.
  2. W panelu administracyjnym WordPressa proszę przejść do Kokpit, a następnie Aktualizacje, albo do Wtyczki, a następnie Zainstalowane wtyczki. Jeśli na liście pojawi się aktualizacja Content Views, proszę zainstalować ją stąd.
  3. Jeśli wolą Państwo wiersz poleceń, WP-CLI robi to samo: wp plugin update content-views-query-and-display-post-page (polecenie używa nazwy katalogu, a nie nazwy wyświetlanej).
  4. Jeśli nie pojawia się żadna aktualizacja, mogą Państwo pobrać najnowszą wersję bezpośrednio ze strony wtyczki w katalogu WordPress.org, Content Views – Post Grid & Filter, i zaktualizować przez Wtyczki, następnie Dodaj wtyczkę i Wyślij wtyczkę na serwer.
  5. Po aktualizacji proszę potwierdzić nowy numer wersji (4.5.1 lub nowszy), korzystając z powyższych kroków, i sprawdzić, czy Państwa siatki wpisów oraz wszelkie filtry na nich nadal wyświetlają się prawidłowo.

Przy tej okazji warto upewnić się, że rdzeń WordPressa oraz pozostałe Państwa wtyczki są aktualne, ponieważ ta sama zasada dotyczy ich wszystkich.

Po aktualizacji

Aktualizacja do wersji 4.5.1 lub nowszej zamyka ten problem i dla większości witryn to cały zakres zadania. Ta strona jest powiadomieniem zapobiegawczym, a nie raportem incydentu: nie mam wglądu w to, czy na Państwa witrynie coś się wydarzyło, i tego nie sprawdzałem.

Dwie drobne rzeczy warto zrobić, póki aktualizacja jest świeża:

  • Proszę potwierdzić, że wersja rzeczywiście się zmieniła, korzystając z tego ze sprawdzeń powyżej, które było najłatwiejsze, i wczytać stronę pokazującą jedną z Państwa siatek wpisów, aby upewnić się, że nadal się wyświetla.
  • Jeśli mieli Państwo otwartą rejestrację WordPressa i jej nie potrzebują, warto rozważyć jej zamknięcie. Jest to ogólna higiena, a nie naprawa tego problemu, którym zajęła się już aktualizacja, i warto pamiętać, że inne wtyczki na Państwa witrynie mogą i tak tworzyć konta.

Zauważą Państwo, że na tej stronie nie ma listy kontrolnej „załóż, że doszło do naruszenia”, i jest to celowe, a nie przeoczenie. Tym, co daje ten problem, jest odczyt z bazy danych osiągalny z konta o niskich uprawnieniach. Nie daje on nikomu konta administratora i nie uruchamia kodu na Państwa serwerze, więc audyt kont administratorów i procedura zmiany haseł, które polecam po lukach klasy przejęcia kontroli, nie byłyby tu proporcjonalne. Proszę zaktualizować, potwierdzić i kontynuować pracę.

Co zrobiłem, a czego nie

Dla pełnej przejrzystości co do sprawdzenia stojącego za moim e-mailem, oto jego całość. Odczytałem strony i pliki, które Państwa witryna i tak udostępnia każdemu odwiedzającemu:

  • Państwa stronę główną oraz adresy zasobów w niej zapisane;
  • publiczny plik README.txt wtyczki wewnątrz wp-content/plugins/content-views-query-and-display-post-page/;
  • standardową stronę rejestracji WordPressa Państwa witryny pod adresem /wp-login.php?action=register, aby sprawdzić, czy jest otwarta dla odwiedzających. Jest to opublikowana strona, i jej odczytanie to jedyne, co z nią zrobiłem.

Nie przesłałem tego formularza rejestracji, nie założyłem konta i nie zalogowałem się na Państwa witrynie. Nie wysłałem niczego do podatnej funkcji. Ten ostatni punkt to ten, co do którego chcę być najbardziej jednoznaczny: ten problem to miejsce docelowe wstrzyknięcia SQL, a wystrzeliwanie ładunku w cudzą bazę danych nie jest czymś, co ten projekt robi, ani w laboratorium, ani produkcyjnie. Nic nie zostało przesłane, przetestowane ani wykorzystane, i nic nie dotknęło Państwa panelu administracyjnego WordPressa, Państwa bazy danych ani żadnej prywatnej części witryny.

Celowo również nie publikuję szczegółów, które pomogłyby komuś wykorzystać ten problem. Powyższy opis zatrzymuje się na poziomie potrzebnym właścicielowi witryny, i nie podaję odnośników do żadnego kodu proof-of-concept.

To jest obserwacja oparta na wersji: Państwa witryna zgłasza wersję starszą niż 4.5. Nie jest to stwierdzenie, że Państwa witryna była podatna na atak w chwili, gdy ją sprawdzałem. Ponieważ wykorzystanie tego problemu wymaga, by ktoś był zalogowany, a ja nie widzę, kto posiada konta na Państwa witrynie, witryna z zakresu objętego problemem może wcale nie być narażona, a witryna z tego zakresu może być osobno chroniona innymi środkami, takimi jak zapora aplikacji webowych (WAF) lub poprawka wprowadzona wstecznie.

Nie mam webmastera / utknąłem

Jeśli nie zajmują się Państwo witryną osobiście, proszę przekazać tę stronę osobie, która to robi (deweloperowi, agencji lub firmie hostingowej). Powyższe kroki rozpozna od razu.

Jeśli utrzymują Państwo witrynę samodzielnie i utkną, chętnie bezpłatnie wskażę właściwy kierunek. Proszę napisać, korzystając z danych kontaktowych poniżej.

Kontakt

Evan Harris, badacz bezpieczeństwa

Kontaktuję się w takich sprawach wyłącznie po to, by pomóc operatorom zabezpieczyć ich witryny. Jeśli wolą Państwo nie otrzymywać kolejnych wiadomości, proszę dać znać; uszanuję to.

Źródła

Oficjalne komunikaty i śledzenie

Producent / wtyczka