Nazwa wtyczki	Wtyczka API Planaday
Rodzaj podatności	Atak typu cross-site scripting (XSS)
Numer CVE	CVE-2024-11804
Pilność	Średni
Data publikacji CVE	2026-02-28
Adres URL źródła	CVE-2024-11804

Odbity XSS w wtyczce API Planaday (≤ 11.4): Co właściciele stron WordPress muszą teraz zrobić

Autor: Zespół ds. bezpieczeństwa WP-Firewall
Data: 2026-02-26
Tagi: WordPress, Bezpieczeństwo, WAF, Luka, XSS, Wtyczka

Streszczenie: Odbita luka Cross-Site Scripting (XSS) wpływająca na wtyczkę API Planaday WordPress (wersje ≤ 11.4, naprawiona w 11.5 — CVE-2024-11804) została ujawniona. Ten post wyjaśnia, co ta luka oznacza dla Twojej strony, jak napastnicy mogą ją wykorzystać, jak wykryć wykorzystanie oraz krok po kroku wskazówki dotyczące łagodzenia i odzyskiwania z perspektywy zapory ogniowej WordPress i operacji bezpieczeństwa.

---

Spis treści

• Co się stało (wysoki poziom)
• Dlaczego odbity XSS ma znaczenie dla stron WordPress
• Szczegóły techniczne (podsumowanie luki)
• Praktyczne scenariusze ryzyka (jak napastnik może to wykorzystać)
• Natychmiastowe działania, które powinieneś podjąć (0–24 godziny)
• Krótkoterminowe łagodzenia, jeśli nie możesz natychmiast zaktualizować (1–7 dni)
• Jak zapora aplikacji internetowej (WAF) taka jak WP­Firewall chroni Cię
• Wzmacnianie i długoterminowe zabezpieczenia (poza zastosowaniem łatki)
• Wykrywanie wykorzystania i badanie kompromitacji
• Lista kontrolna odzyskiwania, jeśli wykryjesz naruszenie
• Najlepsze praktyki dla deweloperów wtyczek (jak to powinno być zapobiegane)
• Chroń swoją witrynę teraz — zacznij od darmowego planu WP-Firewall
• Wnioski i ostateczne zalecenia
• Dodatek: przykładowe zasady WAF i fragmenty blokujące serwer

---

Co się stało (wysoki poziom)

26 lutego 2026 roku badacze bezpieczeństwa opublikowali szczegóły dotyczące odbitej luki Cross-Site Scripting (XSS) w wtyczce API Planaday WordPress, wpływającej na wersje do 11.4. Dostawca wydał wersję 11.5, aby rozwiązać problem.

Ta luka ma równoważną powagę CVSS w górnym średnim zakresie (zgłoszona jako CVSS 7.1). Chociaż jest to odbity XSS (które zazwyczaj wymaga, aby użytkownik odwiedził spreparowany URL lub kliknął złośliwy link), raport wskazuje, że atak może być zainicjowany przez nieautoryzowanego aktora i staje się niebezpieczny, gdy uwierzytelniony administrator lub inny uprzywilejowany użytkownik wchodzi w interakcję z złośliwie spreparowanym zasobem. Ta kombinacja — nieautoryzowany napastnik + działanie uprzywilejowanego użytkownika — jest szczególnie niepokojąca na stronach WordPress, ponieważ może prowadzić do przejęcia konta, kradzieży ciasteczek sesyjnych lub działań administracyjnych wykonywanych bez zgody.

Jako zespół, który buduje i obsługuje WP­Firewall (zapora WAF skoncentrowana na WordPressie i zarządzana usługa bezpieczeństwa), chcemy dać Ci praktyczne, priorytetowe wskazówki: co zrobić teraz, jak szybko złagodzić, jeśli nie możesz natychmiast zaktualizować, jak wykryć nadużycia i jak odzyskać, jeśli wydarzy się najgorsze.

---

Dlaczego odbity XSS ma znaczenie dla stron WordPress

Odbity XSS to luka wstrzyknięcia, w której złośliwy skrypt jest odbity z serwera w odpowiedzi na wartość dostarczoną przez napastnika (na przykład parametry zapytania, dane formularza lub fragmenty URL). Zazwyczaj wymaga ofiary (administrator strony lub zalogowany użytkownik), aby kliknęła spreparowany link lub odwiedziła stronę zawierającą ten link. Ale gdy ofiarą jest administrator lub użytkownik z podwyższonymi uprawnieniami, wpływ szybko się eskaluje:

• Przechwytywanie sesji: Kradnij ciasteczka sesyjne lub tokeny uwierzytelniające, aby podszyć się pod administratorów.
• Kradzież poświadczeń i phishing: Prezentuj fałszywe powiadomienia lub formularze administracyjne w celu zbierania poświadczeń.
• Eskalacja uprawnień: Wykorzystaj uprawnienia administratora do przesyłania backdoorów, zmiany ustawień witryny lub wstrzykiwania trwałej złośliwej treści.
• Ryzyko związane z łańcuchem dostaw: Administratorzy zarządzający wieloma witrynami mogą ponownie używać poświadczeń lub kluczy API, co zwiększa szkody.

W WordPressie, odzwierciedlone XSS w wtyczce, która wchodzi w interakcję z stronami administracyjnymi, importowanymi danymi lub punktami końcowymi REST, staje się wektorem dla atakujących do kompromitacji witryny, nawet gdy luka wymaga, aby administrator kliknął coś — atakujący mogą zwabić administratorów za pomocą ukierunkowanego phishingu, wykorzystać narażone strony administracyjne lub osadzić złośliwą treść w e-mailach lub pulpitach nawigacyjnych.

---

Szczegóły techniczne (podsumowanie luki)

• Dotknięta wtyczka: Planaday API (wtyczka WordPress)
• Dotyczy wersji: ≤ 11,4
• Poprawione w: 11.5
• Klasa podatności: Odbite Cross-Site Scripting (XSS)
• CVE: CVE-2024-11804
• Zgłoszona powaga: Średni (CVSS ~7.1)
• Wymagania dotyczące wykorzystania: Wejście kontrolowane przez atakującego odzwierciedlone w odpowiedzi; interakcja użytkownika przez uwierzytelnionego/uprzywilejowanego użytkownika wymagana do wykonania kontekstu skryptu
• Powierzchnia ataku: punkty końcowe frontendowe i/lub administracyjne, które odzwierciedlają niesanitizowane wejście w HTML bez odpowiedniego uciekania lub filtrowania, lub w kontekstach JavaScript bez sanitizacji/enkodowania

Głównym problemem w odzwierciedlonym XSS jest to, że dane dostarczone przez żądanie (ciąg zapytania, ciało POST, nagłówki, referer itp.) trafiają do odpowiedzi HTML bez odpowiedniego uciekania lub walidacji. Jeśli ta odpowiedź jest przetwarzana przez przeglądarkę i nie jest neutralizowana przez Content-Security-Policy lub bezpieczne funkcje kodowania, ładunek zostanie wykonany.

Nie opublikujemy tutaj kodu exploita ani dokładnych ładunków ataków — publikacja exploita ułatwia życie oportunistycznym atakującym. Zamiast tego, ten post koncentruje się na działaniach defensywnych i dochodzeniowych.

---

Praktyczne scenariusze ryzyka (jak napastnik może to wykorzystać)

1. Phishing administratora
   • Atakujący tworzy URL, który zawiera złośliwy skrypt w odzwierciedlonym parametrze.
   • Administrator otrzymuje przekonujący e-mail lub wiadomość na pulpicie i klika w link.
   • Złośliwy skrypt wykonuje się w kontekście sesji administratora, kradnąc ciasteczka lub wykonując działania administracyjne.
2. Złośliwy komentarz lub zewnętrzna treść
   • Jeśli wtyczka odzwierciedla wartości, które mogą być zawarte w stronach wyświetlanych edytorom lub administratorom (np. ekrany podglądu lub treści napędzane API), atakujący może wstrzyknąć skonstruowany URL lub post, który otworzy administrator.
3. Link międzystronowy w treści stron trzecich
   • Atakujący używa forum, czatu lub wydarzenia w kalendarzu, aby opublikować spreparowany link. Edytor lub administrator strony przeglądający link podczas uwierzytelnienia uruchamia XSS.
4. Przejście do trwałego kompromitacji
   • Odbity XSS jest używany do stworzenia trwałej zmiany (np. utworzenie użytkownika administratora, wstrzyknięcie pliku z tylnym wejściem lub zainstalowanie złośliwego wtyczki), przekształcając jednorazowy atak odbity w trwały kompromitację.

---

Natychmiastowe działania, które powinieneś podjąć (0–24 godziny)

1. Natychmiast zaktualizuj wtyczkę.
   • Jeśli Twoja strona korzysta z API Planaday, zaktualizuj do wersji 11.5 lub nowszej. To jest najważniejszy krok.
2. Jeśli nie możesz teraz zaktualizować, wyłącz wtyczkę
   • Dezaktywuj lub odinstaluj wtyczkę, aż będziesz mógł zastosować poprawkę. To zapobiega przetwarzaniu żądań przez podatny kod.
3. Wprowadź tymczasowe zabezpieczenia
   • Użyj WP­Firewall, aby zastosować regułę łagodzącą (wirtualne łatanie), która blokuje żądania zawierające podejrzane wzorce (zobacz przykładowe reguły WAF poniżej).
   • Blokuj podejrzane ciągi zapytań i wzorce wejściowe na poziomie serwera WWW lub WAF.
4. Chroń konta administratorów
   • Wymuś wylogowanie wszystkich użytkowników i obróć tokeny sesji administratora.
   • Natychmiast zresetuj hasła dla wszystkich administratorów.
   • Włącz lub zweryfikuj uwierzytelnianie dwuskładnikowe (2FA) dla kont administratorów.
5. Przejrzyj logi dostępu
   • Sprawdź logi serwera WWW i logi zapory ogniowej pod kątem nietypowych żądań, powtarzających się prób zawierających tagi skryptów lub podejrzane znaki oraz wszelkich żądań do specyficznych punktów końcowych wtyczek.
6. Skanuj w poszukiwaniu zagrożeń
   • Przeprowadź pełne skanowanie złośliwego oprogramowania i integralności plików na stronie. Jeśli wykryjesz podejrzane pliki PHP, zmodyfikowane pliki rdzenia lub wtyczek, lub nieznane konta administratorów, traktuj stronę jako skompromitowaną i postępuj zgodnie z poniższymi krokami odzyskiwania.

---

Krótkoterminowe łagodzenia, jeśli nie możesz zaktualizować natychmiast (1–7 dni)

Jeśli zastosowanie poprawki dostawcy nie jest możliwe w ciągu kilku godzin, wdroż warstwowe łagodzenia, aby zmniejszyć ryzyko:

• Twardo blokuj znane złe wzorce wejściowe za pomocą swojego WAF (wirtualna poprawka)
  • Blokuj żądania, które zawierają lub javascript: w ciągach zapytań lub wartościach nagłówków.
  • Blokuj żądania z typowymi sygnaturami ładunków XSS (np. zakodowane tagi skryptów, obsługiwacze onerror=).
• Użyj Content-Security-Policy (CSP)
  • Dodaj restrykcyjną CSP, która zabrania skryptów inline i pozwala tylko na skrypty z zaufanych źródeł. Przykład: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...';
  • CSP nie jest złotym środkiem, ale może zapobiec wielu atakom XSS odzwierciedlonym.
• Wymuś ciasteczka HttpOnly i Secure
  • Ustaw ciasteczka PHPSESSID i auth na HttpOnly i Secure oraz użyj SameSite=strict tam, gdzie to możliwe.
• Ogranicz punkty końcowe administracyjne wtyczek za pomocą białej listy IP
  • Jeśli administratorzy łączą się z znanych zakresów IP, ogranicz dostęp do /wp-admin/ i punktów końcowych wtyczek do tych zakresów na krótki okres.
• Wyłącz niepotrzebne role użytkowników i zminimalizuj liczbę administratorów
  • Usuń lub zdegradować konta administratorów, które nie są potrzebne.
• Wzmocnij świadomość na temat e-maili i phishingu
  • Ostrzeż swój zespół administracyjny, aby nie klikał w linki w e-mailach, dopóki wtyczka nie zostanie zaktualizowana.

---

Jak zapora aplikacji internetowej (WAF) taka jak WP­Firewall chroni Cię

Nowoczesny WAF skoncentrowany na WordPressie zapewnia kilka warstw obronnych szczególnie cennych dla odzwierciedlonych XSS opartych na wtyczkach:

• Wirtualne łatanie (zasady łagodzenia)
  • Możemy stworzyć ukierunkowane zasady, które pasują do wzorca eksploatacji (na przykład blokowanie żądań do konkretnych punktów końcowych wtyczek zawierających znaki podobne do ładunków) i zastosować je natychmiast na twojej stronie bez modyfikacji kodu wtyczki.
• Blokowanie z uwzględnieniem kontekstu
  • Zamiast bezmyślnie blokować wszystkie żądania z “”, zaawansowany WAF sprawdza, gdzie dane byłyby odzwierciedlane (parametr URL, nagłówek, POST) i blokuje tylko te, które pasują do wektora ataku, redukując fałszywe alarmy.
• Ograniczenie liczby żądań i zarządzanie botami
  • Napastnicy często szybko sprawdzają wiele adresów URL. Ograniczenie liczby żądań i wykrywanie botów mogą zablokować zautomatyzowane skanery i próby eksploatacji.
• Wirtualne łatanie plus logowanie i powiadomienia
  • Gdy WAF blokuje żądanie, rejestruje próbę i wydaje powiadomienia, dając ci wgląd w aktywne próby eksploatacji.
• Integracja z kanałami informacji o lukach
  • Usługa zabezpieczeń, która śledzi ujawnione luki, może automatycznie dodawać zasady dla nowo ujawnionych CVE (w tym omawianego) i dystrybuować je do chronionych witryn.

Jeśli jesteś użytkownikiem WP­Firewall, włącz łagodzenie dla “Reflected XSS – Planaday API (CVE-2024-11804)” tak szybko, jak to możliwe, i upewnij się, że Twój WAF aktywnie blokuje podejrzane wzorce.

---

Wzmacnianie i długoterminowe zabezpieczenia (poza zastosowaniem łatki)

1. Zasada najmniejszych uprawnień
   • Zmniejsz liczbę użytkowników administracyjnych.
   • Daj redaktorom i autorom tylko te uprawnienia, których potrzebują.
2. Silna autoryzacja
   • Wymuś 2FA dla administratorów.
   • Używaj silnych, losowo generowanych haseł i menedżera haseł.
   • Unikaj ponownego używania haseł w różnych witrynach i usługach.
3. Utrzymuj wszystko zaktualizowane
   • Używaj rutyny konserwacyjnej (lub zarządzanej usługi), aby szybko stosować aktualizacje dla rdzenia WordPressa, motywów i wtyczek.
   • Rozważ automatyczne aktualizacje dla drobnych/poprawek, gdzie to stosowne.
4. Wzmocnij ustawienia serwera i PHP.
   • Wyłącz edytowanie plików w wp-admin: define('DISALLOW_FILE_EDIT', true);
   • Ogranicz wykonanie PHP w katalogach przesyłania, które można zapisywać.
   • Używaj kont użytkowników bazy danych z minimalnymi uprawnieniami i ogranicz dostęp zdalny do DB.
5. Monitorowanie i wykrywanie
   • Wdrażaj monitorowanie integralności plików (FIM), aby ostrzegać o nieoczekiwanych zmianach plików.
   • Używaj regularnych automatycznych skanów złośliwego oprogramowania i planuj audyty witryn.
   • Przekazuj krytyczne logi do scentralizowanego systemu logowania lub SIEM w celu korelacji.
6. Strategia kopii zapasowej
   • Utrzymuj zdalne, niezmienne kopie zapasowe z częstymi zrzutami.
   • Regularnie testuj proces przywracania kopii zapasowej.
7. Bezpieczny cykl życia rozwoju dla wtyczek
   • Programiści wtyczek powinni walidować i sanitizować wszystkie przychodzące dane, uciekać wyjście za pomocą odpowiednich funkcji kontekstowych i używać nonce'ów dla żądań zmieniających stan.

---

Wykrywanie wykorzystania i badanie kompromitacji

Objawy, które wymagają natychmiastowego zbadania:

• Nowe lub nieznane konta administratorów.
• Pliki z ostatnimi nieoczekiwanymi zmianami (szczególnie pliki PHP).
• Nieznane zaplanowane zadania (cron jobs) w WordPressie.
• Nieznane połączenia wychodzące z twojego serwera.
• Dziwne przekierowania wpływające na strony administracyjne lub frontend witryny.
• Skargi od użytkowników na spam, wyskakujące okna lub przekierowania.

Kroki dochodzeniowe:

1. Triage logów
   • Przejrzyj logi dostępu serwera WWW w poszukiwaniu żądań z podejrzanymi ciągami zapytań, dziwnymi agentami użytkownika lub żądaniami POST do punktów końcowych wtyczek.
   • Sprawdź logi WAF — zablokowane żądania są często najczytelniejszym sygnałem prób wykorzystania.
2. Szukaj wskaźników ładunku
   • Szukaj zakodowanych znaczników skryptów, atrybutów onerror/onload lub nietypowych ciągów zakodowanych w Base64 w postach, stronach i opcjach.
3. Sprawdź użytkowników i role
   • Eksportuj listy użytkowników i szukaj kont utworzonych w czasie podejrzanych wpisów w logach.
4. Sprawdź integralność plików
   • Porównaj bieżące pliki z znanym dobrym kopią zapasową. Zwróć szczególną uwagę na wp-config.php, funkcje.php, oraz katalogach wtyczek.
5. Sprawdź zaplanowane wydarzenia
   • Lista wp_cron wydarzenia i upewnij się, że żadne nie są podejrzane.
6. Jeśli znajdziesz dowody na kompromitację
   • Umieść witrynę w trybie konserwacji, wyłącz ją, jeśli to konieczne, odizoluj od sieci, a następnie przejdź do poniższych kroków odzyskiwania.

---

Lista kontrolna odzyskiwania, jeśli wykryjesz naruszenie

1. Wyłącz witrynę (jeśli to konieczne)
   • Zapobiegaj dalszym szkodom podczas dochodzenia.
2. Zachowaj dowody
   • Zrób kopie logów i zrzut systemu plików do celów kryminalistycznych.
3. Usuń wektor ataku
   • Zaktualizuj lub usuń podatny plugin; zastosuj łatkę dostawcy; usuń wszelkie wstrzyknięte złośliwe pliki.
4. Przywróć z czystej kopii zapasowej
   • Jeśli masz niedawny, czysty backup sprzed kompromitacji, przywróć go, a następnie zastosuj aktualizację.
5. Zmień wszystkie dane uwierzytelniające
   • Zresetuj wszystkie hasła administratorów i użytkowników, dane logowania do bazy danych, klucze API oraz wszelkie specyficzne dla witryny tokeny.
   • Unieważnij sesje (wymuś wylogowanie wszystkich użytkowników).
6. Ponownie przeskanuj i zweryfikuj
   • Uruchom wiele skanów w poszukiwaniu złośliwego oprogramowania i integralności, aby upewnić się, że nie pozostały żadne tylne drzwi.
7. Ponownie włącz zabezpieczenia i monitoruj
   • Wprowadź zasady WAF, ponownie włącz monitorowanie i uważnie obserwuj logi w poszukiwaniu powtórzeń.
8. Komunikacja
   • Jeśli dane klientów lub konta użytkowników zostały dotknięte, postępuj zgodnie z wymaganiami ujawnienia i powiadom dotkniętych interesariuszy z odpowiednimi szczegółami.

---

Najlepsze praktyki dla deweloperów wtyczek (jak to powinno być zapobiegane)

Programiści, którzy dostarczają kod, który jest dostępny w sieci, muszą przestrzegać praktyk bezpiecznego kodowania:

• Oczyść dane wejściowe
  • Używaj pomocników sanitarnych WordPressa dla danych przychodzących: dezynfekuj_pole_tekstowe(), intval(), wp_filter_nohtml_kses()itd.
• Używaj odpowiedniego kontekstu do ucieczki danych wyjściowych
  • Dla kontekstów HTML: esc_html()
  • Dla kontekstów atrybutów: esc_attr()
  • Dla kontekstów JS: esc_js() + json_encode() gdy osadzasz zmienne PHP w skryptach
• Używaj funkcji specyficznych dla API
  • Podczas tworzenia punktów końcowych REST, waliduj i sanitizuj argumenty za pomocą zarejestruj_pole_rest/register_rest_route callbacków i używaj parametrów ‘sanitize_callback’ i ‘validate_callback’.
• Wymuszaj kontrole nonces i możliwości
  • Wszystkie żądania zmieniające stan powinny wymagać weryfikacji nonce i sprawdzenia uprawnień (bieżący_użytkownik_może()).
• Unikaj bezpośredniego wyświetlania danych wejściowych użytkownika w odpowiedziach
  • Preferuj bezpieczne wzorce renderowania danych i stosuj ucieczkę w ostatniej chwili.
• Wprowadź zautomatyzowane pokrycie testami dla bezpieczeństwa
  • Uwzględnij testy sprawdzające, czy wyjścia wtyczki są odpowiednio zabezpieczone oraz czy punkty końcowe REST walidują i oczyszczają dane wejściowe.

---

Chroń swoją witrynę teraz — zacznij od darmowego planu WP-Firewall

Czy chcesz natychmiastowej warstwy bezpieczeństwa podczas aktualizacji wtyczek? WP­Firewall oferuje darmowy plan Basic zaprojektowany dla właścicieli stron, którzy chcą podstawowej, zarządzanej ochrony bez skomplikowanej konfiguracji. Plan Basic (darmowy) obejmuje aktywnie zarządzany zaporę aplikacji webowej (WAF), nielimitowaną przepustowość, skanowanie złośliwego oprogramowania oraz łagodzenie zagrożeń skierowanych na OWASP Top 10 — dokładnie takie rodzaje ochrony, które pomagają zatrzymać próby wykorzystania odzwierciedlonego XSS.

Jeśli chcesz szybkiej, łatwej ochrony podczas aktualizacji do poprawionej wersji wtyczki, zarejestruj się w darmowym planie tutaj:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Przejście na płatny plan dodaje automatyczne usuwanie złośliwego oprogramowania, dostosowane czarne/białe listy adresów IP, wirtualne łatanie luk i raportowanie — funkcje, które przyspieszają odzyskiwanie i zmniejszają ręczne obciążenie, jeśli zostanie podjęta próba ataku na Twoją stronę.

---

Wnioski i ostateczne zalecenia

Luki w odzwierciedlonym XSS, takie jak CVE-2024-11804 w API Planaday, są niebezpieczne, ponieważ łączą nieautoryzowaną powierzchnię ataku z potencjałem do kompromitacji uprzywilejowanych użytkowników. Najprostsze, najskuteczniejsze natychmiastowe działanie dla każdego właściciela strony korzystającego z wtyczki to aktualizacja do wersji 11.5.

Jeśli nie możesz zaktualizować natychmiast, podejmij ostrożne kroki łagodzące: dezaktywuj wtyczkę, zastosuj wirtualne łaty WAF, egzekwuj ścisłe zabezpieczenia konta administratora i dokładnie skanuj. Użyj warstwowych zabezpieczeń — WAF, CSP, flagi bezpiecznych ciasteczek, 2FA, ograniczony dostęp administratora — aby zmniejszyć szansę na sukces atakującego.

Na koniec przyjmij rytm konserwacji z priorytetem bezpieczeństwa: aktualizuj niezwłocznie, regularnie przeprowadzaj skany, utrzymuj kopie zapasowe i stosuj zasadę najmniejszych uprawnień dla kont administracyjnych. Jeśli potrzebujesz pomocy w implementacji wirtualnych łatek, ustawianiu zasad izolacji lub przeprowadzaniu dochodzenia kryminalistycznego, zespół WP­Firewall może szybko Ci pomóc — zacznij od naszego darmowego planu Basic, aby dodać tę natychmiastową warstwę ochrony.

Bądź bezpieczny i utrzymuj swoją stronę w aktualności.

— Zespół Bezpieczeństwa WP-Firewall

---

Dodatek: przykładowe zasady WAF/serwera (nie kopiuj bezmyślnie — testuj pod kątem fałszywych pozytywów)

Uwaga: Najpierw przetestuj każdą zasadę w środowisku staging. To są ilustracyjne wzory, które możesz dostosować do swojego WAF lub serwera.

1. Podstawowa zasada nginx (blokuj, jeśli ciąg zapytania zawiera tagi skryptów)

   if ($query_string ~* "<script|%3Cscript|javascript:|onerror=|onload=") {
       return 403;
   }

2. Przykład Apache/mod_security (koncepcyjny)

   SecRule ARGS|ARGS_NAMES|REQUEST_HEADERS "@rx (<|%3C)(script|img|svg|iframe)|onerror=|onload=" 
       "id:100001,deny,log,msg:'Possible reflected XSS attack - blocked'"

3. Bardziej ukierunkowana zasada dla WAF (pseudo-regex)

   – Blokuj żądania do punktów końcowych wtyczki, które zawierają nawiasy kątowe lub obsługiwane zdarzenia:

   URI żądania zawiera: /wp-content/plugins/planaday-api/<|%3C).*?(script|iframe|svg|img|onerror|onload|javascript:)
   THEN block with 403 and log

4. Nagłówek Content-Security-Policy (przykład)

   Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.example.com; object-src 'none'; base-uri 'self'; frame-ancestors 'none';

5. Blokuj podejrzane nagłówki Referer (tymczasowo)

   - Jeśli zauważysz powtarzające się próby eksploatacji pochodzące z małego zestawu refererów, zablokuj je w WAF.

---

Jeśli chcesz otrzymać plan pomocy krok po kroku dostosowany do Twojej witryny (analizowane logi, wdrożone zasady WAF i harmonogram naprawy od ograniczenia do odzyskania), skontaktuj się z pomocą WP­Firewall lub zarejestruj się w darmowym planie Basic, aby uzyskać natychmiastową, zarządzaną ochronę WAF: https://my.wp-firewall.com/buy/wp-firewall-free-plan/