Nazwa wtyczki	Twórca leja sprzedażowego od FunnelKit
Rodzaj podatności	Atak typu cross-site scripting (XSS)
Numer CVE	CVE-2025-12878
Pilność	Niski
Data publikacji CVE	2026-02-01
Adres URL źródła	CVE-2025-12878

Pilne: Przechowywane XSS w Funnel Builder (FunnelKit) <= 3.13.1.2 — Co właściciele WordPressa muszą wiedzieć i jak WP‑Firewall cię chroni

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

Streszczenie

Publicznie ujawniono lukę w zabezpieczeniach typu cross-site scripting (XSS) wtyczki Funnel Builder (FunnelKit) w wersjach <= 3.13.1.2 w dniu 2 lutego 2026 roku (CVE‑2025‑12878). Luka ta pozwala uwierzytelnionemu użytkownikowi z uprawnieniami Współtwórcy na przechowywanie JavaScriptu wewnątrz wfop_phone parametru shortcode, który następnie wykonuje się w przeglądarkach odwiedzających, gdy dotknięty shortcode jest renderowany. Dostawca wydał poprawkę w wersji 3.13.1.3.

Ten post wyjaśnia, w praktycznych terminach:

• czym jest luka i dlaczego ma znaczenie;
• kto jest narażony i realistyczne scenariusze ataków;
• jak potwierdzić, czy twoja strona jest dotknięta, używając wyszukiwań WordPress/WP‑CLI/SQL;
• natychmiastowe środki zaradcze i długoterminowe wzmocnienie bezpieczeństwa;
• jak WP‑Firewall chroni twoją stronę zarówno teraz (wirtualne łatanie/WAF), jak i w przyszłości.

Niniejsze wytyczne są napisane z perspektywy zespołu bezpieczeństwa WP‑Firewall i zakładają, że chcesz praktycznych kroków, które możesz zastosować już dziś (najpierw staging, zawsze).

---

Co się stało — szybkie fakty

• Dotknięta wtyczka: Funnel Builder od FunnelKit (wtyczka WordPress).
• Wrażliwe wersje: <= 3.13.1.2
• Naprawione w: 3.13.1.3
• Typ podatności: Przechowywane skrypty międzywitrynowe (XSS)
• CVE: CVE‑2025‑12878
• Wymagane uprawnienia do wykorzystania: Współpracownik
• CVSS: 6.5 (średni)
• Wykorzystanie wymaga interakcji użytkownika (odwiedzenia strony, która renderuje ładunek), ale ładunek jest przechowywany po stronie serwera (więc utrzymuje się i może wpływać na wielu użytkowników).

---

Dlaczego przechowywane XSS jest niebezpieczne (przypomnienie)

Przechowywane XSS występuje, gdy atakujący może wstrzyknąć JavaScript (lub HTML z obsługą skryptów), który jest przechowywany na serwerze (w postach, meta, ustawieniach wtyczki itp.) i jest później serwowany innym użytkownikom bez odpowiedniej sanitizacji lub ucieczki. Konsekwencje obejmują:

• Kradzież sesji i przejęcie konta (kradzież ciasteczek, tokenów sesji);
• Eskalacja uprawnień, jeśli administratorzy przeglądają lub edytują dotkniętą treść;
• Dostarczanie ładunków drugiego etapu (złośliwe oprogramowanie, skrypty do kopania kryptowalut, formularze phishingowe);
• Zmiana wyglądu lub wstrzykiwanie treści, które podważają zaufanie i SEO;
• Trwałe tylne drzwi poprzez złośliwe ustawienia administratora wstrzyknięte przez początkowe XSS.

Chociaż Contributor ma stosunkowo niskie uprawnienia, przechowywane XSS zwiększa ryzyko: atakujący z kontem Contributor może tworzyć treści zawierające ładunek, który później uruchomi się w przeglądarce każdego użytkownika — w tym administratorów — którzy przeglądają dotknięte strony frontendowe lub administracyjne renderujące shortcode.

---

Przegląd techniczny (co się dzieje)

Luka wynika z niewystarczającej sanitacji/ucieczki danych wejściowych przekazywanych przez wfop_phone parametr shortcode. Użytkownik Contributor (który normalnie nie może publikować, ale może dodawać treści, które mogą być zapisane w formularzach wtyczek, szkicach lub innych zarządzanych przez wtyczki podmiotach) może umieścić ładunki HTML/JS w tym parametrze. Gdy wtyczka później renderuje shortcode na stronie, te ładunki są wyjściowe bez ucieczki, co pozwala przeglądarce na ich wykonanie.

Przykład (sanitizowany dla bezpieczeństwa):

• Złośliwy ładunek jako przechowywane dane wejściowe (wyświetlane z ucieczką): <script>/* złośliwy JS */</script>
• Gdy shortcode jest renderowane bez ucieczki, skrypt działa w kontekście przeglądarki odwiedzającego.

Ponieważ jest to przechowywane (a nie odzwierciedlone), wstrzyknięty kod utrzymuje się, aż zostanie usunięty, i może wpływać na wielu odwiedzających lub nawet administratorów witryny, którzy otwierają treść w swoich przeglądarkach.

---

Realistyczne scenariusze ataków

1. Atakujący rejestruje (lub kompromituje) konto Contributor — wiele witryn pozwala na rejestrację lub ma słabe kontrole wprowadzania.
2. Atakujący tworzy treść lub aktualizuje ustawienie Funnel/element/formularz, gdzie wfop_phone jest przechowywane z ładunkiem skryptu.
3. Witryna później publikuje funnel/formularz lub administrator go podgląda, co powoduje wykonanie ładunku w kontekście zalogowanych użytkowników (w tym administratorów) lub gości.
4. Skrypt atakującego wykonuje działania takie jak:
   • Kradzież ciasteczek/tokenów sesji (prowadząca do przejęcia konta).
   • Utworzenie nowego użytkownika administratora za pośrednictwem dowolnych dostępnych punktów końcowych dostępnych w JS.
   • Wstrzyknij tylne drzwi lub przekieruj odwiedzających na strony phishingowe/złośliwe oprogramowanie.
   • Zmodyfikuj ustawienia wtyczki/motywu, osadź stronę spamową SEO itp.

Nawet jeśli strona wymaga publikacji przez administratora, Contributor czasami może stworzyć treść, którą administrator zobaczy w podglądzie — a podglądy mogą wykonywać skrypty w przeglądarce administratora.

---

Jak sprawdzić, czy Twoja witryna jest dotknięta

Po pierwsze — zawsze testuj na wersji stagingowej lub offline swojej strony. Nie uruchamiaj niebezpiecznych ładunków na produkcji.

1. Potwierdź wersję wtyczki
   • Przejdź do WordPress Admin → Wtyczki i sprawdź wersję Funnel Builder / FunnelKit.
   • Jeśli nie możesz uzyskać dostępu do panelu administracyjnego, sprawdź wp-content/plugins/funnel-builder nagłówki wtyczek w plikach wtyczek; sprawdź readme.txt Lub funnel-builder.php.
2. Jeśli masz dostęp SSH, użyj WP‑CLI:
   • Wyświetl zainstalowaną wersję:

     wp plugin get funnel-builder --field=wersja

   • Zaktualizuj wtyczkę (zobacz późniejszą sekcję), jeśli jest podatna.
3. Przeszukaj swoją bazę danych pod kątem wfop_phone wystąpienia
   Używając phpMyAdmin, Adminer lub klienta MySQL, uruchom (dostosuj prefiks tabeli, jeśli nie wp_):

   SELECT ID, post_title, post_status;

   Wyszukaj postmeta:

   SELECT post_id, meta_key, meta_value;

   Opcje wyszukiwania i inne tabele:

   SELECT option_name, option_value;

4. Użyj WP‑CLI, aby wyszukać posty i opcje:
   • Posty:

     wp post list --post_type='any' --format=ids | xargs -I % wp post get % --field=post_content --raw | grep -n "wfop_phone"

   • Wartości opcji wyszukiwania (uważaj na duże bazy danych):

     wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%wfop_phone%';"

5. Skanuj za pomocą skanera bezpieczeństwa (WP‑Firewall, skanery złośliwego oprogramowania lub niestandardowe skrypty) — szukaj wystąpień <script Lub JavaScript: w dowolnej treści lub danych wtyczek.
6. Audytuj użytkowników z rolą Współtwórcy: szukaj ostatnich rejestracji, podejrzanych nazw użytkowników lub nagłej aktywności.

---

Natychmiastowe działania łagodzące (co zrobić teraz — priorytetowo)

Jeśli Twoja strona korzysta z podatnej wersji FunnelKit lub znajdziesz podejrzane wfop_phone wystąpienia, postępuj zgodnie z tą priorytetową listą. Zawsze pracuj w środowisku testowym przed wprowadzeniem zmian na produkcji, jeśli to możliwe.

1. Zaktualizuj wtyczkę (najlepsza poprawka)
   • Zaktualizuj Funnel Builder do 3.13.1.3 lub nowszej wersji natychmiast przez panel administracyjny WordPress lub WP‑CLI:

     wp plugin update funnel-builder

   • Jeśli automatyczna aktualizacja nie jest dostępna, pobierz poprawioną wtyczkę z oficjalnego repozytorium wtyczek i zainstaluj.
2. Tymczasowo wyłącz wtyczkę
   • Jeśli nie możesz zaktualizować natychmiast, tymczasowo dezaktywuj Funnel Builder (admin → wtyczki), aby zapobiec renderowaniu shortcode i zatrzymać wykonywanie skryptów.
3. Usuń lub zneutralizuj dotknięte shortcode'y
   • Zastąp wystąpienia [wfop_phone ...] użycie w postach/stronach z bezpiecznym miejscem do zastąpienia, aż do naprawienia.
   • Uruchom aktualizacje bazy danych, aby usunąć podejrzane atrybuty:

     UPDATE wp_posts;

   • Wykonaj kopię zapasową swojej bazy danych przed uruchomieniem jakichkolwiek masowych aktualizacji.
4. Oczyść przechowywaną treść
   • Szukaj <script i inne obsługiwacze zdarzeń w treści postów oraz metadanych wtyczek i usuń je:

     WYBIERZ ID, tytuł_postu Z wp_posts GDZIE post_content LUBIĘ '%

5. Ogranicz uprawnienia współpracowników (tymczasowo)
   • Zmień role członków; ogranicz możliwość tworzenia lub edytowania formularzy/lejek dla współpracowników, dopóki strona nie zostanie naprawiona.
   • Rozważ tymczasowe wyłączenie rejestracji na froncie lub wymaganie zatwierdzenia przez administratora dla nowych użytkowników.
6. Skanuj w poszukiwaniu wskaźników kompromitacji
   • Szukaj nowych kont administratorów, zmodyfikowanych plików wtyczek/motywów, nieznanych zadań zaplanowanych (cron) lub plików dodanych do uploads.
   • Sprawdź logi serwera pod kątem nietypowych żądań POST lub wpisów w czasie, gdy złośliwy ładunek mógł być przechowywany.
7. Obracanie sekretów
   • Po potwierdzeniu czystego stanu, zmień sól, klucze API i wszelkie dane uwierzytelniające, które mogły zostać ujawnione.
8. Przywróć z kopii zapasowej, jeśli znajdziesz trwałe tylne drzwi
   • Jeśli czyszczenie jest niekompletne lub wykryjesz głębsze naruszenie, przywróć z czystej kopii zapasowej i zastosuj wszystkie łatki zabezpieczeń.

---

Ochrony WP‑Firewall — jak pomagamy

Jako zapora ogniowa WordPress i dostawca zabezpieczeń, WP‑Firewall ma wiele warstw, aby chronić strony przed tą klasą podatności, nawet przed zastosowaniem aktualizacji wtyczek:

1. Wirtualne łatanie (reguła WAF)
   • Wdrażamy wirtualne łatki (zasady WAF), które przechwytują żądania próbujące przechować znane wzorce exploitów w wfop_phone lub innych wejściach FunnelKit.
   • Przykład wzorca sygnatury WAF, którego używamy (koncepcyjny; rzeczywista zasada używa wzmocnionego regex i kontroli kontekstu):
   • Blokuj HTTP POSTy/PUTy zawierające wfop_phone wartości parametrów, które zawierają:
     • <script lub zakodowane warianty (skrypt)
     • onerror=, ładowanie=, JavaScript:, dokument.cookie, Lub oceniać(
   • Koncepcyjny regex do wykrywania tagów skryptów lub obsługiwaczy zdarzeń w wartościach parametrów:

     (?i)(<\s*skrypt\b|\s*skrypt|javascript:|on\w+\s*=|document\.cookie|eval\()

   • Dostosowujemy zasady, aby unikać fałszywych pozytywów (np. numery telefonów zawierających na podciągi) poprzez sprawdzanie kontekstu i nazw parametrów.
2. Filtrowanie odpowiedzi
   • WP‑Firewall może opcjonalnie sanitizować wychodzące odpowiedzi HTML, aby usunąć tagi inline <script> wstawione za pomocą shortcode'ów, zanim dotrą do klientów. To jest druga linia obrony i należy jej używać ostrożnie, aby nie złamać funkcjonalności.
3. Ograniczanie liczby żądań i kontrole rejestracji
   • Blokuj lub ograniczaj automatyczne rejestracje i podejrzane procesy tworzenia kont współtwórców, aby zmniejszyć możliwości atakujących.
4. Skanowanie plików i integralności
   • Skanujemy nowo dodane pliki, zmodyfikowane pliki wtyczek/motywów oraz podejrzane zmiany, które często towarzyszą działaniom po wykorzystaniu.
5. Monitorowanie aktywności i powiadomienia
   • Powiadomienia o podejrzanych podglądach administratorów, zmianach treści zawierających ładunki przypominające skrypty oraz aktywności kont współtwórców są dostępne dla administratorów.
6. Wsparcie po incydencie
   • Jeśli wykryjesz kompromitację, wsparcie WP‑Firewall może pomóc usunąć złośliwy kod, przywrócić bezpieczne stany i zalecić kroki wzmacniające.

Uwaga: wirtualne łatanie to tymczasowe działanie awaryjne i nigdy nie powinno być stałym substytutem stosowania poprawek dostawcy. Zawsze aktualizuj do poprawionej wersji wtyczki, gdy jest dostępna.

---

Zalecane zasady WAF (techniczne, dla zespołów bezpieczeństwa)

Poniżej znajdują się sugerowane zasady wykrywania, które możesz wdrożyć w WAF. Są one ilustracyjne — testuj zasady w środowisku staging i unikaj zbyt szerokich wzorców, aby zmniejszyć fałszywe pozytywy.

1. Blokuj żądania POST, w których nazwa parametru zawiera wfop_phone a wartość zawiera <script lub zakodowany tag skryptu:
   Warunek: Metoda HTTP to POST/PUT
   Parametr: body (dane formularza) lub ładunek JSON
   Wzorzec:

   (?i)(wfop_phone).*?(\s*skrypt|<\s*skrypt|javascript:|on\w+\s*=|document\.cookie|eval\(|window\.location)

2. Zablokuj żądania za pomocą wfop_phone wartość parametru zawierająca podejrzane atrybuty zdarzeń JS:
   Wzorzec:

   (?i)wfop_phone=.*(onerror|onload|onclick|onsubmit|onfocus)=

3. Oczyść renderowaną zawartość (inspekcja odpowiedzi)
   Sprawdź wyjściowy HTML pod kątem <script osadzonego pod wfop_phone-związanym markupem; usuń lub zakoduj przed odpowiedzią.
4. Monitorowanie i ostrzeganie
   Jeśli jakiekolwiek żądanie pasuje do reguły, zarejestruj pełne żądanie z znacznikiem czasu, IP, agentem użytkownika i przechwyconymi wartościami parametrów (przechowuj logi w bezpieczny sposób) i wyślij powiadomienie do administratorów.

Ważny: Reguły WAF są potężne, ale wymagają dostrojenia do Twojej witryny. Testuj dokładnie, ponieważ pola telefoniczne czasami zawierają legalnie znaki, które mogą zmylić naiwne reguły (np. znaki plusa, nawiasy lub zlokalizowane formaty liczb).

---

Lista kontrolna reakcji na incydenty (krok po kroku)

Jeśli znajdziesz dowody na wykorzystanie, użyj tej uporządkowanej listy kontrolnej:

1. Zawierać
   • Dezaktywuj podatny plugin lub zastosuj łatkę dostawcy.
   • Aktywuj zasady ochrony WP‑Firewall i zwiększ logging/powiadomienia.
   • Tymczasowo wyłącz publiczną rejestrację użytkowników, jeśli jest nadużywana.
2. Zbadać
   • Zidentyfikuj, kiedy złośliwa zawartość została przechowana (znacznik czasu).
   • Zidentyfikuj konto(y) Współtwórcy, które przechowały ładunek.
   • Szukaj innych instancji wfop_phone i innych podejrzanych shortcode'ów.
   • Przejrzyj logi serwera i dostępu pod kątem IP atakujących i wzorców żądań.
3. Wytępić
   • Usuń złośliwą zawartość z bazy danych (posty, postmeta, opcje).
   • Usuń wszelkie złośliwe pliki lub nieautoryzowanych użytkowników administratora.
   • Wyczyść zaplanowane zadania (wp_cron hooks) utworzone przez napastnika.
4. Odzyskiwać
   • Zmień wszystkie poświadczenia, które mogły zostać ujawnione.
   • Ponownie zastosuj poprawki zabezpieczeń i potwierdź, że wtyczka jest zaktualizowana do wersji 3.13.1.3 lub nowszej.
   • Przywróć z czystej kopii zapasowej, jeśli integralność nie może być zagwarantowana.
5. Wyciągnięte wnioski
   • Sprawdź, dlaczego konto Współpracownika istniało i czy surowsze zasady wprowadzania lub moderacji treści mogą zmniejszyć ryzyko.
   • Wprowadź wzmocnienie po incydencie: 2FA, minimalne uprawnienia dla ról, przegląd automatycznych procesów publikacji.
6. Notyfikować
   • Jeśli wrażliwe dane użytkowników lub konta zostały naruszone, stosuj odpowiednie zasady powiadamiania o naruszeniach i informuj dotkniętych użytkowników.

---

Rekomendacje dotyczące wzmocnienia zapobiegawczego

1. Zasada najmniejszych uprawnień
   • Przejrzyj role i uprawnienia. Współpracownicy powinni mieć tylko to, czego potrzebują. Ogranicz dostęp do stron administracyjnych wtyczek.
2. Wymagaj moderacji i przeglądu przez administratorów
   • Upewnij się, że zgłoszenia współpracowników są przeglądane przez redaktorów/administratorów przed publikacją. Unikaj automatycznego renderowania szkiców redaktora dla administratorów bez sanitizacji.
3. Użyj walidacji i sanitizacji danych wejściowych
   • Wtyczki, które akceptują treści użytkowników, muszą sanitizować dane wejściowe przy użyciu standardowych funkcji WP:
     • Używać wp_kses() do białej listy HTML.
     • Ucieczka wyjścia z esc_html(), esc_attr(), Lub wp_kses_post() w miarę odpowiednio.
4. Utrzymuj zaktualizowane rdzenie WordPressa, motywy i wtyczki.
   • Stosuj poprawki zabezpieczeń niezwłocznie i utrzymuj proces stagingowy do testowania.
5. Wymuszanie silnego uwierzytelniania
   • Użyj 2FA dla kont administratorów/redaktorów i włącz silne zasady dotyczące haseł.
6. Ogranicz bezpośrednie edytowanie plików i wyłącz PHP exec tam, gdzie to możliwe
   • Zapobiegaj edytorom plików w panelu, aby utrudnić napastnikom utrzymanie tylnej furtki po stronie serwera.
7. Ciągłe monitorowanie
   • Monitorowanie integralności plików, zaplanowane skanowanie złośliwego oprogramowania i ochrona WAF w czasie rzeczywistym zmniejszają czas przebywania napastników.

---

Przykładowe zapytania i skrypty (dla administratorów witryny)

• Znajdź posty zawierające shortcode:

  SELECT ID, post_title, post_status;

• Znajdź postmeta z podejrzanym skryptem:

  WYBIERZ post_id, meta_key;

• WP‑CLI wyszukiwanie podejrzanych ciągów:

  wp search-replace '<script' '' --all-tables --dry-run

  Używać --dry-run najpierw, a następnie usuń go, aby wykonać zamianę po weryfikacji wyników.

---

Najlepsze praktyki dla wydawców wtyczek i twórców witryn

Jeśli tworzysz leje sprzedażowe, formularze lub pozwalasz na wkłady od użytkowników o niższych uprawnieniach, przestrzegaj tych obowiązków:

• Zawsze escape'uj dane wyjściowe. Nigdy nie polegaj na roli użytkownika, aby uczynić nieescape'owane dane wyjściowe bezpiecznymi.
• Używaj sanitizacji po stronie serwera, a nie tylko po stronie klienta.
• Waliduj numery telefonów ściśle (tylko cyfry, znak plus, spacje, myślniki).
• Unikaj wstrzykiwania surowych treści użytkownika do atrybutów HTML w linii bez odpowiedniego kodowania.
• Wdrażaj bezpieczny mechanizm podglądu, który neutralizuje skrypty podczas podglądu administratora.

---

Praktyczny przykład: bezpieczne przetwarzanie pola telefonu w kodzie

Jeśli jesteś deweloperem aktualizującym kod wtyczki lub motywu, upewnij się, że pola telefoniczne są sanitizowane/escape'owane. Przykład (koncepcyjny PHP):

// Podczas zapisywania danych wejściowych telefonu:

Nigdy nie wyświetlaj surowych wartości bezpośrednio w atrybutach HTML lub treści.

---

Zarejestruj się w WP‑Firewall Basic — chroń swoją witrynę już dziś

Tytuł: Zacznij chronić swoją witrynę WordPress za darmo z WP‑Firewall Basic

Jeśli chcesz szybkiego, bezproblemowego sposobu na dodanie warstwy ochronnej podczas łatania lub badania, plan podstawowy WP‑Firewall (darmowy) zapewnia podstawową ochronę dla witryn WordPress. Plan podstawowy obejmuje zarządzany zaporę, zasady WAF, nielimitowaną przepustowość, skaner złośliwego oprogramowania oraz łagodzenie ryzyk OWASP Top 10 — pomagając zatrzymać znane wzorce exploitów, takie jak FunnelKit. wfop_phone XSS, zanim dotrą do przeglądarek odwiedzających. Dla właścicieli witryn, którzy potrzebują więcej automatyzacji i głębszej naprawy, nasze płatne plany dodają automatyczne usuwanie złośliwego oprogramowania, czarną/białą listę IP, automatyczne wirtualne łatanie luk oraz zaawansowane usługi naprawcze. Zarejestruj się w darmowym planie WP‑Firewall i dodaj awaryjną warstwę obronną do swojej witryny tutaj: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Długoterminowe monitorowanie i zapewnienie.

Po łatanie i oczyszczeniu, kontynuuj monitorowanie:

• Cotygodniowe skanowanie złośliwego oprogramowania i kontrole integralności plików.
• Powiadomienia o nowych instalacjach lub zmianach wtyczek.
• Okresowe wyszukiwania shortcode'ów i podejrzanych wzorców.
• Regularnie przeglądaj konta użytkowników, szczególnie współpracowników.

Rozważ stopniowe wprowadzanie automatycznych aktualizacji wtyczek oraz proces szybkiego stosowania awaryjnych łatek w całej witrynie.

---

Ostatnie przemyślenia zespołu WP‑Firewall

Przechowywane luki XSS w powszechnie używanych wtyczkach stanowią znaczące ryzyko, ponieważ mogą przekształcić konta o niskich uprawnieniach w potężne wektory ataku. Problem FunnelKit wfop_phone jest wyraźnym przykładem: jedno niesanitizowane pole może mieć ogromne konsekwencje.

Bezpieczna, poprawna odpowiedź jest warstwowa:

1. Łatka u źródła — zaktualizuj FunnelKit do wersji 3.13.1.3 lub nowszej.
2. Ogranicz i oczyść — wyłącz lub zdezynfekuj dotknięte treści, przeglądaj konta.
3. Chroń z przodu — użyj warstwy WAF/wirtualnego łatania (takiej jak WP‑Firewall), aby blokować próby exploitów i monitorować podejrzaną aktywność.
4. Wzmocnij procesy — ogranicz role, wymagaj moderacji i utrzymuj szybki proces aktualizacji.

Jesteśmy dostępni, aby pomóc administratorom WP szybko wdrożyć awaryjne zasady WAF, skanować podejrzane treści i przywrócić czyste działanie. Jeśli jeszcze nie korzystasz z WP‑Firewall, nasz plan podstawowy (darmowy) zapewnia natychmiastową ochronę zapory i skanowania złośliwego oprogramowania podczas stosowania poprawek dostawcy. Rozpocznij: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Bądź czujny — tego rodzaju luki są dość powszechne, a warstwowe zabezpieczenia oraz szybkie łatanie znacznie zmniejszają ryzyko.

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