Nazwa wtyczki	Motyw Bricks Builder dla WordPress
Rodzaj podatności	Cross Site Scripting
Numer CVE	CVE-2026-41554
Pilność	Średni
Data publikacji CVE	2026-04-25
Adres URL źródła	CVE-2026-41554

Odbity XSS w motywie Bricks Builder (CVE‑2026‑41554): Co właściciele stron WordPress muszą teraz zrobić

Autor: Zespół ds. bezpieczeństwa WP‑Firewall
Data: 2026-04-25

Szczegółowy, praktyczny przewodnik dla właścicieli i administratorów stron WordPress na temat podatności na odbity XSS wpływającej na motyw Bricks Builder (CVE‑2026‑41554). Kroki do wykrywania, łagodzenia, wirtualnego łatania i wzmacniania stron — napisane z perspektywy eksperta ds. bezpieczeństwa WP‑Firewall.

Krótko mówiąc
Odbita podatność na Cross‑Site Scripting (XSS) (CVE‑2026‑41554) dotyczy wersji motywu Bricks Builder od 1.9.2 do wersji przed 2.3. Problem jest wykorzystywalny bez uwierzytelnienia i ma podstawowy wynik CVSS wynoszący 7.1. Natychmiast zaktualizuj do Bricks Builder 2.3 lub nowszej. Jeśli nie możesz teraz zaktualizować, zastosuj wirtualne łatanie za pomocą swojego zapory aplikacji webowej (WAF), wdroż ścisłe nagłówki bezpieczeństwa (CSP, X‑Content‑Type‑Options, X‑Frame‑Options), audytuj uprawnienia użytkowników i skanuj swoją stronę w poszukiwaniu oznak kompromitacji.

---

Dlaczego to ma znaczenie

Odbity XSS pozostaje jednym z najczęściej używanych wektorów w kampaniach masowych. Nieautoryzowany atakujący może stworzyć URL zawierający złośliwy ładunek i przekonać uprzywilejowanego użytkownika lub odwiedzającego stronę do kliknięcia w niego. Gdy zostanie pomyślnie odbity przez stronę, ładunek wykonuje się w kontekście przeglądarki ofiary. Może to prowadzić do kradzieży sesji, eskalacji uprawnień, dowolnego wykonywania JavaScript, phishingu i dystrybucji złośliwej zawartości — wszystko to szkodzi reputacji, rankingom w wyszukiwarkach i zaufaniu klientów.

Ta konkretna podatność dotyczy motywu Bricks Builder i została publicznie ujawniona 23 kwietnia 2026 roku. Jest klasyfikowana jako odbity XSS i ma średni priorytet z wynikiem CVSS wynoszącym 7.1. Dostawca naprawił problem w wersji 2.3. Jeśli Twoja strona działa na wersji Bricks Builder od 1.9.2 do (ale nie włącznie) 2.3, uważaj się za podatnego, dopóki nie zaktualizujesz lub nie zastosujesz łagodzeń.

---

Czym jest odbity XSS (krótkie wprowadzenie)

Odbity XSS występuje, gdy aplikacja webowa przyjmuje nieufne dane wejściowe (często z parametrów zapytania, pól formularzy lub nagłówków) i włącza je dosłownie w natychmiastowej odpowiedzi HTTP bez odpowiedniego kodowania lub sanitizacji. W przeciwieństwie do XSS przechowywanego, ładunek atakującego nie jest przechowywany na serwerze — jest osadzony w stworzonym linku lub żądaniu i “odbity” z powrotem do użytkownika.

Kluczowe właściwości odbitego XSS:

• Zazwyczaj wymaga interakcji (użytkownik klika w stworzony link lub odwiedza stworzona stronę).
• Wpływa na kontekst przeglądarki użytkownika, który widzi stworzona odpowiedź.
• Może być używane do przejmowania sesji, wykonywania działań w imieniu uwierzytelnionych użytkowników lub dostarczania dodatkowego złośliwego oprogramowania.

Ponieważ ta podatność jest wykorzystywalna bez uwierzytelnienia, każdy odwiedzający lub uprzywilejowany użytkownik, który kliknie w złośliwy link, może stać się ofiarą.

---

Szczegóły (co wiemy)

• Typ podatności: Odbite skrypty międzystronowe (XSS)
• Produkt dotknięty: Motyw Bricks Builder (motyw WordPress)
• Wersje podatne na ataki: wersje od 1.9.2 do wersji przed 2.3
• Poprawione w: 2.3
• CVE: CVE‑2026‑41554
• Wymagane uprawnienia: Brak (nieautoryzowane)
• Wykorzystanie wymaga: Interakcja użytkownika (kliknięcie w złośliwy URL lub odwiedzenie stworzona strony)
• Powaga: Średni (Patchstack zgłosił wynik CVSS wynoszący 7.1)

Wrażliwość to klasyczny wzorzec “niezabezpieczonego odbicia”: niektóry parametr żądania lub fragment jest odzwierciedlany w odpowiedzi bez poprawnego zabezpieczenia dla kontekstów HTML i JavaScript. Ponieważ wrażliwość jest odbita, głównym środkiem zaradczym jest aktualizacja do poprawionej wersji. Drugorzędne środki zaradcze obejmują walidację/enkodowanie wejścia, CSP i zasady WAF.

---

Realistyczne scenariusze ataków

Napastnicy będą preferować taktyki niskiego wysiłku i wysokiej nagrody. Oto prawdopodobne scenariusze:

• Phishing do administratorów — Napastnik wysyła spreparowany link do administratora strony. Po kliknięciu skrypt kradnie ciasteczko uwierzytelniające lub cicho wyzwala akcję (np. tworzenie użytkownika administratora lub zmiana treści).
• Infekcja drive-by — Odwiedzający stronę podąża za udostępnionym linkiem (media społecznościowe, fora). Złośliwy skrypt wykonuje się i przekierowuje do ładunku lub prosi odwiedzającego o pobranie fałszywej aktualizacji lub wtyczki.
• Spam SEO i zniekształcenie — Wstrzyknięty skrypt modyfikuje treść lub reklamy, prowadząc do spamu SEO (ukryte linki, przekierowania afiliacyjne), co szkodzi rankingom wyszukiwania.
• Przechwycenie sesji podczas sesji uprzywilejowanych — Jeśli zalogowany edytor lub administrator odwiedza URL, napastnik może przejąć sesję i uzyskać pełną kontrolę nad stroną.

Ponieważ napastnicy mogą celować zarówno w publicznych odwiedzających, jak i zalogowanych pracowników, każda strona WordPress działająca na dotkniętej wersji Bricks Builder powinna traktować to jako priorytet do naprawy lub złagodzenia.

---

Natychmiastowe kroki (co zrobić teraz)

Jeśli zarządzasz jedną lub więcej stron WordPress, które używają Bricks Builder, postępuj zgodnie z tą listą kontrolną w kolejności:

1. Inwentaryzacja
   • Zidentyfikuj wszystkie strony używające Bricks Builder i zanotuj wersję motywu.
   • Użyj swojego narzędzia zarządzającego/panelu kontrolnego hosta lub WP-CLI:

     wp theme list --status=active --format=table

2. Aktualizacja (główna, ostateczna poprawka)
   • Zaktualizuj Bricks Builder do wersji 2.3 lub nowszej na każdej dotkniętej stronie.
   • Użyj pulpitu WordPress Aktualizacje, panelu kontrolnego swojego hosta lub WP-CLI:

     aktualizacja motywu wp bricks

   • Zweryfikuj sukces aktualizacji i przetestuj podstawową funkcjonalność strony w środowisku stagingowym, jeśli to możliwe.
3. Jeśli nie możesz zaktualizować natychmiast — zastosuj wirtualne łatanie i środki zaradcze
   • Włącz i dostosuj zarządzany WAF (zapora aplikacji webowej).
   • Zablokuj lub oczyść żądania, które zawierają podejrzane ładunki (tagi skryptów, atrybuty zdarzeń, zakodowany JS) dla podatnych punktów końcowych.
   • Zastosuj surową politykę bezpieczeństwa treści (CSP), która zapobiega wykonywaniu skryptów inline (może być wymagane nonce/hash dla legalnych skryptów inline).
   • Ustaw nagłówki X‑Content‑Type‑Options: nosniff, X‑Frame‑Options: DENY oraz Referrer‑Policy.
   • Tymczasowo ogranicz dostęp do kreatorów stron i adresów URL podglądu poprzez białą listę IP lub uwierzytelnianie.
4. Skanuj swoje strony w poszukiwaniu wskaźników kompromitacji (IoCs)
   • Sprawdź logi dostępu pod kątem nietypowych ciągów zapytań lub parametrów GET.
   • Szukaj podejrzanych nowych użytkowników administratora lub nieoczekiwanych zmian w postach/stronach/szablonach.
   • Przeprowadź pełne skanowanie złośliwego oprogramowania (zarówno integralność plików, jak i skanowanie bazy danych).
5. Komunikuj i edukuj
   • Ostrzeż pracowników i klientów, aby nie klikali w nieznane linki, szczególnie te, które udają podglądy stron lub linki do kreatorów.
   • Natychmiast włącz uwierzytelnianie dwuskładnikowe (2FA) dla użytkowników administratora.
6. Kopia zapasowa
   • Wykonaj pełną kopię zapasową (pliki + baza danych) przed przystąpieniem do naprawy i zachowaj wiele zrzutów.

---

Praktyczne wskazówki dotyczące WAF / wirtualnego łatania

Jeśli używasz WP‑Firewall lub innej zapory aplikacji webowej, wirtualne łatanie jest najszybszym sposobem na złagodzenie eksploatacji, aż będziesz mógł zaktualizować motyw.

Przykładowe zasady łagodzenia, które warto rozważyć (koncepcyjne — dostosuj, aby uniknąć fałszywych pozytywów):

• Zablokuj żądania z niezakodowanymi wzorcami w ciągach zapytań lub nagłówkach:
  • Reject requests where QUERY_STRING or REQUEST_URI contains literal “<script” or “%3Cscript” (case‑insensitive).
• Zablokuj podejrzane atrybuty zdarzeń JavaScript w parametrach:
  • Odrzuć, gdy parametry zawierają wzorce “onerror=”, “onload=”, “onmouseover=”.
• Odrzuć próby wstrzykiwania adresów URL protokołu JS do parametrów:
  • Zablokuj wzorce “javascript:” lub “data:text/html” w ciągach zapytań.
• Ogranicz lub wyzwól podejrzane żądania POST/GET do punktów końcowych builder/preview:
  • Zwiększ kontrolę dla żądań, które zawierają tokeny podglądu buildera lub punkty końcowe buildera.
• Wyzwól lub CAPTCHA żądania wysokiego ryzyka:
  • Zastosuj CAPTCHA lub krok weryfikacji ludzkiej dla żądań pasujących do podejrzanych wzorców.

Ważny: Wiele prostych reguł filtrujących można obejść za pomocą sprytnego kodowania. Solidny WAF łączy dopasowywanie wzorców, wykrywanie anomalii i heurystykę. Kluczowe jest uważne monitorowanie fałszywych pozytywów, aby uniknąć łamania legalnej funkcjonalności, szczególnie w złożonych motywach buildera, które mogą legalnie przekazywać zakodowaną zawartość.

Użytkownicy WP‑Firewall powinni:

• Włączyć wstępnie zbudowany zestaw reguł łatki wirtualnej dla tego XSS w Bricks Builder (zapewniamy dostosowany zestaw reguł).
• Włączyć rejestrowanie żądań dla reguły i przeglądać zablokowane żądania.
• Jeśli reguła powoduje fałszywe pozytywy, użyj polityki etapowej: log → wyzwanie → blokada.

---

Rekomendacje dotyczące Content‑Security‑Policy (CSP)

CSP to potężne rozwiązanie, aby zmniejszyć wpływ XSS, szczególnie odzwierciedlonego XSS, gdzie atakujący polegają na skryptach inline lub wstrzykniętych skryptach zewnętrznych.

Rekomendacje dotyczące nagłówków bazowych:

• Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.example.com; object-src 'none'; base-uri 'self'; frame-ancestors 'none';
• X-Content-Type-Options: nosniff
• Referrer-Policy: brak-referrera-przy-obniżeniu (lub surowsze)
• X-Frame-Options: ZABRANIAJ
• Polityka uprawnień: geolokalizacja=(), mikrofon=(), kamera=()

Uwagi:

• Surowa CSP z brakiem dla script‑src i zabraniająca ‘unsafe‑inline’ złamie wiele motywów, które używają skryptów inline. Testuj na stagingu i dodawaj nonces/hashy dla legalnych skryptów inline w razie potrzeby.
• Dla podglądów buildera rozważ ograniczenie adresów URL podglądu do tych samych źródeł lub uwierzytelnionych sesji.

---

Jak wykrywać eksploatację (wskaźniki do obserwacji)

• Access logs show requests with long, unusual query strings, often with “<“, “%3C”, “javascript:”, or other encoded payload fragments.
• Odniesienia odpowiadające phishingowym e-mailom lub nieznanym domenom.
• Nagły wzrost odpowiedzi 200 dla URL-i, które zazwyczaj zwracają 404 lub przekierowują.
• Powiadomienia administracyjne: nowi użytkownicy administratora utworzeni, niespodziewane edycje wtyczek/tematów lub zmiany treści przez administratorów.
• Powiadomienia z twojego skanera złośliwego oprogramowania lub WAF dotyczące zablokowanych prób XSS.
• Błędy w konsoli przeglądarki dla użytkowników, którzy zgłaszają dziwne zachowanie po kliknięciu w link.

Uruchom te skany:

• Sprawdzenie integralności systemu plików (porównaj pliki motywu z oryginalnym pakietem).
• Szukaj niespodziewanych plików PHP lub webshelli w wp‑content/uploads, wp‑includes lub katalogach motywów/wtyczek.
• Sprawdzenie bazy danych pod kątem niespodziewanej wstrzykniętej treści w postach, widgetach lub opcjach.

---

Szybkie kontrole higieny kodu (dla programistów)

Przeszukaj kod swojego motywu pod kątem ryzykownych wzorców. Na maszynie deweloperskiej lub w środowisku staging, uruchom:

• Szukaj echo/print bez ucieczki:

  grep -R "echo .* \$_GET" wp-content/themes/bricks/
  

• Szukaj wyjścia pozbawionego funkcji ucieczki:
  • esc_html(), esc_attr(), esc_url(), wp_kses_post(), dezynfekuj_pole_tekstowe()
• Napraw, stosując odpowiednią ucieczkę w odpowiednim kontekście:
  • Używać esc_html() dla kontekstu ciała HTML.
  • Używać esc_attr() dla kontekstu atrybutu.
  • Używać esc_url_raw() / esc_url() dla adresów URL.
  • Dla dozwolonego bogatego HTML, użyj wp_kses() z bezpieczną dozwoloną listą.

Jeśli nie jesteś programistą lub nie jesteś pewien, nie próbuj edytować plików motywu na produkcji — współpracuj z programistą lub zastosuj wirtualne łatanie WAF zamiast tego.

---

Książka akcji w odpowiedzi na incydent (jeśli podejrzewasz kompromitację)

1. Izolować i zawierać
   • Włącz tryb konserwacji lub tymczasowo wyłącz dostęp publiczny.
   • Zmień hasła administratorów i unieważnij aktywne sesje (WordPress > Użytkownicy > Twój profil > Wyloguj się wszędzie).
   • Wymuś resetowanie haseł dla wszystkich administratorów i redaktorów.
2. Zachowaj dowody
   • Zrób forensyczny zrzut logów i systemów plików przed wprowadzeniem dużych zmian.
   • Eksportuj logi dostępu za odpowiedni okres czasu.
3. Oczyść i napraw
   • Zaktualizuj Bricks Builder do wersji 2.3 lub nowszej.
   • Usuń wszelkie złośliwe pliki lub tylne drzwi, które zostały zidentyfikowane.
   • Przywróć z czystej kopii zapasowej, jeśli kompromis jest rozległy.
4. Wzmocnienie i odzyskiwanie
   • Wydaj ponownie klucze API i zmień sekrety, które mogły zostać ujawnione.
   • Włącz 2FA dla wszystkich uprzywilejowanych kont.
   • Przeconfiguruj zasady WAF i włącz ciągłe monitorowanie.
5. Przegląd po incydencie
   • Zidentyfikuj przyczynę źródłową i zamknij luki.
   • Komunikuj się z interesariuszami i dokumentuj podjęte działania.

---

Lista kontrolna długoterminowego wzmacniania

• Utrzymuj aktualne jądro WordPress, motywy i wtyczki; subskrybuj alerty bezpieczeństwa.
• Ogranicz liczbę użytkowników administratorów i stosuj zasady minimalnych uprawnień.
• Wymuś 2FA dla wszystkich administratorów i użytkowników o wysokich uprawnieniach.
• Użyj zarządzanego WAF z wirtualnym łatającym i wykrywaniem anomalii.
• Zaplanuj regularne skanowanie złośliwego oprogramowania i kontrole integralności plików.
• Utrzymuj kopie zapasowe poza siedzibą z wersjonowaniem i okresowo testuj przywracanie.
• Zastosuj zasadę separacji: używaj dedykowanych subdomen administratorów lub VPN do wrażliwych operacji, gdy to możliwe.
• Wzmocnij konfiguracje PHP i serwera (wyłącz wykonywanie w przesyłkach, używaj bezpiecznych uprawnień do plików).
• Wprowadź nagłówki bezpieczeństwa (CSP, X-Frame-Options, X-Content-Type-Options).
• Audytuj integracje zewnętrzne (CDN, analityka, sieci reklamowe) i używaj Subresource Integrity (SRI) przy dołączaniu zewnętrznych skryptów.

---

Praktyczne polecenia i narzędzia

(Używaj ich w środowisku testowym lub ostrożnie w produkcji.)

• Sprawdź wersję motywu za pomocą WP‑CLI:

  wp theme get bricks --field=wersja

• Zaktualizuj motyw za pomocą WP‑CLI:

  aktualizacja motywu wp bricks

• Szukaj nieescapowanego wyjścia (przykład):

  grep -R --include="*.php" -nE "echo .*\\\$_(GET|POST|REQUEST|COOKIE)" wp-content/themes/bricks/

• Wypisz aktywne wtyczki i motywy:

  wp plugin list wp theme list

• Eksportuj ostatnie logi dostępu (przykład, na wielu hostach):

  tail -n 500 /var/log/apache2/access.log | grep "bricks" > recent_bricks_access.log

• Skanuj pod kątem wspólnych markerów webshell:

  grep -R --include="*.php" -nE "(eval|base64_decode|gzinflate|system|passthru|shell_exec)" wp-content/

---

Powszechne błędy i fałszywe poczucie bezpieczeństwa

• “Moja strona ma mały ruch, więc atakujący się nie zainteresują.” — Błędne. Atakujący używają zautomatyzowanych skanerów i masowych exploitów; strony o niskim ruchu są często celem zbiorowym.
• “Mam wtyczkę zabezpieczającą, więc jestem bezpieczny.” — Wtyczki zabezpieczające pomagają, ale jedynym niezawodnym rozwiązaniem dla podatnego motywu jest aktualizacja. WAF może złagodzić, ale nie jest trwałym substytutem łatania.
• “Po prostu usunę motyw.” — Wiele stron zależy od motywów budowlanych; ich usunięcie może zepsuć funkcjonalność. Zaktualizuj, przetestuj, a następnie usuń nieużywane motywy.

---

Jak WP‑Firewall pomaga (z perspektywy pragmatycznego inżyniera bezpieczeństwa)

Jako dostawca zapory WordPress, naszym celem jest skrócenie czasu między publicznym ujawnieniem a skuteczną ochroną. Oto jak pomagamy chronić strony przed odzwierciedlonymi lukami XSS, takimi jak CVE‑2026‑41554:

• Wirtualne łatanie: Nasze zarządzane zestawy reguł są wdrażane szybko i dostosowane do blokowania powszechnych wzorców exploitów dla tego odzwierciedlonego XSS Bricks Builder bez łamania legalnego ruchu budowniczego.
• Ciągłe monitorowanie: Rejestrujemy podejrzane żądania i wyświetlamy te zdarzenia na pulpicie, abyś mógł zobaczyć próby eksploatacji w czasie rzeczywistym.
• Granularne blokowanie i tryby wyzwań: Jeśli reguła niesie ryzyko fałszywych pozytywów, możemy umieścić ją w trybie wyzwania (CAPTCHA) przed pełnym blokowaniem; zmniejsza to zakłócenia w usłudze, jednocześnie chroniąc cię.
• Skanowanie zabezpieczeń: Regularne automatyczne skany wykrywają podejrzane zmiany i powszechne wskaźniki kompromitacji.
• Wsparcie incydentowe: Nasz zespół może zapewnić wskazówki dotyczące usuwania i priorytetowe wsparcie w celu zidentyfikowania i usunięcia wszelkich infekcji.

Jeśli zarządzasz wieloma witrynami, centralne zarządzanie z dostosowaniem reguł dla każdej witryny znacznie redukuje koszty operacyjne w przypadku ujawnienia podatności.

---

Testowanie i walidacja (zrób to po aktualizacji)

• Potwierdź, że wersja motywu 2.3+ jest aktywna.
  • W panelu administracyjnym WordPress: Wygląd → Motywy → Wersja Bricks Builder
  • Lub za pomocą WP‑CLI: wp theme get bricks --field=wersja
• Wyczyść pamięci podręczne (cache serwera, CDN).
• Powtórz legalne przepływy pracy (edytuj strony, publikuj treści, użyj podglądu kreatora), aby upewnić się, że aktualizacja nie zepsuła funkcjonalności.
• Ponownie uruchom skaner podatności lub logi WAF, aby upewnić się, że próby wykorzystania nie wywołują już tego samego zachowania odpowiedzi.

---

Kiedy skontaktować się z profesjonalną pomocą

Jeśli wykryjesz oznaki trwającego wykorzystania, takie jak nowo utworzone konta administratorów, nieznane pliki lub uporczywe przekierowania/spam SEO, skontaktuj się z profesjonalistą ds. bezpieczeństwa. Natychmiastowe kroki obejmują izolację witryny, zachowanie logów oraz koordynację pełnego procesu czyszczenia i wzmocnienia zabezpieczeń. Jeśli masz wiele witryn klientów, rozważ usługi zarządzane, które zapewniają zarówno proaktywne zabezpieczenia, jak i szybkie reagowanie na incydenty.

---

Nowy sposób na uzyskanie natychmiastowej ochrony: Bezpłatny zarządzany WAF dla witryn WordPress

Uzyskaj natychmiastową bezpłatną ochronę zarządzanego WAF (plan podstawowy), aby chronić swoją witrynę WordPress podczas aktualizacji podatnych motywów i wtyczek. Plan podstawowy (bezpłatny) obejmuje podstawowe zabezpieczenia, takie jak zarządzany zapora, nielimitowana przepustowość, zapora aplikacji internetowej (WAF) z wirtualnym łatającym dla znanych CVE, skaner złośliwego oprogramowania oraz łagodzenie ryzyk OWASP Top 10.

Zarejestruj się w WP‑Firewall Basic (bezpłatny) tutaj

Dlaczego warto rozważyć bezpłatny plan podczas aktualizacji:

• Otrzymujesz natychmiastowe wirtualne łaty wdrożone, aby zatrzymać próby wykorzystania podatności na odzwierciedlone XSS.
• Nielimitowana przepustowość i ochrona WAF dla witryn startowych i o niskim ruchu.
• Łatwa ścieżka do aktualizacji do automatycznego usuwania złośliwego oprogramowania oraz czarnej/białej listy IP, jeśli potrzebujesz bardziej zaawansowanych kontroli.

(Jeśli zarządzasz witrynami dla klientów, późniejsze przejście na plan Standard lub Pro dodaje automatyczne usuwanie złośliwego oprogramowania, kontrolę IP, miesięczne raportowanie i zaawansowane usługi naprawcze.)

---

Podsumowanie i ostateczne zalecenia

• Natychmiast zaktualizuj Bricks Builder do wersji 2.3 lub nowszej na wszystkich dotkniętych stronach — to jest ostateczne rozwiązanie.
• Jeśli nie możesz zaktualizować od razu, wdroż wirtualne łatanie za pomocą zarządzanego WAF, włącz surową CSP i ogranicz dostęp do funkcji budowania/podglądu.
• Przeprowadź skanowanie i kontrole forensyczne, aby wykryć jakiekolwiek oznaki kompromitacji.
• Zastosuj ogólne wzmocnienie: 2FA, minimalne uprawnienia, rutynowe kopie zapasowe i kontrole integralności plików.
• Użyj scentralizowanego zarządzania bezpieczeństwem, jeśli zarządzasz wieloma stronami, aby skrócić czas reakcji na przyszłe ujawnienia.

Odbite XSS jest zarówno stare, jak i niebezpieczne, ponieważ łatwo je wykorzystać na dużą skalę. Priorytetowo traktuj łatanie, stosuj wirtualne łaty tam, gdzie to konieczne, i kontynuuj monitorowanie. Jeśli potrzebujesz pomocy w implementacji zasad WAF, weryfikacji czystego stanu lub wzmocnienia swoich instalacji, nasi inżynierowie ds. bezpieczeństwa są gotowi do pomocy.

Bądź bezpieczny i traktuj wszelkie nieautoryzowane ujawnienia XSS jako pilny element do naprawy.

— Zespół ds. bezpieczeństwa WP‑Firewall