Łagodzenie XSS w wtyczce Alfie WordPress//Opublikowano 2026-03-23//CVE-2026-4069

Nazwa wtyczki	Alfie
Rodzaj podatności	Atak typu cross-site scripting (XSS)
Numer CVE	CVE-2026-4069
Pilność	Wysoki
Data publikacji CVE	2026-03-23
Adres URL źródła	CVE-2026-4069

TL;DR — Dlaczego powinieneś to przeczytać teraz

Wtyczka Alfie (Feed) WordPress (wersje <= 1.2.1) ma przypisaną podatność na przechowywane skrypty międzywitrynowe (XSS) związaną z parametrem "naam". Podatność można połączyć z żądaniem w stylu CSRF, aby spowodować, że skrypt zostanie zapisany i później wykonany w przeglądarce administratora lub innego użytkownika z uprawnieniami. Jeśli używasz Alfie na jakiejkolwiek stronie, szczególnie na stronach, które akceptują marketing lub dostęp osób trzecich do panelu WordPress, natychmiast przeczytaj i postępuj zgodnie z poniższymi krokami ograniczającymi i naprawczymi.

Ten post jest napisany z perspektywy WP-Firewall — profesjonalnego zespołu WAF i operacji bezpieczeństwa WordPress — i daje pragmatyczne, wykonalne wskazówki dla właścicieli stron, deweloperów i zespołów hostingowych.

---

Streszczenie wykonawcze podatności

• Dotknięte oprogramowanie: wtyczka Alfie (Feed) WordPress
• Wersje podatne: <= 1.2.1
• Typ podatności: Skrypty międzywitrynowe (przechowywane XSS), wyzwalane przez nazwa parametr i wykorzystywane przez wektor fałszywego żądania międzywitrynowego (CSRF)
• CVE: CVE-2026-4069
• Zgłoszona powaga (techniczna): CVSS 7.1 (uwaga: wykorzystanie wymaga interakcji użytkownika w wielu rzeczywistych scenariuszach)
• Skutek: Kradzież danych sesji administratora, trwałe wykonywanie JS w widokach administratora, przejęcie konta, nieautoryzowane działania administratora za pośrednictwem przeglądarki ofiary

---

Jak działa atak — techniczny przepływ w prostym języku

1. Wtyczka Alfie udostępnia punkt końcowy lub obsługę ustawień, która akceptuje nazwa parametr (np. w żądaniu POST lub GET) i zapisuje dostarczoną wartość w miejscu, które później będzie wyświetlane w kontekście administracyjnym (tabela opcji, niestandardowe meta posty lub niestandardowy widżet pulpitu).
2. Ta obsługa nie wystarczająco waliduje, nie oczyszcza ani nie ucieka od nazwa wartości przed jej zapisaniem.
3. Atakujący tworzy dane wejściowe, które zawierają złośliwy ładunek skryptu (na przykład JavaScript, który wykonuje żądania w tle lub wykrada ciasteczka/lokalne przechowywanie).
4. Atakujący hostuje lub osadza sztuczkę CSRF (link, źródło obrazu lub ukryty formularz), która powoduje, że administrator lub inny użytkownik z uprawnieniami wysyła skonstruowane żądanie (lub odwiedza stronę, która powoduje to żądanie).
5. Ponieważ nazwa wartość została przechowana bez odpowiedniej sanitizacji, złośliwy JavaScript jest później renderowany i wykonywany w kontekście przeglądarki każdego użytkownika przeglądającego strony administracyjne wtyczki — dając atakującemu te same uprawnienia co ten użytkownik w kontekście sesji przeglądarki.

Ważne niuanse:

• Opublikowane badania i ujawnienia wskazują, że wykorzystanie wymaga interakcji użytkownika (np. kliknięcia w link lub odwiedzenia złośliwej strony, która wyzwala przechowywany input). To zmniejsza prawdopodobieństwo całkowicie zautomatyzowanego masowego kompromitowania, ale ukierunkowane lub szerokie kampanie phishingowe mogą nadal być skuteczne.
• Przechowywane XSS w kontekstach administracyjnych jest szczególnie niebezpieczne. Udany ładunek wykonany przez administratora może tworzyć nowych użytkowników administracyjnych, zmieniać adresy e-mail, eksportować dane uwierzytelniające lub instalować tylne drzwi.

---

Ocena ryzyka: co ta podatność oznacza dla twojej strony

• Scenariusze o wysokim wpływie:
  • Atakujący przekonuje administratora do kliknięcia w link lub odwiedzenia strony, która wyzwala podatne żądanie. Gdy skrypt działa w przeglądarce administratora, atakujący może wykonywać dowolne działania administracyjne (tworzyć użytkowników, modyfikować ustawienia, przesyłać złośliwy kod).
  • Przechowywane XSS może być używane do wstrzykiwania trwałych tylnych drzwi lub adresów URL powłok sieciowych do konfiguracji strony, umożliwiając długoterminowy dostęp.
• Scenariusze o średnim / niższym wpływie:
  • Jeśli przechowywana treść jest wyświetlana tylko użytkownikom o niskich uprawnieniach, natychmiastowe szkody mogą być ograniczone do zniekształcenia lub kradzieży po stronie klienta (ciasteczka, tokeny).
• Czynniki łagodzące:
  • Wymóg interakcji użytkownika utrudnia zautomatyzowane masowe wykorzystanie.
  • Jeśli twoja strona korzysta z silnych kontroli dostępu administracyjnego (2FA, ograniczenia IP do obszaru administracyjnego, surowa polityka bezpieczeństwa treści), okno na wykorzystanie się zawęża.

Nawet jeśli twoja strona wydaje się mała lub o niskim ruchu, atakujący rutynowo celują w instalacje WordPressa wszelkich rozmiarów, ponieważ każdy przyczółek można zmonetyzować.

---

Natychmiastowe kroki dla właścicieli stron (ograniczenie — zrób to teraz)

1. Zidentyfikuj, czy Alfie jest zainstalowane i sprawdź wersję:
   • W panelu WordPressa przejdź do Wtyczki → Zainstalowane wtyczki i poszukaj "Alfie" lub "Alfie — Feed".
   • Jeśli zarządzasz wieloma stronami, przeszukaj listy wtyczek w całej flocie lub użyj WP-CLI: wp plugin list --format=csv | grep -i alfie
2. Jeśli jesteś na podatnej wersji (<= 1.2.1):
   • Tymczasowo natychmiast dezaktywuj wtyczkę.
   • Jeśli dezaktywacja nie jest możliwa (łamanie funkcjonalności), ogranicz dostęp do obszaru administracyjnego (patrz krok 4) i przejdź do kroku 3.
3. Zaktualizuj, gdy zostanie wydana oficjalna łatka:
   • Jeśli dostawca wtyczki wyda poprawioną wersję, zaktualizuj, gdy tylko potwierdzisz zgodność w środowisku testowym.
   • Jeśli żadna oficjalna łatka nie jest jeszcze dostępna, przejdź do kontroli retencji (WAF/wirtualne łatanie) oraz krótkoterminowego usunięcia lub zastąpienia wtyczki.
4. Zmniejsz narażenie administracyjne:
   • Ogranicz dostęp do /wp-admin i stron konfiguracji wtyczek według IP lub VPN, gdzie to możliwe.
   • Wymuszaj silne dane logowania administratora i uwierzytelnianie dwuskładnikowe dla wszystkich kont administratorów.
   • Rotuj hasła dla kont administratorów i wszystkich użytkowników, którzy niedawno odwiedzili strony ustawień wtyczek.
5. Włącz i dostosuj zaporę aplikacji internetowej (WAF):
   • Wdróż WAF, który może wykrywać i blokować próby wstrzykiwania HTML/JS za pomocą nazwa parametru lub powiązanych punktów końcowych.
   • Zastosuj wirtualne łatki/reguły, aby zablokować żądania POST/GET zawierające tagi , obsługiwacze zdarzeń JS lub podejrzane ładunki skierowane do punktów końcowych wtyczki.
6. Sprawdź wskaźniki kompromitacji (IOC):
   • Przeszukaj swoją bazę danych (wp_options, postmeta, tabele niestandardowe) w poszukiwaniu tagów skryptów lub podejrzanego JavaScript. Przykład SQL (uruchom na kopii testowej lub tylko do odczytu repliki DB):

     SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%<script %' OR option_value LIKE '%onmouseover=%' OR option_value LIKE '%javascript:%';

   • Sprawdź specyficzne dla wtyczki przechowywanie (szukaj nazw opcji, prefiksów tabel lub kluczy meta, które zawierają "alfie", "feed" lub "naam").
   • Sprawdź przesyłane pliki oraz pliki motywów/wtyczek pod kątem nowo dodanych lub zmodyfikowanych plików.
7. Skanuj witrynę:
   • Uruchom skaner złośliwego oprogramowania i integralności, aby wykryć wstrzyknięte skrypty, webshale lub nieoczekiwane modyfikacje.
   • Jeśli wykryjesz tagi skryptów w opcjach administracyjnych, których nie umieściłeś, usuń je ostrożnie po zarejestrowaniu logów i dowodów.
8. Kopia zapasowa do odzyskania:
   • Utwórz pełną kopię zapasową systemu plików + bazy danych i izoluj kopię zapasową do przeglądu kryminalistycznego przed oczyszczeniem witryny.

---

Jeśli znajdziesz aktywne naruszenie — odpowiedź na incydent

1. Umieść stronę w trybie konserwacji lub tymczasowo ją wyłącz, jeśli nie możesz zapewnić izolacji.
2. Zachowaj logi i dowody: logi serwera WWW, logi dostępu, logi aktywności WordPressa oraz migawki bazy danych.
3. Zidentyfikuj wektor i zakres: znajdź wszystkie lokalizacje przechowywania, w których złośliwy kod został zachowany.
4. Usuń złośliwe ładunki:
   • Ręcznie oczyść lub usuń złośliwe wartości z bazy danych (najlepiej najpierw na replikacie staging).
   • Zastąp zmodyfikowane pliki PHP z znanych dobrych kopii zapasowych lub świeżych kopii wtyczek/motywów.
5. Obracanie sekretów:
   • Zresetuj hasła dla wszystkich użytkowników administracyjnych.
   • Cofnij i ponownie wydaj wszelkie klucze API lub tokeny, które mogły być obsługiwane przez stronę.
6. Przejrzyj konta i role użytkowników w poszukiwaniu nieautoryzowanych użytkowników i usuń je.
7. Ponownie przeskanuj stronę, aby zweryfikować, że nie ma dalszej persystencji.
8. Włącz ponownie stronę, gdy kroki czyszczenia i wzmocnienia są już wdrożone.
9. W razie potrzeby zaangażuj profesjonalnego dostawcę usług reagowania na incydenty, aby zbadać potencjalny ruch boczny lub wyciek danych.

---

Jak wykrywać próby przed kompromitacją (wytyczne dotyczące logów i WAF)

• Monitoruj anomalne żądania POST do punktów końcowych wtyczek, szczególnie tam, gdzie nazwa pojawia się jako parametr.
• Ustaw zasady WAF lub sygnatury IDS dla:
  • Żądań zawierających tokeny <script lub .
  • Zakodowane ładunki, które dekodują się do tagów skryptów (script).
  • Użycia schematów URI JavaScript (JavaScript:) lub obsługiwanych zdarzeń inline (ładowanie=, onerror=, onclick=) w parametrach, które są później renderowane.
• Strona logowania administratora ładuje i rejestruje odsyłacze oraz adresy IP pochodzenia. Jeśli użytkownik administratora uzyskał dostęp do podejrzanego źródła tuż przed utrwaleniem skryptu w Twojej bazie danych, to jest to czerwona flaga.
• Skonfiguruj powiadomienia dla nowych lub zmodyfikowanych opcji/wniosków meta, które zawierają tagi HTML.

WAF-y mogą dać Ci okno czasowe: jeśli zauważysz wiele zablokowanych prób przeciwko temu samemu parametrowi lub punktowi końcowemu, podnieś poziom zagrożenia i zaostrz dostęp administratora.

---

Bezpieczne kodowanie i wzmacnianie wtyczek — co deweloperzy powinni naprawić

Autorzy wtyczek powinni wdrożyć następujące najlepsze praktyki, aby zapobiec przechowywanym wektorem XSS i CSRF:

1. Wymuszaj odpowiednie kontrole uprawnień

   if ( ! current_user_can( 'manage_options' ) ) {

2. Używaj nonce'ów do przesyłania formularzy i weryfikuj je:

   // Dodaj nonce do formularza;

3. Oczyść przychodzące dane przed ich przechowaniem:

   sanitize_text_field( $input['naam'] )

   W innych kontekstach: użyj wp_kses() z listą dozwolonych bezpiecznych tagów HTML, jeśli podstawowy HTML jest potrzebny.

4. Ucieczka przy wyjściu (ważne!)
   • Podczas drukowania wartości w atrybutach HTML: echo esc_attr( $value );
   • Podczas drukowania w treści HTML: echo esc_html( $value );
5. Unikaj przechowywania nieufnego surowego HTML w opcjach lub meta. Jeśli przechowywanie HTML jest wymagane, użyj ścisłych list dozwolonych i zabezpieczeń serializacji.
6. Unikaj polegania tylko na filtracji po stronie klienta. Walidacja po stronie serwera i ucieczka są obowiązkowe.

Minimalny wzór do obsługi po stronie serwera:

// Przykład: przetwarzaj bezpiecznie 'naam' przesłane metodą POST w obsłudze ustawień administratora;

Podczas wyjścia:

$naam = get_option( 'alfie_naam', '' );

---

WAF i wirtualne łatanie: praktyczne zasady blokowania tego wektora

Jeśli oficjalna łatka nie jest jeszcze dostępna, WAF może częściowo lub całkowicie złagodzić wykorzystanie, stosując ukierunkowane zasady. Poniżej znajdują się strategie obronne i przykłady (koncepcyjne — dostosuj, aby uniknąć fałszywych pozytywów):

1. Zablokuj żądania do adresów URL administracyjnych specyficznych dla wtyczek z nieufnych źródeł:
   • Odrzuć żądania do /wp-admin/admin-post.php lub innych znanych obsługiwaczy Alfie, gdy referer jest zewnętrzny, chyba że obecny jest ważny nonce.
2. Zablokuj dane wejściowe zawierające znaczniki skryptów:
   • Wykryj <script (i zakodowane odpowiedniki) w dowolnym parametrze żądania i zablokuj lub wyzwól (captcha).
   • Wykryj podejrzane atrybuty obsługi zdarzeń: ładowanie=, onerror=, onclick=, najechanie myszką=.
3. Zablokuj pseudo-protokóły JavaScript:
   • Odrzuć parametry zawierające JavaScript: URI.
4. Ogranicz aktywność POST w stosunku do punktu końcowego wtyczki, aby zapobiec zautomatyzowanym masowym próbom.
5. Uwaga dotycząca wirtualnego łatania:
   • Użyj zasady WAF, która szuka nazwa parametru zawierającego nawiasy kątowe lub obsługiwacze zdarzeń JS i zablokuj żądanie, jeśli pasuje. Najpierw wdroż tryb tylko do logowania, aby zmierzyć fałszywe pozytywy, a następnie wymuś blokowanie.

Przykład (pseudo-regex — nie wprowadzaj do produkcji bez testowania):

• Zablokuj, jeśli parametr zawiera zakodowany lub surowy <script:

  (?i)(|<)\s*skrypt

• Zablokuj, jeśli parametr zawiera błąd, załadować, kliknij poza bezpiecznymi kontekstami:

  (?i)on(błąd|załaduj|kliknij|mysz)

Ważny: Testuj zasady na etapie i monitoruj fałszywe pozytywy. Zbyt ogólne zasady mogą zakłócać legalne dane biznesowe i legalny HTML.

---

Czyszczenie: bezpieczne usuwanie przechowywanego XSS

• Nigdy nie edytuj bezpośrednio żywej bazy danych bez kopii zapasowej i starannego przeglądu.
• Pracuj na kopii tylko do odczytu lub stagingowej, aby zweryfikować skrypty usuwania.
• Zastąp wszelkie skompromitowane opcje lub wpisy metadanych oczyszczonymi wartościami lub usuń je całkowicie.
• Jeśli znajdziesz trwały skrypt wstrzyknięty do treści widgetu lub opcji, usuń część skryptu, a następnie ponownie przeskanuj witrynę.
• Jeśli witryna została skompromitowana, zweryfikuj integralność systemu plików (porównaj z wersjami wtyczek/motywów znanymi jako dobre) i zastąp zmodyfikowane pliki oficjalnymi wydaniami.

---

Lista kontrolna zapobiegania i wzmacniania w dłuższej perspektywie

Dla właścicieli stron i administratorów:

• Utrzymuj wszystkie motywy, wtyczki i rdzeń WordPressa zaktualizowane, a aktualizacje testuj w środowisku staging przed wdrożeniem na produkcję.
• Ogranicz liczbę kont administratorów. Używaj najmniejszych uprawnień.
• Wymuszaj uwierzytelnianie dwuskładnikowe (2FA) dla administratorów.
• Ogranicz dostęp do obszaru administracyjnego za pomocą list dozwolonych adresów IP lub VPN, gdzie to możliwe.
• Wprowadź surową Politykę Bezpieczeństwa Treści (CSP), aby zredukować wpływ wstrzykniętych skryptów.
• Wzmocnij punkty końcowe logowania (CAPTCHA, ograniczenie liczby prób).
• Używaj centralnie zarządzanych zabezpieczeń WAF i regularnego skanowania bezpieczeństwa.

Dla deweloperów:

• Przyjmij ucieczkę z wyjścia i oczyszczanie wejścia jako wymóg niepodlegający negocjacjom.
• Używaj nonce'ów do wszelkich aktualizacji zmieniających stan lub konfigurację.
• Waliduj i ograniczaj dozwolony HTML za pomocą list dozwolonych, jeśli akceptujesz wejście HTML.
• Dodaj testy jednostkowe/integracyjne, które sprawdzają, czy przechowywane wartości są ucieczone podczas renderowania.

---

Dlaczego WAF i zarządzane skanowanie mają znaczenie w przypadku tego typu podatności.

Problemy z przechowywanym XSS często występują w wtyczkach i motywach osób trzecich, gdzie oryginalny kod nie przestrzegał wytycznych dotyczących bezpiecznego rozwoju. Chociaż zawsze zalecamy aktualizację podatnych wtyczek, nie zawsze jest to możliwe od razu — na przykład, gdy wtyczka nie ma dostępnej poprawki lub gdy aktualizacja mogłaby przerwać krytyczną funkcjonalność biznesową.

Profesjonalnie dostrojony WAF zapewnia natychmiastową ochronę poprzez:

• Blokowanie prób wykorzystania na poziomie HTTP (zanim dotrą do podatnego kodu).
• Stosowanie wirtualnych poprawek w celu skierowania na podatny parametr i punkty końcowe.
• Wykrywanie i kwarantanna podejrzanych ładunków, które zawierają tagi skryptów lub zakodowane ładunki.
• Zapewnienie ciągłego skanowania i alertowania, aby wcześnie wychwycić oznaki kompromitacji.

Połączenie WAF z skanerem strony i workflow reagowania na incydenty zamyka lukę między ujawnieniem a wydaniem trwałej poprawki.

---

Często zadawane pytania, które słyszymy od właścicieli stron

Q: "Czy jeśli luka wymaga interakcji użytkownika, moja strona jest naprawdę zagrożona?"
A: Tak. Interakcja użytkownika (link phishingowy, złośliwy e-mail, skompromitowana strona partnera) jest często wszystkim, czego potrzebuje atakujący. Administratorzy klikają w linki. Kampanie w rzeczywistości łączą prostą inżynierię społeczną z pojedynczą luką, aby osiągnąć pełną kompromitację.

Q: "Czy WAF może zablokować wszystko?"
A: Żaden pojedynczy środek nie jest doskonały. WAF znacznie redukuje ryzyko i zyskuje czas podczas łatania, ale powinien być częścią warstwowych zabezpieczeń: kontroli dostępu, bezpiecznego kodu, monitorowania i reagowania na incydenty.

Q: "Czy powinienem usunąć wtyczkę?"
A: Jeśli wtyczka jest nieistotna lub masz alternatywę, jej natychmiastowe usunięcie jest najczystszą metodą łagodzenia. Jeśli wtyczka jest krytyczna i nie ma poprawki, izoluj ją za pomocą kontroli dostępu i wirtualnego łatania WAF, aż będzie można zastosować bezpieczną aktualizację.

---

Lista kontrolna reagowania na incydenty (jednostronicowe podsumowanie)

1. Kopia zapasowa DB + system plików; zachowaj logi.
2. Dezaktywuj podatną wtyczkę.
3. Ogranicz dostęp administratora (lista dozwolonych adresów IP, VPN).
4. Przeprowadź skanowanie złośliwego oprogramowania i integralności.
5. Przeszukaj DB pod kątem tagów skryptów i nieoczekiwanego HTML w opcjach/postmeta.
6. Usuń złośliwe ciągi na etapie; ponownie zaimportuj po weryfikacji.
7. Zastąp zmodyfikowane pliki, używając oficjalnych pakietów wtyczek/motywów.
8. Zmień dane logowania administratora i API.
9. Włącz ponownie usługi po weryfikacji i monitoruj logi.
10. Wdrożenie długoterminowych zabezpieczeń (WAF, CSP, 2FA).

---

Jak WP-Firewall pomaga Ci zmniejszyć narażenie i szybciej się odbudować

W WP-Firewall podchodzimy do takich incydentów z trzema równoległymi działaniami:

• Natychmiastowe łagodzenie za pomocą zarządzanych reguł WAF i wirtualnych poprawek, które blokują ścieżki eksploatacji (np. żądania, które zawierają tagi skryptów lub atrybuty obsługi zdarzeń w nazwa parametr).
• Ciągłe skanowanie w poszukiwaniu trwałości i wskaźników kompromitacji, z narzędziami, które mogą znaleźć przechowywane skrypty w opcjach, postmeta i innych lokalizacjach przechowywania.
• Plany działania w przypadku incydentów i wskazówki, które pomagają właścicielom stron bezpiecznie się odzyskać.

Podstawowy darmowy plan WP-Firewall obejmuje podstawowe zabezpieczenia, które skutecznie łagodzą tę klasę ataków (zarządzany firewall, sygnatury WAF, skanowanie złośliwego oprogramowania i łagodzenie OWASP Top 10). Jeśli potrzebujesz automatycznego usuwania lub szybszej reakcji, wyższe poziomy dodają automatyczne usuwanie złośliwego oprogramowania, czarne/białe listy, wirtualne łatanie i usługi zarządzane.

---

Nowość: Chroń swoją stronę już teraz z planem bez kosztów

Zabezpiecz dostęp administratora w kilka minut — zacznij od WP-Firewall Basic (Darmowy)

Jeśli chcesz natychmiast zmniejszyć ryzyko związane z tą podatnością Alfie i podobnymi problemami z wtyczkami, zacznij od naszego planu Podstawowego (Darmowego). Oferuje on podstawowe zabezpieczenia, w tym zarządzany firewall, dostosowany WAF, nieograniczoną przepustowość, automatyczne skanowanie w poszukiwaniu złośliwej zawartości i łagodzenie powszechnych ryzyk OWASP Top 10 — wszystko bez kosztów, aby zapewnić Ci bezpieczeństwo już dziś.

Zarejestruj się lub aktywuj darmowy plan tutaj: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Jeśli wolisz automatyczne czyszczenie i dodatkową kontrolę nad czarnymi i białymi listami IP, nasze plany Standard i Pro dodają automatyczne usuwanie złośliwego oprogramowania, zarządzanie IP, wirtualne łatanie podatności, miesięczne raportowanie i wsparcie na poziomie concierge.

---

Ostateczne zalecenia — praktyczne następne kroki dla większości właścicieli stron

1. Natychmiast zweryfikuj, czy Alfie jest zainstalowane i sprawdź wersje. Jeśli jest podatne, dezaktywuj lub ogranicz wtyczkę.
2. Wprowadź zasady WAF, aby zablokować HTML/JS w nazwa parametrze i innych wejściach, które mogą być trwałe.
3. Sprawdź swoją bazę danych pod kątem podejrzanych znaczników skryptów i usuń je w kontrolowany sposób.
4. Wzmocnij swój obszar administracyjny za pomocą 2FA i ograniczeń IP.
5. Zarejestruj się na zarządzany serwis WAF i skanowania (zacznij od darmowego planu, jeśli wolisz), podczas gdy czekasz na poprawki od dostawcy.
6. Zachęć autorów wtyczek do naprawy przyczyny: kontrole uprawnień, nonce po stronie serwera, odpowiednia sanitizacja i ucieczka oraz dokładne testy bezpieczeństwa.

---

Jeśli potrzebujesz pomocy w zastosowaniu któregokolwiek z powyższych kroków ograniczających, lub chcesz, aby WP-Firewall zastosował tymczasową wirtualną łatkę i przeskanował Twoją stronę w poszukiwaniu trwałości, nasz zespół może pomóc. Zacznij od darmowego planu, aby uzyskać natychmiastowe zabezpieczenia, a następnie rozważ aktualizację do automatycznej naprawy i zarządzanego wsparcia: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Bądź bezpieczny — najsłabsza wtyczka na stronie to pierwszy przystanek atakującego.