Nazwa wtyczki	Wtyczka do listy kontaktów WordPress
Rodzaj podatności	Atak typu cross-site scripting (XSS)
Numer CVE	CVE-2026-3516
Pilność	Niski
Data publikacji CVE	2026-03-22
Adres URL źródła	CVE-2026-3516

Pilne: Przechowywane XSS w wtyczce Kontakt Lista (≤ 3.0.18) — Co właściciele stron muszą teraz zrobić

Data: 2026-03-21
Autor: Zespół ds. bezpieczeństwa WP‑Firewall
Tagi: WordPress, Bezpieczeństwo, XSS, Podatność, WAF, Reakcja na incydenty

Podsumowanie: Przechowywana podatność na Cross‑Site Scripting (XSS) wpływająca na wtyczkę WordPress “Kontakt Lista” (wersje ≤ 3.0.18) pozwala uwierzytelnionemu użytkownikowi z uprawnieniami Współpracownika na przesyłanie danych HTML/iframe, które mogą być renderowane w sposób niebezpieczny, prowadząc do przechowywanego XSS (CVE‑2026‑3516). Łatka została wydana w wersji 3.0.19 w dniu 20 marca 2026 roku. Niniejsze zalecenie wyjaśnia wpływ, wykrywanie, usuwanie, krótkoterminowe wirtualne łatanie przy użyciu WAF oraz długoterminowe wzmocnienie.

Spis treści

• Szybkie fakty
• Jak działa podatność (przegląd, łańcuch eksploatacji)
• Rzeczywisty wpływ i scenariusze ataków
• Jak wykryć, czy Twoja strona jest dotknięta (wyszukiwania, WP‑CLI, zapytania DB, logi)
• Natychmiastowe kroki naprawcze (aktualizacja, łatka, usunięcie złośliwych wpisów)
• Krótkoterminowe łagodzenie za pomocą zapory aplikacji internetowej (wirtualne łatanie)
• Zalecane bezpieczne zmiany w kodowaniu i konfiguracji dla autorów wtyczek i właścicieli stron
• Lista kontrolna czyszczenia i reakcji na incydenty
• Lista kontrolna zapobiegania i długoterminowego wzmocnienia
• Często zadawane pytania
• Jak WP‑Firewall może pomóc (przegląd planu darmowego i link do rejestracji)

---

Szybkie fakty

• Dotknięte oprogramowanie: Wtyczka Kontakt Lista WordPress — wersje ≤ 3.0.18
• Typ podatności: Przechowywane skrypty międzywitrynowe (XSS)
• Wektor: Niezabezpieczony/niebezpieczny wynik _cl_map_iframe parametru (dostarczonego przez użytkownika iframe/html)
• Wymagane uprawnienia: Współtwórca (uwierzytelniony)
• Wymagana interakcja użytkownika: Tak (atakujący przechowuje ładunek; wykonanie wymaga uprzywilejowanego użytkownika lub konkretnej akcji/widoku)
• CVE: CVE‑2026‑3516
• CVSS (zgodnie z raportem): 6.5 (średni)
• Łatane w: Kontakt Lista v3.0.19 (wydana 20 marca 2026)

---

Jak działa podatność (na wysokim poziomie)

Przechowywane XSS występuje, gdy atakujący może dostarczyć dane, które są zapisywane na serwerze (baza danych, opcje, postmeta itp.) i później renderowane na stronie lub w widoku administratora bez poprawnego uciekania lub sanitizacji. W tym przypadku wtyczka akceptowała parametr o nazwie _cl_map_iframe który mógł zawierać HTML (iframe) i przechowywała go, a następnie renderowała tę wartość na ekranach frontendowych lub administracyjnych bez odpowiedniego filtrowania/uciekania.

Dlaczego to jest ważne:

• Współpracownicy to uwierzytelnieni użytkownicy na Twojej stronie WordPress. Zazwyczaj nie mogą publikować postów, ale mogą przesyłać treści, które są później zatwierdzane. Jeśli wtyczka zapisuje wartość dostarczoną przez współpracownika w polu bazy danych, a ta wartość jest później renderowana na stronie administracyjnej lub na stronie wyświetlanej przez użytkowników o wyższych uprawnieniach, przechowywana treść może być wykonywana w kontekście każdego, kto ją wyświetla.
• Ładunek przechowywanego XSS może działać w przeglądarce administratora/edytora lub nawet odwiedzającego stronę (w zależności od tego, gdzie wtyczka wyprowadza tę wartość), prowadząc do przejęcia konta, kradzieży sesji lub nieautoryzowanych działań wykonywanych z uprawnieniami ofiary.

Łańcuch eksploatacji w tym raporcie jest zasadniczo:

1. Atakujący uwierzytelnia się jako Współpracownik.
2. Atakujący przesyła kontakt lub ustawienie zawierające spreparowane _cl_map_iframe ładunek.
3. Wtyczka przechowuje ładunek bez odpowiedniej sanitizacji/escapingu.
4. Gdy uprzywilejowany użytkownik (lub widok strony, który renderuje przechowywaną wartość) ładuje treść, złośliwy skrypt jest wykonywany.

Notatka: Opublikowany raport stwierdza, że wykorzystanie wymaga interakcji użytkownika — więc atakujący samodzielnie nie może łatwo przejąć konta administratora; uprzywilejowany użytkownik musi zobaczyć lub interagować ze stroną, która zawiera przechowywany ładunek.

---

Rzeczywisty wpływ i scenariusze ataków

Mimo że Współpracownik to stosunkowo niskopoziomowa rola, przechowywane XSS może eskalować i poszerzać wpływ. Przykłady:

• Kradzież sesji administratora — jeśli ładunek kradnie ciasteczka administratora lub tokeny sesji, a następnie eksfiltruje je do domeny kontrolowanej przez atakującego, atakujący może podszyć się pod administratora.
• Działania oparte na przeglądarce — JavaScript wykonywany w kontekście administratora może przesyłać formularze, zmieniać ustawienia wtyczek/motywów, tworzyć nowych użytkowników, przesyłać złośliwe pliki lub instalować tylne drzwi.
• Phishing i inżynieria społeczna — atakujący dodaje iframe lub treść, która wprowadza w błąd uprzywilejowanych użytkowników do wykonywania działań, które ujawniają dane uwierzytelniające lub zatwierdzają treści.
• Utrwalona defacement strony lub wstrzykiwanie reklam — ładunek może wstrzykiwać banery lub przekierowywać odwiedzających na złośliwe strony.
• Wpływ na łańcuch dostaw — jeśli strona zarządzana przez agencję zostanie skompromitowana, atakujący mogą wykorzystać ją jako punkt zaczepienia do zainfekowania klientów lub dystrybucji złośliwego oprogramowania.

Ponieważ podatność jest przechowywana, pojedyncze spreparowane zgłoszenie może wpływać na wielu użytkowników w czasie i na różnych stronach.

---

Jak sprawdzić, czy twoja witryna jest dotknięta (wykrywanie)

Powinieneś założyć, że każda strona działająca na Contact List ≤ 3.0.18 jest potencjalnie dotknięta, dopóki nie zweryfikujesz.

Ważne kroki na wysokim poziomie:

1. Potwierdź wersję wtyczki
2. Przeszukaj bazę danych w poszukiwaniu podejrzanych _cl_map_iframe wartości i innych związanych z wtyczką przechowywanych HTML
3. Szukaj nietypowej aktywności administratora, nowych użytkowników lub zmodyfikowanych plików
4. Skanuj za pomocą skanera integralności/złośliwego oprogramowania

Poniżej znajdują się praktyczne kontrole, które możesz przeprowadzić natychmiast.

1) Potwierdź wersję wtyczki w WordPress Admin lub systemie plików

• WordPress Admin: Wtyczki → Zainstalowane wtyczki → Lista kontaktów → zanotuj wersję.
• System plików: Sprawdź readme.txt lub nagłówek wtyczki w /wp-content/plugins/contact-list/contact-list.php dla ciągu wersji.

2) Przeszukaj bazę danych w poszukiwaniu _cl_map_iframe parametr

Luka odnosi się do parametru _cl_map_iframe. Przechowywane wartości mogą znajdować się w postmeta, opcjach lub tabeli wtyczki.

Użyj WP‑CLI lub bezpośredniego SQL. Uważaj na dostęp do DB i wykonaj kopie zapasowe przed wprowadzeniem zmian.

Przykłady WP‑CLI:

# Przeszukaj postmeta"

Skierowane zapytanie MySQL:

SELECT option_name AS location, option_value AS value;

Szukaj typowych wskaźników XSS:

• <script
• JavaScript:
• onerror=, onload=, onclick=
• <iframe z zewnętrznym źródłem lub atrybutami srcdoc

3) Przeszukaj tabele wtyczek i treść postów

Jeśli wtyczka przechowuje kontakty w niestandardowej tabeli (np., wp_cl_records lub podobnej), przeszukaj kolumny tej tabeli w poszukiwaniu <iframe Lub <script.

4) Użyj WP‑CLI lub grep, aby sprawdzić pliki wtyczek pod kątem niebezpiecznych echo (dla deweloperów witryn)

Szukać echo Lub drukować surowych zmiennych bez esc_ funkcje:

grep -R --line-number "echo .*_cl_map_iframe" wp-content/plugins/contact-list || true

Następnie sprawdź, jak wtyczka wyświetla wartość (czy jest esc_attr(), esc_html() Lub wp_kses() używana?).

5) Dzienniki serwera i aktywność administratora

• Sprawdź dzienniki dostępu pod kątem POST-ów z kont contributorów dodających kontakty lub nietypowych ładunków POST zawierających iframe.
• Przejrzyj wtyczki Ostatnia Aktywność, dzienniki audytu lub dzienniki panelu sterowania hosta w poszukiwaniu zmian w pobliżu daty ujawnienia.

6) Skanowanie złośliwego oprogramowania i integralności

Uruchom skaner złośliwego oprogramowania i sprawdzenie integralności plików (porównaj pliki wtyczki z czystą kopią wtyczki). Szukaj dodanych plików PHP lub zmodyfikowanych plików rdzenia/wtyczki.

---

Natychmiastowe działania naprawcze (co zrobić teraz)

Jeśli zarządzasz witryną WordPress z Contact List ≤ 3.0.18, wykonaj te natychmiastowe kroki:

1. Zaktualizuj wtyczkę do v3.0.19 lub nowszej (zalecany pierwszy krok)
   • To jest ostateczna poprawka. Zawsze testuj aktualizacje na środowisku testowym, jeśli to możliwe.
2. Jeśli nie możesz zaktualizować natychmiast (problemy ze środowiskiem testowym/kompatybilnością):
   • Tymczasowo dezaktywuj wtyczkę Contact List.
   • Jeśli dezaktywacja nie jest możliwa, ogranicz możliwości Contributorów za pomocą wtyczki do zarządzania rolami (zapobiegaj contributorom w przesyłaniu treści, które trafiają na podatną ścieżkę zapisu).
   • Blokuj żądania, które zawierają podejrzane _cl_map_iframe ładunki za pomocą swojego WAF (zobacz sekcję WAF poniżej).
3. Wyszukaj i oczyść przechowywane ładunki
   • Znajdź przechowywane wartości zawierające HTML/iframe/skrypt i usuń lub oczyść je.
   • Przykład: zastąp podejrzane wartości pustym ciągiem lub bezpiecznym miejscem po dokładnym przeglądzie.
   • Zawsze wykonuj kopie zapasowe bazy danych przed zmianą wartości.
4. Kontrola kont użytkowników
   • Weryfikuj konta współpracowników pod kątem podejrzanych rejestracji lub rozszerzeń uprawnień.
   • Wymuś resetowanie haseł dla użytkowników, którzy mogli mieć kontakt z podejrzanym kontentem.
   • Rozważ tymczasowe wyłączenie nowo utworzonych lub nieufnych kont współpracowników.
5. Skanuj w poszukiwaniu powłok sieciowych i tylnej furtki.
   • Jeśli znajdziesz jakikolwiek nieautoryzowany kod, wyłącz stronę w celu naprawy, przywróć z czystej kopii zapasowej, jeśli to konieczne, i przeprowadź pełny przegląd kryminalistyczny.
6. Rotuj dane uwierzytelniające i klucze bezpieczeństwa.
   • Rotuj hasła administratorów, klucze API i rozważ rotację soli WordPress w wp-config.php jeśli podejrzewasz kradzież sesji.
7. Rejestruj i monitoruj
   • Włącz/sprawdź dzienniki audytu dla uprzywilejowanych użytkowników odwiedzających strony, które mogą renderować przechowywany ładunek.
   • Monitoruj połączenia wychodzące ze strony w poszukiwaniu prób eksfiltracji danych.

---

Krótkoterminowe łagodzenie: wirtualne łatanie WAF (co powinien robić WAF).

Zapora aplikacji internetowej (WAF) zapewnia krótkoterminową wirtualną łatkę, która blokuje złośliwe ładunki na warstwie HTTP, zanim dotrą do WordPressa. Wirtualne łatanie to praktyczne rozwiązanie tymczasowe, podczas gdy aktualizujesz wtyczki lub naprawiasz przechowywane ładunki.

Co blokować:

• Żądania zawierające _cl_map_iframe wartości parametrów z <script tagi, JavaScript: URI lub wewnętrznymi obsługami zdarzeń (ładowanie=, onerror=itp.)
• POST-y z kont współpracowników, które zawierają podejrzany HTML w polach map/iframe.
• Podejrzane wartości w żądaniach POST bez referera lub żądaniach z nietypowymi agentami użytkownika.

Przykład koncepcji reguły ModSecurity (ilustracyjny; dostosuj do swojego środowiska):

# Blokuj _cl_map_iframe zawierające tagi skryptów lub URI javascript:"

Ważny: dostosowanie jest konieczne, aby uniknąć fałszywych pozytywów. Najpierw testuj reguły w trybie monitorowania (zamiast blokowania).

Zasady WAF mogą również:

• Oczyść lub usuń iframe elementy z ciał POST
• Blokować żądania, w których konta współpracowników próbują przesłać HTML (w zależności od zachowania i uzasadnionych potrzeb)

Jeśli korzystasz z zarządzanego WAF lub zewnętrznej usługi zapory, przekaż zidentyfikowane wskaźniki, aby mogły szybko wdrożyć wirtualną łatkę w całej swojej sieci.

Uwaga dotycząca blokowania na poziomie witryny:

• Jeśli wdrażasz zasady WAF w WordPressie (za pomocą zapory opartej na wtyczkach), upewnij się, że zasady wychwytują _cl_map_iframe parametr i oznaczają go lub oczyszczają przed zapisaniem.

---

Poprawki na poziomie kodu i najlepsze praktyki (dla programistów i autorów wtyczek)

Jeśli utrzymujesz wtyczkę Listy Kontaktów lub zarządzasz niestandardowym kodem, zastosuj te bezpieczne praktyki kodowania:

1. Waliduj na wejściu
   • Upewnij się, że przychodzące dane odpowiadają oczekiwanym formatom.
   • Jeśli wtyczka oczekuje tylko adresu URL lub identyfikatora osadzenia Google Maps, akceptuj tylko to i odrzucaj wszystko, co zawiera tagi HTML.
2. Oczyszczaj i escape'uj na wyjściu
   • Nigdy nie wyświetlaj treści kontrolowanej przez użytkownika bez escape'owania.
   • Używaj odpowiednich interfejsów API WordPressa:
     • esc_attr() podczas wstrzykiwania wartości do atrybutu
     • esc_url() dla URL-i
     • esc_html() dla wyjścia w czystym tekście
     • wp_kses() Lub wp_kses_post() z rygorystyczną listą dozwolonych, jeśli musisz zezwolić na podzbiór HTML
   • Przykład: wyświetl adres URL mapy z echo esc_url( $map_url );
3. Unikaj przechowywania surowego HTML, chyba że to konieczne
   • Jeśli musisz zaakceptować osadzenia iframe, sprawdź źródło iframe i zezwól tylko na bezpieczne kombinacje (na przykład, zezwól tylko na src wartości, które pasują do zaufanych domen, takich jak https://maps.google.com).
4. Użyj kontroli uprawnień
   • Upewnij się, że tylko role z uzasadnioną potrzebą biznesową mogą przechowywać treści HTML.
   • Zastosuj bieżący_użytkownik_może() sprawdzenia przed zaakceptowaniem uprzywilejowanych pól.
5. Używaj nonce'ów i zabezpieczeń CSRF dla przesyłania formularzy.
6. Rejestruj i oczyszczaj widoki administratora
   • Podczas renderowania widgetów administratora lub podglądu treści, traktuj przechowywane wartości jako potencjalnie wrogie i renderuj je bezpiecznie.

Autorzy wtyczek muszą rozważyć ryzyko związane z pozwoleniem Współpracownikom na przechowywanie danych, które będą renderowane na stronach administratora. Powszechnym bezpiecznym wzorcem projektowym jest oczyszczanie i przechowywanie tylko danych strukturalnych (ID, bezpieczne URL-e), nigdy surowego HTML z niższych ról.

---

Lista kontrolna czyszczenia i reakcji na incydenty

Jeśli potwierdzisz kompromitację lub podejrzewasz, że ładunek XSS został wykonany, postępuj zgodnie z tą priorytetową listą kontrolną.

1. Izolować
   • Jeśli złośliwa działalność trwa, wyłącz stronę lub ogranicz dostęp do paneli administratora.
2. Kopia zapasowa
   • Wykonaj pełną kopię zapasową (pliki + DB) do analizy kryminalistycznej.
3. Poprawka
   • Natychmiast zaktualizuj wtyczkę do wersji 3.0.19.
4. Wyeliminuj złośliwą zawartość
   • Usuń przechowywane _cl_map_iframe ładunki lub je oczyść.
   • Szukaj dodatkowych podejrzanych wartości w postmeta, opcjach i wszelkich niestandardowych tabelach wtyczek.
5. Wykryj trwałość
   • Skanuj w poszukiwaniu powłok sieciowych (pliki PHP w uploads, zmodyfikowane pliki motywów lub wtyczek).
   • Sprawdzać wp-config.php I funkcje.php wstrzyknięty kod.
   • Sprawdź katalog uploads i inne katalogi, do których można pisać.
6. Poświadczenia i sekrety
   • Zresetuj hasła dla wszystkich kont administratorów/edytorów.
   • Zmień klucze API, tokeny i sole WordPress, jeśli to konieczne.
7. Przejrzyj logi
   • Zbieraj i przeglądaj dzienniki dostępu do serwera, dzienniki aplikacji i dzienniki audytu administratora, aby określić zakres i harmonogram.
8. Przywróć i zweryfikuj
   • Jeśli przywracasz kopię zapasową, upewnij się, że jest czysta i zaktualizowana, a następnie wykonaj te same kroki skanowania przed całkowitym uruchomieniem strony.
9. Raport i dokumentacja
   • Udokumentuj incydent, kroki naprawcze i harmonogram audytów.
   • Poinformuj interesariuszy i klientów, jeśli to możliwe.
10. Monitor
    • Po naprawie ściśle monitoruj zmiany w plikach i ruch przez pewien czas.

---

Lista kontrolna zapobiegania i długoterminowego wzmocnienia

• Utrzymuj aktualny rdzeń WordPressa, motywy i wtyczki.
• Ogranicz tworzenie kont i dokładnie przeglądaj role/uprawnienia dla współpracowników.
• Zastosuj zasadę najmniejszych uprawnień — użytkownicy i wtyczki mają tylko to, czego potrzebują.
• Użyj WAF, który obsługuje wirtualne łatanie i dostosowane zasady.
• Wdróż ciągłe monitorowanie integralności plików i zaplanowane skanowanie złośliwego oprogramowania.
• Użyj polityki bezpieczeństwa treści (CSP), aby ograniczyć, skąd mogą ładować się skrypty i ramki.
• Regularnie audytuj kod wtyczek, jeśli zezwalasz na wtyczki osób trzecich.
• Utrzymuj regularne kopie zapasowe i testuj procedury przywracania.
• Włącz uwierzytelnianie dwuskładnikowe na wszystkich uprzywilejowanych kontach.
• Rozważ staging dla aktualizacji wtyczek, aby zweryfikować zachowanie przed wdrożeniem produkcyjnym.

---

Często zadawane pytania (FAQ)

Q: Moja strona ma współpracowników, którzy muszą przesłać kod iframe mapy. Co powinienem zrobić?
A: Ponownie oceń ten proces. Jeśli współpracownicy muszą dostarczać osadzenia, akceptuj tylko uporządkowane dane wejściowe (np. bezpieczny identyfikator mapy) i oczyszczaj przy zapisie. Alternatywnie, ogranicz możliwość osadzania do ról Edytora+ i użyj procesu moderacji/publikacji.

Q: Co jeśli zaktualizowałem wtyczkę, ale nadal widzę podejrzane wpisy?
A: Aktualizacja zapobiega nowym zgłoszeniom podatnego typu, ale nie usuwa automatycznie istniejących złośliwych ładunków. Musisz przeszukać bazę danych i usunąć/oczyścić te wpisy.

Q: Czy ta luka może być wykorzystana przez anonimowych odwiedzających?
A: Zgłoszony problem wymaga uwierzytelnionego dostępu współpracownika do przechowywania ładunku. Jednak jeśli istnieje skompromitowane konto współpracownika lub rejestracja konta jest dozwolona, atakujący mogą uzyskać rolę współpracownika.

Q: Czy wyłączenie wtyczki całkowicie łagodzi ryzyko?
A: Zazwyczaj tak — jeśli wtyczka jest dezaktywowana, nie powinna wyświetlać przechowywanych wartości na stronach. Dezaktywacja jest ważnym tymczasowym rozwiązaniem, jeśli nie możesz natychmiast zaktualizować. Nadal przeszukuj przechowywane ładunki i oczyść je przed ponowną aktywacją.

---

Dlaczego warto rozważyć użycie WP‑Firewall teraz

Tytuł: Chroń swoją stronę natychmiast — darmowy zarządzany firewall i ochrona WAF

Jeśli potrzebujesz szybkiej, praktycznej warstwy ochrony podczas aktualizacji i czyszczenia dotkniętych stron, WP‑Firewall zapewnia zawsze aktywny zarządzany firewall i WAF, które mogą pomóc w blokowaniu prób wykorzystania i zapewnieniu wirtualnych poprawek. Nasz plan Basic (Darmowy) zapewnia natychmiastową podstawową ochronę: zarządzane zasady firewalla, nielimitowaną przepustowość, WAF, skanowanie złośliwego oprogramowania i pokrycie w zakresie łagodzenia ryzyk OWASP Top 10 — doskonała pierwsza linia obrony podczas usuwania luk wtyczek.

Zarejestruj się na darmowy plan już dziś i uzyskaj natychmiastową ochronę: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Jeśli potrzebujesz automatycznego czyszczenia, czarnej/białej listy IP, miesięcznych raportów bezpieczeństwa i automatycznych wirtualnych poprawek na dużą skalę, nasze płatne plany dodają te możliwości.)

---

Ostateczne uwagi — co priorytetowo traktować teraz

1. Jeśli używasz Contact List ≤ 3.0.18, zaktualizuj do 3.0.19 natychmiast.
2. Jeśli nie możesz zaktualizować od razu, dezaktywuj wtyczkę lub zastosuj zasady WAF, aby zablokować podejrzane _cl_map_iframe wejścia.
3. Przeszukaj swoją bazę danych w poszukiwaniu zapisanych wartości skryptów/iframe i usuń lub oczyść je.
4. Audytuj konta użytkowników i zmień dane uwierzytelniające tam, gdzie to stosowne.
5. Użyj zarządzanego WAF i ciągłego skanowania, aby zmniejszyć narażenie podczas usuwania.

Jeśli potrzebujesz pomocy w zakresie wirtualnych poprawek, skanowania bazy danych w poszukiwaniu zapisanych ładunków lub prowadzonego czyszczenia, zespół WP‑Firewall może pomóc. Nasz darmowy plan dodaje szybką warstwę łagodzenia podczas gdy kończysz niezbędne aktualizacje i kroki reagowania na incydenty.

---

Jeśli wolisz krótką listę kontrolną do skopiowania/wklejenia:

• [ ] Potwierdź wersję Contact List
• [ ] Zaktualizuj do v3.0.19
• [ ] Zrób kopię zapasową DB/plików
• [ ] Przeszukaj <script, JavaScript:, onerror=, <iframe w polach DB (wp_postmeta, wp_options, tabele niestandardowe)
• [ ] Usuń/oczyść podejrzane zapisane wartości
• [ ] Skanuj w poszukiwaniu powłok sieciowych i nieautoryzowanych plików
• [ ] Zresetuj dane uwierzytelniające dla dotkniętych kont
• [ ] Wdróż zasady WAF, aby zablokować złośliwe _cl_map_iframe wejścia do czasu ich oczyszczenia
• [ ] Monitoruj dzienniki w poszukiwaniu podejrzanej aktywności

---

Bądź bezpieczny. Nasz zespół publikuje na czas ostrzeżenia i wytyczne operacyjne dotyczące incydentów bezpieczeństwa WordPress — jeśli potrzebujesz pomocy w wykrywaniu, wirtualnym łatach lub oczyszczaniu, skontaktuj się za pośrednictwem pulpitu nawigacyjnego WP‑Firewall lub zarejestruj się, aby uzyskać natychmiastową ochronę: https://my.wp-firewall.com/buy/wp-firewall-free-plan/