| Nazwa wtyczki | Codziennie twórz kopię zapasową |
|---|---|
| Rodzaj podatności | Atak typu cross-site scripting (XSS) |
| Numer CVE | CVE-2026-3577 |
| Pilność | Niski |
| Data publikacji CVE | 2026-03-22 |
| Adres URL źródła | CVE-2026-3577 |
Pilne: Przechowywane XSS w “Codziennie twórz kopię zapasową” (<= 2.1.2) — Co właściciele WordPressa muszą wiedzieć i zrobić teraz
Data: 20 mar, 2026
Wrażliwość: Uwierzytelnione (Administrator) Przechowywane Cross-Site Scripting (XSS) za pomocą tytułu kopii zapasowej
Dotyczy wersji: Wtyczka Codziennie twórz kopię zapasową <= 2.1.2
Poprawione w: 2.1.3
CVE: CVE-2026-3577
Priorytet WP-Firewall: Niskie (CVSS 5.9) — ale nie powinno być ignorowane
Jako zespół ds. bezpieczeństwa WordPressa i dostawca zapory aplikacji internetowych WordPress (WAF), chcemy przedstawić praktyczne, jasne i wykonalne podsumowanie niedawno ujawnionego przechowywanego XSS wpływającego na wtyczkę Codziennie twórz kopię zapasową. To ostrzeżenie jest napisane dla programistów, właścicieli stron i administratorów, którzy muszą zrozumieć ryzyko, wykrywanie i łagodzenie z perspektywy rzeczywistej — nie tylko w języku bezpieczeństwa.
Ta luka pozwala uwierzytelnionemu użytkownikowi z uprawnieniami administratora na przechowywanie JavaScriptu (lub innego HTML) w polu tytułu kopii zapasowej. Jeśli ta przechowywana treść zostanie później wyświetlona bez odpowiedniego oczyszczenia, może zostać wykonana w przeglądarce innego użytkownika (na przykład innego administratora lub redaktora), co potencjalnie prowadzi do kompromitacji konta, trwałego zniekształcenia strony lub dalszej eksploatacji (takiej jak dodawanie tylnej furtki, zmiana ustawień lub instalowanie złośliwych wtyczek/tematów).
Poniżej znajdziesz:
– Zwięzły opis techniczny
– Dlaczego to ma znaczenie, nawet przy wymaganym dostępie tylko dla administratorów
– Realistyczne scenariusze ataków i ich wpływ
– Metody wykrywania i wskaźniki kompromitacji (IoCs)
– Natychmiastowe łagodzenia (w tym wskazówki dotyczące WAF/wirtualnych poprawek i reguł)
– Długoterminowe zalecenia dotyczące wzmocnienia i reakcji na incydenty
– Jak WP-Firewall może pomóc (w tym szczegóły naszego darmowego planu i link do rejestracji)
1 — Co się stało (podsumowanie techniczne)
- Wtyczka przechowuje wartość “tytułu” kopii zapasowej bez odpowiedniego oczyszczania lub sanitizacji przy wyjściu (i być może przy wejściu) w widoku administratora lub innej dostępnej stronie.
- Uwierzytelniony użytkownik z uprawnieniami administratora może utworzyć kopię zapasową i wprowadzić JavaScript lub HTML do pola tytułu. Ponieważ tytuł jest przechowywany i później renderowany przez interfejs użytkownika wtyczki bez odpowiedniego kontekstowego oczyszczania, ta treść jest wykonywana w przeglądarce każdego, kto przegląda stronę.
- To jest klasyfikowane jako przechowywana (trwała) podatność XSS. W przeciwieństwie do odzwierciedlonego XSS, przechowywane XSS wstrzykuje treść, która utrzymuje się w backendzie aplikacji (baza danych, opcje, metadane kopii zapasowej) i jest serwowana użytkownikom później.
- Dostawca naprawił ten problem w wersji 2.1.3, wprowadzając odpowiednią sanitizację/escapowanie tam, gdzie to konieczne. Strony nadal działające w wersji <= 2.1.2 pozostają narażone na ryzyko.
2 — Analiza ryzyka i wpływu
Na pierwszy rzut oka, przechowywane XSS dostępne tylko dla administratorów może wydawać się niskiego ryzyka: w końcu atakujący już miał dostęp do konta administratora. Ale istnieje kilka realistycznych scenariuszy zagrożeń, w których ta podatność jest niebezpieczna i powinna być natychmiast naprawiona:
- Skonfiskowane konto administratora lub nieuczciwy administrator: Jeśli atakujący uzyska dostęp do konta administratora (poprzez ponowne użycie danych uwierzytelniających, phishing, skradzione tokeny sesji), mogą umieścić trwały JavaScript w tytule kopii zapasowej. Ten przechowywany ładunek będzie działał za każdym razem, gdy inni użytkownicy administracyjni przeglądają listę kopii zapasowych lub inne UI, które renderuje tytuł — rozszerzając atak na dodatkowe konta.
- Eskalacja uprawnień i utrzymywanie dostępu: Ładunek XSS przechowywany może wykonywać JavaScript w kontekście zalogowanego administratora. To pozwala atakującemu na:
- Zbieranie ciasteczek sesyjnych lub nonce'ów uwierzytelniających i ich wykradanie.
- Wykonywanie nieautoryzowanych działań za pośrednictwem UI administratora, wykorzystując prawa ofiary (instalowanie wtyczek, zmiana opcji, tworzenie nowych użytkowników administratora).
- Wstrzykiwanie tylnej furtki do plików motywów/wtyczek (poprzez edytor mediów, edytory wtyczek lub zainstalowane edytory plików) — prowadząc do pełnego kompromitacji strony.
- Ekspozycja łańcucha dostaw i wielu witryn: Na zarządzanych platformach lub w środowiskach wielowitrynowych, gdzie wiele witryn lub użytkowników wchodzi w interakcje, przechowywane XSS może być używane do przechodzenia między kontami i witrynami.
- Reputacja i SEO: Nawet pozornie drobny trwały skrypt może powodować pętle przekierowań, wstrzykiwanie spamu lub dyskretne wstawianie reklam, szkodząc SEO i zaufaniu użytkowników.
Chociaż CVSS i niektórzy analitycy oznaczają to jako priorytet “niski”, ponieważ atakujący musi być administratorem (lub administrator musi być oszukany, aby wchodzić w interakcje z przygotowanym elementem), w praktyce atakujący wykorzystują te wektory jako część wieloetapowych ataków, które prowadzą do poważnych konsekwencji. Traktuj to poważnie.
3 — Scenariusze eksploatacji (na wysokim poziomie)
Nie opublikujemy kodu eksploatacji ani ładunków. Poniżej znajdują się scenariusze na wysokim poziomie, które mogą wykorzystać atakujący:
- Scenariusz A: Ponowne użycie danych uwierzytelniających prowadzi do kompromitacji administratora. Atakujący loguje się, tworzy kopię zapasową z złośliwym tytułem. Inny administrator później odwiedza listę kopii zapasowych; skrypt wykonuje się w ich przeglądarce, kradnie nonce sesji, a atakujący przejmuje dodatkowe konta.
- Scenariusz B: Phishing + przechowywany ładunek. Atakujący przekonuje administratora do kliknięcia na pozornie nieszkodliwy wewnętrzny link (np. “Zobacz kopie zapasowe”). Sesja administratora wykonuje przechowywany skrypt, który automatycznie wykonuje działania takie jak instalacja wtyczek lub tworzenie użytkowników przez UI administratora.
- Scenariusz C: Zagrożenie wewnętrzne. Niezadowolony administrator umieszcza trwały skrypt w metadanych kopii zapasowej, aby sabotować lub wykradać dane, gdy inni administratorzy logują się.
Krótko mówiąc: chociaż tylko administratorzy mogą wstrzykiwać ładunek, przechowywane XSS umożliwia ruch boczny i eskalację, co czyni to ryzykiem niebagatelnym.
4 — Natychmiastowe działania (triage i łatanie)
- Zaktualizuj wtyczkę do wersji 2.1.3 lub nowszej natychmiast.
- To najszybsze i najbardziej niezawodne rozwiązanie.
- Jeśli nie możesz zaktualizować natychmiast (kompatybilność z systemem starszym, staging), to:
- Tymczasowo wyłącz wtyczkę, jeśli kopie zapasowe mogą być obsługiwane przez inną zaufaną wtyczkę lub narzędzia dostawcy hostingu.
- Ogranicz dostęp do interfejsu kopii zapasowych — tylko znane adresy IP administratorów lub konta administratorów.
- Włącz ścisłe monitorowanie i wykrywanie intruzji na kontach administratorów.
- Zmień dane logowania administratorów i włącz MFA:
- Wymagaj MFA (uwierzytelnianie dwuskładnikowe) dla wszystkich kont administratorów.
- Wymuś resetowanie haseł dla kont administratorów, jeśli podejrzewasz naruszenie.
- Przejrzyj kopie zapasowe i wpisy w bazie danych:
- Szukaj metadanych kopii zapasowych (tytułów) zawierających “<script”, “javascript:” lub podejrzane encje HTML.
- Jeśli znajdziesz podejrzane wpisy, oczyść je lub usuń odpowiadające kopie zapasowe. Najpierw wyeksportuj kopie zapasowe do bezpiecznej lokalizacji przed usunięciem.
- Skanuj witrynę:
- Przeprowadź pełne skanowanie złośliwego oprogramowania w przesyłanych plikach, motywach, wtyczkach i bazie danych.
- Szukaj niedawno zmodyfikowanych plików i nieoczekiwanych użytkowników administratorów.
- Audyt logów:
- Sprawdź dzienniki działań administratorów — tworzenie kopii zapasowych, tworzenie użytkowników, instalacja wtyczek — pod kątem podejrzanych znaczników czasu i adresów IP.
- Jeśli incydent zostanie potwierdzony:
- Postępuj zgodnie z planem reakcji na incydenty: izoluj stronę (tryb konserwacji lub tymczasowa blokada zapory), zrób zrzut systemu plików, zachowaj logi, zmień klucze, przywróć z czystej kopii zapasowej, jeśli to konieczne.
5 — Jak wykryć wykorzystanie (wskaźniki naruszenia)
Szukaj tych oznak, że wykorzystano lub próbowano wykorzystać XSS przechowywane:
- Zapasowe tytuły lub metadane w bazie danych zawierające tagi skryptów lub zakodowane sekwencje JavaScript:
- Ciągi takie jak “<script”, “onerror=”, “javascript:”, lub podejrzane zakodowane ładunki (script).
- Nagłe zmiany dokonane przez konta administracyjne, których nie rozpoznajesz (nowi użytkownicy admina, zmiany w wtyczkach/motylach).
- Niespodziewane wychodzące żądania HTTP z panelu administracyjnego do zewnętrznych domen (ekstrakcja ładunków często wykorzystuje zdalne punkty końcowe).
- Anomalie w przeglądarkach zgłaszane przez administratorów:
- Dziwne okna pop-up, automatyczne przesyłanie formularzy lub przekierowania podczas otwierania strony kopii zapasowej.
- Zwiększona liczba błędów 4xx/5xx lub nietypowe zachowanie interfejsu administracyjnego.
- Logi serwera WWW pokazujące żądania POST/PUT do punktów końcowych wtyczek z podejrzanymi ładunkami.
Przeszukaj bazę danych pod kątem wpisów w tabelach specyficznych dla wtyczek lub wp_options, gdzie przechowywane są metadane kopii zapasowej. Uruchom:
- Zapytanie do bazy danych w celu zlokalizowania podejrzanych tytułów kopii zapasowych (odpowiednio escapuj przed uruchomieniem zapytań na produkcji).
- Sprawdzenie integralności plików, aby zobaczyć, czy pliki po stronie admina zostały zmodyfikowane.
6 — WAF / wskazówki dotyczące wirtualnego łatania (zalecane zasady)
Jeśli natychmiastowa aktualizacja nie jest opcją, WAF (wirtualna łatka) może zmniejszyć narażenie, przechwytując i blokując próby wykorzystania. Poniżej znajdują się zalecane strategie zasad, które WP-Firewall rekomenduje i może wdrożyć dla Ciebie:
- Blokuj podejrzane dane wejściowe do punktów końcowych wtyczek, które obsługują tworzenie lub edytowanie kopii zapasowych.
- Oczyść lub zablokuj żądania z treścią przypominającą tagi w polach, które powinny zawierać tylko prosty tekst (tytuł kopii zapasowej).
- Odrzuć żądania zawierające podejrzane wzorce (np. “<script”, “onerror=”, “javascript:”) w zmiennych POST lub ładunkach JSON.
- Ogranicz punkty końcowe do uwierzytelnionych żądań i zezwól tylko na znane sesje admina i zakresy IP.
Przykład reguły w stylu ModSecurity (koncepcyjnej):
# Zablokuj podstawowe tagi skryptów w tytule kopii zapasowej (dostosuj do swojej składni WAF)"
Wzorzec Nginx+Lua lub niestandardowy WAF (koncepcyjny):
-- pseudo-kod: sprawdź treść żądania pod kątem podejrzanych wzorców w polach nazwanych 'backup_title'
Ważne uwagi:
- Zachowaj zasady skierowane do punktów końcowych specyficznych dla wtyczek, aby uniknąć fałszywych pozytywów.
- Użyj progresywnego blokowania: najpierw rejestruj, potem wyzwanie (CAPTCHA), a następnie blokuj.
- Blokuj lub wyzywaj żądania, które zawierają niebezpieczne wzorce w formularzach skierowanych do administratora lub w parametrach, które powinny zawierać tylko tekst.
WP-Firewall może wdrożyć dostosowane wirtualne łatki na ten dokładny problem, aby zapobiec wykorzystaniu, aż do zastosowania aktualizacji wtyczek.
7 — Wzmacnianie i najlepsze praktyki (poza łatającymi)
Łatanie jest kluczowe, ale długoterminowe łagodzenie wymaga wzmocnienia środowiska:
- Zasada najmniejszego przywileju:
- Zmniejsz liczbę administratorów. Używaj szczegółowych ról (Redaktorzy, Autorzy), gdzie to możliwe.
- Unikaj dzielenia się kontami administratorów między użytkownikami.
- Uwierzytelnianie wieloskładnikowe:
- Wymuszaj MFA dla wszystkich kont administratorów i użytkowników o wysokich uprawnieniach.
- Silne hasła i rotacja:
- Wymuszaj polityki silnych haseł i rotuj dane uwierzytelniające po zdarzeniach wysokiego ryzyka.
- Audyty ról i uprawnień:
- Regularnie przeglądaj, kto ma możliwość instalacji/aktualizacji wtyczek i dostęp do interfejsów kopii zapasowych.
- Bezpieczny cykl życia wtyczek:
- Instaluj tylko wtyczki z zaufanych źródeł.
- Utrzymuj motywy i wtyczki w aktualności.
- Usuń nieużywane wtyczki i motywy; wycofaj osierocone wtyczki.
- Wzmocnienie systemu plików i PHP:
- Wyłącz edytowanie plików w Panelu (
define('DISALLOW_FILE_EDIT', true);). - Ogranicz uprawnienia do zapisu do niezbędnych katalogów.
- Wyłącz edytowanie plików w Panelu (
- Monitorowanie i logowanie:
- Skonsoliduj logi (wydarzenia administracyjne, serwer WWW, logi WAF) i monitoruj anomalne zachowania.
- Ustaw alerty dla nowych kont administratorów, instalacji wtyczek lub dużych zmian.
- Higiena bazy danych:
- Monitoruj i czyść tabele metadanych specyficznych dla wtyczek w poszukiwaniu podejrzanych pól.
- Bądź ostrożny w przypadku funkcji wtyczek, które akceptują dowolny HTML.
- Kopie zapasowe:
- Przechowuj kopie zapasowe w wersjach off-site i weryfikuj integralność kopii zapasowych.
- Rozważ uczynienie kopii zapasowych niemutowalnymi lub ograniczonymi, aby nie mogły być zmieniane przez atakującego.
- Polityki stagingowe i testowe:
- Testuj aktualizacje wtyczek w stagingu przed wdrożeniem na produkcję, ale rób to szybko, gdy opublikowana zostanie poprawka bezpieczeństwa.
8 — Lista kontrolna reakcji na incydent (jeśli podejrzewasz wykorzystanie)
- Izolować
- Wprowadź stronę w tryb konserwacji lub zablokuj zaporę, podczas gdy prowadzisz dochodzenie.
- Zachowaj dowody
- Zrób zrzuty serwera i zachowaj logi (serwer WWW, baza danych, WAF).
- Określenie zakresu
- Szukaj wszystkich wystąpień złośliwych ładunków w metadanych wtyczek, postach, opcjach, biografiach użytkowników i przesłanych plikach.
- Usuń tylne drzwi
- Szukaj nowych użytkowników administratorów, nieznanych motywów/wtyczek oraz zmodyfikowanych plików rdzenia. Usuń lub poddaj kwarantannie podejrzane zmiany.
- Przywróć lub napraw
- Jeśli dostępne są czyste kopie zapasowe sprzed incydentu, rozważ pełne przywrócenie.
- Ponownie zainstaluj rdzeń WordPressa, motywy i wtyczki z czystych źródeł, gdzie to możliwe.
- Obracanie sekretów
- Zresetuj wszystkie hasła kont administratorów, klucze API i wszelkie dane uwierzytelniające na poziomie serwera, które mogły być dostępne.
- Monitorowanie po incydencie
- Zwiększ monitoring, dodaj zaawansowane logowanie i alerty oraz przeprowadzaj powtarzane skany złośliwego oprogramowania.
- Analiza po incydencie
- Udokumentuj, jak doszło do naruszenia, wyciągnięte wnioski oraz kroki podjęte w celu zapobieżenia powtórzeniu.
9 — Zasady wykrywania i zapytania łowieckie (praktyczne)
Oto kilka praktycznych zapytań do bazy danych i logów — dostosuj je starannie do swojego środowiska. Zawsze wykonuj kopię zapasową i testuj zapytania w środowiskach staging przed uruchomieniem na produkcji.
Wyszukaj w bazie danych podejrzane tytuły kopii zapasowych (pojęcie SQL):
SELECT option_id, option_name, option_value;
Wyszukaj posty/metadane dla tagów skryptów (pojęcie):
SELECT ID, post_title, post_date;
Wzorce logów serwera WWW:
- POST do punktów końcowych wtyczek z ciałem żądania zawierającym “<script” lub “onerror”.
- Strony administracyjne dostępne z nietypowych adresów IP lub z wielu lokalizacji w krótkich oknach czasowych.
Dzienniki WAF:
- Żądania wyzwalające zasady dla tagów skryptów w polach ciała POST nazwanych
backup_title,parametr,nazwa.
10 — Dlaczego przechowywane XSS wymaga uwagi, nawet gdy wymaga dostępu administratora
Dwa powody:
- Wzmocnienie: Jedno skompromitowane konto administratora może być użyte do wstrzykiwania trwałych ładunków, które wpływają na wiele kont i utrzymują się przez aktualizacje/zmiany.
- Łączenie ataków w rzeczywistości: Napastnicy rzadko zatrzymują się na jednej podatności. Przechowywane XSS jest często wykorzystywane jako krok do pełnego przejęcia witryny — instalowanie tylnej furtki, tworzenie ukrytych użytkowników administratora lub rozprzestrzenianie się na inne witryny i użytkowników.
Traktuj przechowywane XSS w kontekście administracyjnym jako poważny wskaźnik możliwych wektorów kompromitacji i działaj szybko.
11 — Jak WP-Firewall cię chroni (i specjalne zaproszenie)
WP-Firewall zapewnia zarządzaną ochronę WAF, ciągłe skanowanie złośliwego oprogramowania i szybkie wirtualne łatanie, abyś mógł pozostać chroniony podczas łatania podatnych wtyczek. Nasza ochrona jest dostosowana do specyficznych tras i kontekstów WordPressa, minimalizując fałszywe alarmy i zapewniając, że procesy robocze administratora pozostają użyteczne podczas blokowania prób wykorzystania.
Oferujemy darmowy plan podstawowy, który obejmuje:
- Zarządzany firewall + WAF
- Nielimitowana przepustowość (bez dodatkowych opłat)
- Skaner złośliwego oprogramowania
- Łagodzenie 10 największych ryzyk OWASP
Jeśli chcesz przetestować naszą ochronę i zobaczyć, jak wirtualne łatanie może chronić Twoją stronę podczas planowania i testowania aktualizacji, zarejestruj się w naszym planie Podstawowym (Darmowym):
Chroń swoją stronę teraz — rozpocznij z WP-Firewall Basic
Zarejestruj się w WP-Firewall Basic (darmowe)
Dlaczego to jest ważne:
- Nasz WAF może pomóc zablokować próby wykorzystania zapisanych wzorców XSS w punktach końcowych dla administratorów.
- Podczas aktualizacji wtyczki, nasze wirtualne łaty pomagają zmniejszyć ryzyko lateralnego kompromisu i dają Ci przestrzeń na pełne kroki naprawcze.
(Oferujemy również ulepszone plany z automatycznym usuwaniem złośliwego oprogramowania, zaawansowanym czarnym/białym listowaniem adresów IP, miesięcznymi raportami bezpieczeństwa, automatycznym wirtualnym łataniem oraz dodatkami premium dla agencji i stron o dużym ruchu.)
12 — Lista kontrolna wdrożenia dla zespołów (praktyczna)
Dla operatorów bezpieczeństwa i właścicieli stron, oto krótki podręcznik do szybkiego przeglądu:
- Krok 1: Sprawdź wersję wtyczki. Jeśli <= 2.1.2 — zaplanuj natychmiastową aktualizację do 2.1.3.
- Krok 2: Jeśli potrzebne jest nocne wdrożenie, wdroż wirtualną łatę WP-Firewall, aby przechwycić potencjalne wzorce exploitów na punktach końcowych kopii zapasowych.
- Krok 3: Przejrzyj użytkowników administratorów — wyłącz nieaktualne lub nieużywane konta; włącz MFA.
- Krok 4: Przeskanuj bazę danych w poszukiwaniu podejrzanych tytułów kopii zapasowych i oczyść lub usuń je.
- Krok 5: Przeprowadź pełne skanowanie złośliwego oprogramowania na stronie i sprawdź znaczniki czasu zmiany/plików.
- Krok 6: Rotuj hasła administratora i klucze API, jeśli wykryto podejrzaną aktywność.
- Krok 7: Po usunięciu zagrożenia monitoruj przez co najmniej 30 dni w poszukiwaniu anomalii.
13 — FAQ (krótkie)
P: Czy krytyczne jest natychmiastowe zaktualizowanie?
O: Tak. Łatka jest prosta i zamyka lukę w sanitizacji danych. Zaktualizuj do 2.1.3 tak szybko, jak to możliwe.
P: Moja strona ma tylko jednego administratora i to ja — czy to nadal jest ryzykowne?
O: Tak. Jeśli Twoje konto administratora kiedykolwiek zostanie skompromitowane, przechowywany ładunek może być użyty do utrwalenia i rozszerzenia ataku. Również jeśli korzystasz z hostingu współdzielonego lub sesje administratora są dostępne dla innych, ryzyko wzrasta.
P: Co jeśli nie mogę zaktualizować z powodu problemów z kompatybilnością?
O: Użyj wirtualnej łatki (WAF) i ogranicz dostęp do interfejsu wtyczki według IP lub VPN. Traktuj to jako tymczasowe rozwiązanie i zaplanuj odpowiednią ścieżkę aktualizacji z testowaniem.
P: Czy powinienem usunąć wszystkie kopie zapasowe utworzone przez wtyczkę?
O: Nie usuwaj kopii zapasowych bezmyślnie. Eksportuj kopie zapasowe i sprawdź je. Jeśli metadane kopii zapasowej zawierają podejrzane ładunki w tytułach, usuń/wyczyść te wpisy. Preferuj przywracanie z zweryfikowanej czystej kopii zapasowej, jeśli podejrzewasz kompromitację.
14 — Myśli końcowe
Bezpieczeństwo w WordPressie jest warstwowe. Wrażliwości wtyczek, takie jak to przechowywane XSS, ujawniają, jak małe zaniedbania w sanitizacji mogą być wykorzystane w połączeniu z słabymi poświadczeniami, niewystarczającym monitorowaniem lub brakiem praktyk minimalnych uprawnień. Najszybszym i najbardziej niezawodnym sposobem łagodzenia jest zaktualizowanie dotkniętej wtyczki do wersji z łatką. Jeśli to nie jest możliwe natychmiast, wdroż WAF/wirtualną łatkę i natychmiast zaostrzyć polityki administracyjne.
Jeśli potrzebujesz profesjonalnej pomocy w wdrażaniu wirtualnych łatek i ciągłej ochrony dla swoich stron WordPress, WP-Firewall może chronić Twoje powierzchnie administracyjne, blokować podejrzane ładunki i monitorować próby wykorzystania — dając Ci czas i pewność na wdrożenie przetestowanych aktualizacji wtyczek.
Chroń swoje środowisko WordPress teraz — zaktualizuj do Keep Backup Daily v2.1.3 (lub nowszej), audytuj swoje konta administratorów i rozważ dodanie WAF/wirtualnych łatek do swojej strategii obrony w głębokości.
Jeśli potrzebujesz dostosowanej reakcji awaryjnej na aktywną kompromitację lub pomocy w wdrażaniu wirtualnych łatek WP-Firewall dla tej konkretnej wrażliwości, nasi inżynierowie ds. bezpieczeństwa są dostępni, aby pomóc. Zarejestruj się w naszym planie Podstawowym (Darmowym) i uzyskaj natychmiastową ochronę WAF: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Bądź bezpieczny,
Zespół ds. bezpieczeństwa WP-Firewall
