Nazwa wtyczki	WPBookit
Rodzaj podatności	Atak typu cross-site scripting (XSS)
Numer CVE	CVE-2026-1945
Pilność	Średni
Data publikacji CVE	2026-03-05
Adres URL źródła	CVE-2026-1945

Pilne: Nieautoryzowane przechowywane XSS w WPBookit (<=1.0.8) — Co każdy właściciel strony WordPress powinien teraz zrobić

Autor: Zespół ds. bezpieczeństwa WP‑Firewall
Data: 2026-03-06
Tagi: WordPress, Bezpieczeństwo, WAF, XSS, WPBookit, Luka

Streszczenie

Przechowywana luka w Cross‑Site Scripting (XSS) wpływająca na wtyczkę WPBookit dla WordPressa (wersje <= 1.0.8) została publicznie ujawniona 5 marca 2026 roku i przypisana do CVE‑2026‑1945. Luka pozwala nieautoryzowanym atakującym na przesyłanie spreparowanych danych w wpb_user_name I wpb_user_email parametrach, które mogą być przechowywane i później wykonywane w przeglądarce uprzywilejowanego użytkownika (na przykład, administratora strony). Luka ma poważność podobną do CVSS na poziomie około 7.1 i jest oceniana jako średnia — ale wpływ operacyjny może być poważny, jeśli zostanie wykorzystana: przejęcie konta, kradzież sesji, zniekształcenie strony lub wstrzyknięcie trwałego złośliwego oprogramowania.

Ten post — przygotowany przez zespół bezpieczeństwa WP‑Firewall — wyjaśnia, czym jest ta luka, jak atakujący mogą ją wykorzystać, jak wykryć, czy Twoja strona została zaatakowana, oraz praktyczne kroki łagodzenia i naprawy, które możesz podjąć natychmiast (w tym wirtualną łatkę z Twoim zaporą, bezpieczny tymczasowy kod, który możesz wdrożyć, oraz długoterminowe poprawki dla deweloperów). Wskazówki są pragmatyczne i napisane dla właścicieli stron WordPress, agencji i zespołów hostingowych.

Zrzut luki
– Wtyczka: WPBookit
– Dotknięte wersje: <= 1.0.8
– Problem: Nieautoryzowane przechowywane Cross‑Site Scripting (XSS) przez wpb_user_name I wpb_user_email
– Poprawione w: 1.0.9
– Data ujawnienia publicznego: 5 mar, 2026
– CVE: CVE‑2026‑1945
– Typowa poważność: Średnia (CVSS ~7.1), ale rzeczywisty wpływ zależy od środowiska

---

Dlaczego przechowywane XSS jest niebezpieczne (nawet gdy ma ‘tylko’ średnią powagę)

Przechowywane XSS występuje, gdy złośliwe dane są zapisywane przez aplikację i później renderowane na stronie bez odpowiedniego uciekania lub sanitizacji. W przeciwieństwie do odzwierciedlonego XSS, przechowywane XSS jest trwałe: atakujący może wstrzykiwać ładunki, które wykonują się w przeglądarkach wielu odwiedzających lub administratorów strony.

W przypadku WPBookit punkty wstrzyknięcia to pola powszechnie używane w formularzach rezerwacji — nazwa użytkownika i e-mail. Ponieważ wtyczka przechowuje te dane i później je wyświetla (na przykład w liście rezerwacji administratora, e-mailach lub widżetach rezerwacji na froncie), udany atak może:

• Wykonać JavaScript w kontekście przeglądarki administratora, co pozwala na kradzież ciasteczek sesyjnych lub eksfiltrację tokenów.
• Wykonuj działania w imieniu administratora (tworzenie użytkowników, zmiana ustawień) za pomocą uwierzytelnionych żądań przeglądarki.
• Wstrzykuj trwałą złośliwą treść, która wpływa na odwiedzających stronę (malvertising, przekierowanie na strony phishingowe).
• Obejście kontroli uwierzytelniania za pomocą inżynierii społecznej: napastnicy składają rezerwację, a następnie wabią administratora do kliknięcia w przygotowany link lub otwarcia przygotowanego rekordu rezerwacji.

Chociaż wykorzystanie wymaga, aby uprzywilejowany użytkownik wchodził w interakcję z złośliwą treścią (na przykład administrator przeglądający listę rezerwacji), wiele procesów roboczych WordPressa obejmuje automatyczne e-maile, widżety pulpitu lub zaplanowane zadania, które mogą uruchomić przechowywany ładunek bez oczywistego działania manualnego — co zwiększa ryzyko.

---

Scenariusze ataków, które powinieneś rozważyć

1. Napastnik publikuje rezerwację z złośliwym skryptem w wpb_user_name. Administrator odwiedza obszar rezerwacji; skrypt wykonuje się w kontekście administratora i wykrada pliki cookie lub tworzy użytkownika administratora za pomocą AJAX.
2. Napastnik przygotowuje rezerwację, która zawiera iframe lub zewnętrznego hosta skryptów. Gdy rezerwacja jest wyświetlana na publicznej stronie, odwiedzający są przekierowywani lub wstrzykiwani z kryptowalutami/malvertisingiem.
3. Napastnik wstrzykuje ładunek, który automatycznie wysyła token sesji administratora do zdalnego serwera, umożliwiając trwały dostęp przez tylną furtkę.
4. Jeśli strona wysyła szczegóły rezerwacji w e-mailach HTML, przechowywany ładunek XSS zawarty w nazwie/e-mailu może zostać wykonany w kliencie e-mail odbiorcy (jeśli klient renderuje HTML i nie oczyszcza danych wejściowych).

Ponieważ luka jest nieautoryzowana, przypadkowy napastnik w internecie może próbować ją wykorzystać, co zwiększa pilność natychmiastowych działań naprawczych.

---

Natychmiastowe działania dla właścicieli witryn (krok po kroku)

Jeśli prowadzisz strony WordPress, szczególnie te, które używają WPBookit, wykonaj te kroki teraz.

1. Inwentaryzacja i priorytetyzacja
      – Zidentyfikuj strony działające na WPBookit. Jeśli zarządzasz wieloma stronami, uruchom szybkie polecenie lub użyj swojego narzędzia do zarządzania, aby zlokalizować wtyczkę.
         – Przykład WP‑CLI:
           – wp plugin list --field=name,version | grep -i wpbookit
      – Zauważ, które strony są na <=1.0.8.
2. Zaktualizuj wtyczkę (zalecane)
      – Jeśli strona jest na <=1.0.8, natychmiast zaktualizuj WPBookit do wersji 1.0.9 lub nowszej. Aktualizacja jest najprostszym i najbardziej niezawodnym rozwiązaniem.
3. Jeśli nie możesz zaktualizować teraz — wirtualna łatka
      – Zastosuj regułę WAF (twój host WAF, WAF w chmurze lub WP‑Firewall), aby zablokować żądania zawierające podejrzaną treść w wpb_user_name I wpb_user_email parametrach. Zobacz sekcję “Reguły zapory i tymczasowe łatki” poniżej, aby uzyskać przykładowe reguły.
      – Dodaj krótki mu‑plugin (plugin do użycia) do sanitizacji $_POST wartości przed ich przetworzeniem przez plugin (przykład poniżej).
4. Wykonaj wykrywanie i czyszczenie
      – Przeszukaj bazę danych w poszukiwaniu podejrzanych wpisów w miejscach, gdzie WPBookit przechowuje rezerwacje (zwykle niestandardowe typy postów lub niestandardowe tabele). Przeszukaj również wspólne tabele pod kątem tagów skryptów:
         – Przykład SQL (zachowaj ostrożność; najpierw wykonaj kopię zapasową):
           – WYBIERZ ID, post_title, post_content Z wp_posts GDZIE post_content JAKO '%<script%';
           – WYBIERZ option_name, option_value Z wp_options GDZIE option_value JAKO '%<script%';
           – SELECT * FROM wp_postmeta WHERE meta_value LIKE '%<script%';
      – Sprawdź ostatnie sesje administratorów i aktywność logowania pod kątem anomalii.
      – Sprawdź rekordy rezerwacji i szablony e-maili pod kątem wstrzykniętego kodu.
      – Jeśli występują jakiekolwiek złośliwe ładunki, usuń wpisy, zmień hasła i sekrety, zresetuj sesje administratorów i zbadaj pod kątem tylnej furtki.
5. Reakcja na incydent w przypadku naruszenia
      Jeśli podejrzewasz kompromitację, postępuj zgodnie z tymi krokami w kolejności. Kroki zakładają, że masz dostęp na poziomie konsoli (SSH) i WP‑CLI; jeśli nie, poproś swojego hosta o ich udostępnienie lub współpracuj z profesjonalistą ds. bezpieczeństwa.
      – Wykonaj pełną kopię zapasową (system plików + DB) do celów śledczych.
      – Rozważ przywrócenie z znanej czystej kopii zapasowej przed naruszeniem, jeśli nie możesz pewnie usunąć złośliwych artefaktów.
      – Zmień wszystkie dane logowania administratora i klucze API.
      – Skanuj w poszukiwaniu dodatkowego złośliwego oprogramowania lub tylnych furtek (system plików i baza danych).
      – Powiadom dotkniętych użytkowników zgodnie z twoją polityką.
6. Wzmocnienie na przyszłość
      – Wymuś 2FA dla administratorów.
      – Użyj zasady najmniejszych uprawnień dla kont.
      – Włącz Politykę Bezpieczeństwa Treści (CSP), aby zredukować wpływ XSS.
      – Wzmocnij renderowanie e-maili (używaj tylko tekstu dla automatycznych szablonów, gdzie to możliwe).

---

Analiza techniczna (co poszło nie tak i dlaczego)

Chociaż nie możemy zobaczyć źródła WPBookit w każdej linii, ta klasa przechowywanego XSS zazwyczaj wynika z kombinacji czynników:

• Treść dostarczona przez użytkownika (taka jak imię lub e-mail) jest akceptowana bez wystarczającej walidacji.
• Treść jest przechowywana i później renderowana bez odpowiedniego uciekania lub sanitizacji.
• Wyjście jest renderowane jako surowy HTML (lub wstrzykiwane w kontekst, w którym HTML jest interpretowany).
• Ekrany administracyjne lub szablony e-mail wyświetlają przechowywaną treść w kontekście podatnym na wykonanie skryptu.

Typowe niebezpieczne wzorce kodu obejmują wyświetlanie surowych danych POST:

// niebezpieczny przykład - NIE UŻYWAJ;

Bezpieczne wzorce używają zarówno walidacji/sanitizacji wejścia, jak i uciekania wyjścia:

• Przy wejściu: dezynfekuj_pole_tekstowe(), sanitize_email(), Lub wp_kses() w zależności od dozwolonej treści.
• Przy wyjściu: esc_html(), esc_attr(), esc_url(), Lub wp_kses_post() w zależności od kontekstu.

Solidne podejście:
– Waliduj i sanitizuj na wejściu.
– Uciekaj przy wyjściu.
– Zastosuj zasadę najmniejszych uprawnień i używaj nonce'ów / sprawdzeń uprawnień dla wrażliwych działań.

---

Krótkie, bezpieczne fragmenty kodu, które możesz wdrożyć natychmiast

Jeśli nie możesz zaktualizować wtyczki od razu, zalecamy zastosowanie prostego mu-pluginu, który sanitizuje przychodzące pola rezerwacji przed ich przetworzeniem i zapisaniem. Dodaj ten kod jako nowy plik w wp-content/mu-plugins/wpfw-sanitize-wpbookit.php (wtyczki must-use są uruchamiane przed innymi wtyczkami).

<?php;

Uwagi:
– To jest tymczasowe rozwiązanie. Zmniejszy ryzyko przechowywania HTML/skryptu w tych dwóch polach, ale pełne rozwiązanie wymaga aktualizacji wtyczki lub zastosowania solidnej reguły WAF.
– Zawsze testuj w środowisku stagingowym przed wdrożeniem do produkcji.

---

Zasady zapory i tymczasowe poprawki (przykłady)

Zapora aplikacji webowej (WAF) jest idealna do zatrzymywania zautomatyzowanego wykorzystywania i dawania ci czasu. Oto koncepcje zasad, które możesz wdrożyć w swojej zaporze (twoim hoście lub WP‑Firewall).

1. Zasada blokowania parametrów (zabroń, jeśli parametr zawiera <script Lub na* atrybuty)
      – Blokuj żądania, w których wpb_user_name Lub wpb_user_email parametr zawiera znaki < Lub > lub sekwencje takie jak JavaScript: Lub najechanie myszką=.
      – Przykład pseudo‑zasady (dostosuj do składni swojego WAF):
         – JEŚLI request_body zawiera param wpb_user_name LUB wpb_user_email
           I wartość pasuje do regex (?i)(<\s*skrypt\b|javascript:|on\w+\s*=)
           TO zablokuj (HTTP 403)
2. Walidacja długości i znaków
      – Blokuj, jeśli parametr e-mail zawiera znaki spoza oczekiwanego zestawu dla e-maila.
      – Odrzuć, jeśli wpb_user_name zawiera nawiasy kątowe lub długie podejrzane ładunki (> 200 znaków dla imienia jest nietypowe).
3. Ograniczenie geograficzne/ilościowe
      – Jeśli obserwujesz próby wykorzystania, zastosuj limity ilościowe lub tymczasowe CAPTCHY dla punktu rezerwacji.
4. Rejestrowanie i powiadamianie
      – Zapisz i powiadom, gdy zablokowane żądanie zostało zapisane, i wyślij odpowiednie dane żądania (bez wrażliwych ciasteczek) do swojego zespołu bezpieczeństwa.

Zastrzeżenie: Uważaj, aby unikać fałszywych pozytywów (na przykład, legalne imiona z nie‑łacińskimi znakami). Rozpocznij w trybie “wyzwania”, jeśli jest dostępny, i dostosuj zasady.

---

Jak wykrywać eksploatację i badać złośliwe wpisy

1. Inspekcja bazy danych
      – Szukaj <script Lub onerror= Lub JavaScript: w rekordach rezerwacji, postmeta i opcjach.
      – Sprawdź tabele, w których WPBookit może przechowywać dane: tabele niestandardowe, wp_posts, wp_postmeta, lub tabele specyficzne dla wtyczek.
2. Dzienniki dostępu
      – Sprawdź logi serwera WWW (nginx/apache) pod kątem żądań POST do punktów końcowych przesyłania rezerwacji z podejrzanymi ładunkami lub długimi parametrami.
      – Sprawdź skoki w żądaniach do formularza rezerwacji z pojedynczych adresów IP.
3. Logi e-mail
      – Jeśli szczegóły rezerwacji są wysyłane e-mailem, sprawdź HTML wychodzących e-maili pod kątem wstawionych skryptów.
4. Aktywność administratora
      – Sprawdź ostatnie logowania administratora, resetowanie haseł i zmiany w plikach wtyczek/motywów.
      – Przejrzyj logi aplikacji w poszukiwaniu nietypowego zachowania lub nieudanych prób eskalacji uprawnień.
5. Skanowanie systemu plików
      – Skanuj w poszukiwaniu zmienionych plików i nieznanych plików PHP (szczególnie w wp-content/uploads, wp-includes i wp-content/plugins).

---

Długoterminowe poprawki dewelopera (dla autorów wtyczek i integratorów)

Jeśli jesteś deweloperem wtyczek lub utrzymujesz integracje WPBookit, stosuj te zasady wzmacniania:

• Oczyść i zweryfikuj wszystkie dane wejściowe:
     – Użyj dezynfekuj_pole_tekstowe() dla nazw w formacie tekstowym.
     – Użyj sanitize_email() dla pól e-mail.
     – Użyj wp_kses() jeśli dozwolony jest ograniczony HTML.
• Escape na wyjściu:
     – Dla treści ciała HTML użyj esc_html().
     – Dla atrybutów HTML użyj esc_attr().
     – Dla URL-i użyj esc_url().
• Unikaj przechowywania surowego HTML w polach edytowalnych przez użytkowników, chyba że jest to absolutnie konieczne.
• Używaj nonce'ów i sprawdzania uprawnień dla ekranów administracyjnych i punktów końcowych AJAX.
• Ogranicz ilość informacji zwracanych na publicznych punktach końcowych (unikaj osadzania danych użytkowników w atrybutach HTML bez ich ucieczki).
• Chroń strony administracyjne dodatkowymi kontrolami nonce i zabezpieczeniami CSRF.
• W przypadku elementów, które będą wysyłane e-mailem, upewnij się, że treść jest oczyszczona i używaj szablonów tylko tekstowych tam, gdzie to praktyczne.

---

Dla dostawców hostingu i agencji: lista kontrolna masowej mitigacji

Jeśli zarządzasz dużymi flotami stron WordPress:

• Skanuj inwentarz pod kątem wersji WPBookit <=1.0.8 i zaplanuj aktualizacje do 1.0.9+.
• Jeśli natychmiastowa aktualizacja nie jest możliwa dla żadnej strony:
     – Zastosuj globalną regułę WAF odmawiającą niebezpiecznych wzorców w wpb_user_name I wpb_user_email.
     – Wdróż mu-plugin sanitizera na zarządzanych stronach.
     – Dodaj krótkoterminową blokadę na punkcie końcowym rezerwacji dla anonimowych zgłoszeń (lub włącz CAPTCHA).
• Komunikuj się z klientami: poinformuj ich o problemie, które strony są dotknięte i jakie kroki podejmujesz.
• Oferuj usługi naprawcze: skanowanie bazy danych, czyszczenie i monitorowanie dalszych intruzji.

---

Lista kontrolna po kompromitacji (jeśli znalazłeś złośliwe ładunki)

1. Wyłącz stronę lub przejdź w tryb konserwacji, aby zapobiec dalszym nadużyciom.
2. Zbieraj dowody kryminalistyczne: kopię systemu plików i migawkę bazy danych.
3. Zidentyfikuj i usuń złośliwe wpisy w bazie danych (usuń wstrzyknięty kod).
4. Skanuj system plików w poszukiwaniu powłok webowych, tylnej furtki i zmodyfikowanych plików PHP.
5. Zmień wszystkie klucze administracyjne, FTP/SFTP, bazy danych i API.
6. Zresetuj ciasteczka uwierzytelniające i wymuś reset haseł dla użytkowników administracyjnych.
7. Przejrzyj zaplanowane zadania (cron) pod kątem mechanizmów utrzymywania.
8. Zainstaluj czyste wersje wtyczek i zaktualizuj rdzeń WordPressa.
9. Jeśli przywracasz z kopii zapasowej, upewnij się, że punkt przywracania jest czysty i zastosuj wszystkie aktualizacje zabezpieczeń przed ponownym otwarciem.
10. Monitoruj logi i włącz wykrywanie anomalii oraz 2FA na przyszłość.

---

Zapobieganie podobnym lukom w całym Twoim środowisku WordPress.

Krótka lista kontrolna, którą powinien przyjąć każdy administrator i deweloper WordPress:

• Utrzymuj wtyczki, motywy i rdzeń zaktualizowane. Łaty mają znaczenie.
• Zmniejsz powierzchnię ataku wtyczek: usuń nieużywane wtyczki; preferuj wtyczki z aktywnym wsparciem i dziennikami zmian.
• Uruchom WAF przed swoimi stronami i utrzymuj zasady aktualne.
• Ogranicz dostęp administratora według IP, gdzie to możliwe; użyj ograniczeń sieciowych dla wp-admin i xmlrpc.php.
• Wymuszaj silne dane uwierzytelniające i 2FA dla wszystkich uprzywilejowanych kont.
• Regularnie twórz kopie zapasowe zarówno plików, jak i baz danych; testuj przywracanie.
• Używaj monitorowania bezpieczeństwa i kontroli integralności plików.
• Regularnie skanuj pod kątem podatnych wersji wtyczek i znanych CVE.

---

Często zadawane pytania

Q: Czy atakujący może to wykorzystać bez klikania czegokolwiek przez administratora?
A: W większości przypadków przechowywane XSS wymaga, aby ofiara załadowała lub wyświetliła przechowywany ładunek (na przykład, administrator przeglądający listę rezerwacji). Jednak jeśli e-maile lub procesy automatyczne renderują przechowywane dane w niebezpieczny sposób, ładunek może zostać wykonany automatycznie. Traktuj przechowywane XSS jako ryzyko o wysokim wpływie.

Q: Czy po prostu zablokowanie “” w wejściach zatrzyma atak?
A: Blokowanie oczywistych wzorców pomaga, ale wykwalifikowani atakujący używają wymijających kodowań i sprytnych ładunków. Najbezpieczniejsze podejście to obrona w głębokości: sanitizacja na wejściu, eskapada na wyjściu i zastosowanie ochron WAF.

Q: Jeśli zaktualizuję do 1.0.9, czy jestem całkowicie bezpieczny?
A: Aktualizacja do poprawionej wtyczki jest podstawowym rozwiązaniem. Po aktualizacji nadal skanuj swoją bazę danych w poszukiwaniu wstrzykniętej treści i upewnij się, że nie pozostały żadne złośliwe artefakty.

---

Przykładowa oś czasu incydentu (jak może przebiegać atak)

• Dzień 0: Atakujący identyfikuje podatną instalację WPBookit i składa rezerwację z zakodowanym ładunkiem XSS w wpb_user_name.
• Dzień 1: Rezerwacja jest przechowywana w bazie danych witryny. Atakujący wysyła spreparowany e-mail do administratora witryny, zachęcając go do obejrzenia rezerwacji w obszarze administracyjnym.
• Dzień 2: Administrator klika w link, przegląda rezerwację; ładunek działa w kontekście administratora i wykrada ciasteczko sesji do atakującego.
• Dzień 3–4: Atakujący wykorzystuje sesję do stworzenia konta administratora z tylnym wejściem i przesyła trwały skrypt PHP. Dochodzi do kompromitacji witryny i możliwego ruchu bocznego.

Szybsze wykrywanie i środki zapobiegawcze przerywają ten łańcuch w wielu punktach.

---

Chroń swoją stronę teraz — zacznij od darmowego planu WP‑Firewall

Jeśli zarządzasz witrynami WordPress i chcesz natychmiastowej, zarządzanej ochrony podczas wykonywania powyższych kroków, WP‑Firewall oferuje darmowy plan podstawowy, który zapewnia niezbędne zabezpieczenia dostosowane do ryzyk związanych z WordPress. Plan podstawowy (darmowy) obejmuje:

• Zarządzany zapora z regułami WAF dostosowanymi do typowych ataków na WordPress
• Nielimitowana przepustowość i ochrona dla Twojej witryny
• Skaner złośliwego oprogramowania do wykrywania podejrzanych plików i modyfikacji
• Reguły łagodzenia dla ryzyk OWASP Top 10 (w tym wzorce XSS)
• Łatwa aktywacja, abyś mógł zastosować wirtualne łatanie podczas aktualizacji wtyczek

Zalecamy zapisanie się na darmowy plan, aby zapewnić natychmiastowe wirtualne łatanie i monitorowanie podczas łatania WPBookit na swoich witrynach. Aby uzyskać szczegóły i rozpocząć natychmiastową ochronę swojej witryny, odwiedź:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Jeśli potrzebujesz bardziej zaawansowanej automatycznej naprawy, możliwości zezwolenia/odmowy IP lub miesięcznych raportów dla klientów, rozważ nasze płatne poziomy, które dodają automatyczne usuwanie złośliwego oprogramowania, czarną/białą listę IP, zaplanowane raporty, automatyczne wirtualne łatanie i inne.

---

Końcowa rada od inżynierów WP‑Firewall

• Priorytetowe aktualizacje: gdy wtyczka ma nieautoryzowane przechowywane XSS, zakładaj, że będzie celem i aktualizuj jak najszybciej.
• Używaj wielu warstw: WAF + utwardzanie aplikacji + monitorowanie zapewnia znacznie lepszą ochronę niż jakakolwiek pojedyncza kontrola.
• Działaj szybko, ale ostrożnie: jeśli podejrzewasz kompromitację, postępuj zgodnie z udokumentowanym planem reakcji na incydenty, zachowaj dowody i naprawiaj, stosując zweryfikowane kroki.

Jeśli potrzebujesz pomocy w wykrywaniu, wirtualnym łataniu lub pełnych usługach czyszczenia, WP‑Firewall jest dostępny, aby pomóc. Zacznij od darmowego planu, aby natychmiast włączyć zarządzane zabezpieczenia WAF i zmniejszyć natychmiastowe ryzyko podczas łatania, badania i czyszczenia.

---

Zasoby i przydatne polecenia

• WP‑CLI do znajdowania instalacji wtyczki WPBookit:
  wp plugin list --format=table --fields=name,version | grep -i wpbookit
• Przeszukaj bazę danych w poszukiwaniu ładunków skryptów (najpierw zrób kopię zapasową):
  WYBIERZ ID, tytuł_postu Z wp_posts GDZIE post_content LUBIĘ '%
• Szybkie skanowanie systemu plików (Linux):
  grep -RIl --exclude-dir=vendor --exclude-dir=node_modules "<script" wp-content/

---

To ostrzeżenie zostało napisane przez Zespół Bezpieczeństwa WP‑Firewall, aby pomóc właścicielom stron WordPress szybko i odpowiedzialnie zareagować na ujawnienie CVE‑2026‑1945 dotyczące WPBookit <=1.0.8. Jeśli potrzebujesz pomocy w zastosowaniu tymczasowych środków zaradczych, tworzeniu reguł WAF lub przeprowadzaniu sprzątania po incydencie, nasz zespół może pomóc.