Krytyczny CSRF w wtyczce Restore Permanently Delete//Opublikowano 2025-08-22//CVE-2025-7839

ZESPÓŁ DS. BEZPIECZEŃSTWA WP-FIREWALL

Restore Permanently delete Post or Page Data Vulnerability

Nazwa wtyczki Przywróć Trwale usuń dane Postu lub Strony
Rodzaj podatności CSRF
Numer CVE CVE-2025-7839
Pilność Niski
Data publikacji CVE 2025-08-22
Adres URL źródła CVE-2025-7839

Pilne: CSRF w “Przywróć Trwale usuń dane Postu lub Strony” (<= 1.0) — Co właściciele stron WordPress muszą teraz zrobić

Opublikowany: 22 sierpnia 2025
CVE: CVE-2025-7839 — Waga: Niska (CVSS 4.3)
Typ podatności: Fałszywe żądanie między witrynami (CSRF) — A5: Uszkodzona kontrola dostępu

Jako praktyk bezpieczeństwa WordPress pracujący w zespole badawczym i ochrony WP-Firewall, piszę, aby wyjaśnić, co ta luka oznacza dla właścicieli stron, dlaczego ma znaczenie, nawet gdy waga jest “niska”, i jakie dokładnie kroki powinieneś podjąć dzisiaj, aby chronić swoje strony WordPress.

To ostrzeżenie syntetyzuje publicznie zgłoszone szczegóły dotyczące luki w wtyczce “Przywróć Trwale usuń dane Postu lub Strony” (wersje <= 1.0) i rozszerza to o praktyczne wskazówki dotyczące łagodzenia, wykrywania i zapobiegania. Pokażę również bezpieczne, nieeksploatacyjne przykłady kodu, które możesz wykorzystać do wzmocnienia swojej strony, oraz wyjaśnię, jak zarządzane wirtualne łatanie z WAF może natychmiast pomóc, gdy oficjalna poprawka nie jest dostępna.

Notatka: Wtyczka obecnie nie ma dostępnej oficjalnej wersji naprawionej.


Streszczenie wykonawcze (prosty język)

  • Co się stało: Błąd w wtyczce pozwala na inicjowanie żądań sieciowych, które przywracają lub trwale usuwają posty/strony bez odpowiedniej walidacji żądania.
  • Natychmiastowe ryzyko: Atakujący może spowodować wykonanie uprzywilejowanych działań, oszukując zalogowanego administratora, aby odwiedził złośliwą stronę (klasyczny CSRF) — lub, według raportów, wysyłając żądania, które są akceptowane bez odpowiednich kontroli uwierzytelnienia. Może to prowadzić do niepożądanych przywróceń lub trwałych usunięć treści.
  • Waga: Oceniona jako Niska (CVSS 4.3). Dlaczego niska? Ponieważ wpływ jest ograniczony w porównaniu do luk umożliwiających pełne przejęcie (wpływa na operacje związane z treścią, a nie na zdalne wykonywanie kodu). Ale “niska” nie oznacza “ignoruj” — utrata treści i zakłócenia w procesach redakcyjnych to realne zagrożenia.
  • Krótkoterminowe łagodzenie: Jeśli używasz tej wtyczki (<=1.0), natychmiast ją wyłącz lub zablokuj punkty końcowe administracyjne wtyczki za pomocą swojego zapory. Jeśli wolisz mniej zakłócające podejście, zastosuj zasady wirtualnego łatania na poziomie WAF lub dodaj defensywny kod, aby zweryfikować nonces i uprawnienia przed uruchomieniem operacji wtyczki.
  • Długoterminowo: Zainstaluj tylko naprawioną wersję wtyczki z zaufanego źródła. Dodaj monitorowanie, audyty ról i kopie zapasowe, aby zmniejszyć ryzyko utraty danych.

Jak działa luka (technicznie, nieeksploatacyjnie)

Fałszywe żądanie między witrynami (CSRF) występuje, gdy atakujący oszukuje przeglądarkę użytkownika, aby wysłała żądanie do docelowej witryny, w której użytkownik jest uwierzytelniony. W WordPressie typowe środki łagodzące to:

  • Nonces (wp_nonce_field(), wp_verify_nonce()), aby zapewnić, że żądanie pochodzi z legalnego formularza w interfejsie użytkownika.
  • Kontrole uprawnień (current_user_can()), aby upewnić się, że zalogowany użytkownik ma uprawnienia do wykonania danej akcji.
  • Uwierzytelnione punkty końcowe i kontrole w ścieżkach tylko dla administratorów.

Raporty wskazują, że operacje przywracania/trwałego usuwania wtyczki nie mają odpowiedniej walidacji żądania — w szczególności brakującej weryfikacji nonces i/lub uprawnień. Istnieją dwa odpowiednie tryby awarii:

  1. Wtyczka udostępnia akcję administracyjną, która może być wywołana, gdy zalogowany jest prawidłowy administrator, ale akcja nie ma ważnego sprawdzenia nonce. Atakujący może stworzyć stronę, która, gdy zostanie odwiedzona przez tego administratora, zmusza jego przeglądarkę do wysłania złośliwego żądania (klasyczny CSRF).
  2. Co gorsza, punkt końcowy wtyczki może nie wymagać uwierzytelnienia ani odpowiednich sprawdzeń uprawnień — co oznacza, że nieautoryzowany podmiot mógłby wysyłać żądania bezpośrednio, a wtyczka wykonuje akcję. Jeśli tak jest, problem zmienia się z CSRF na złamanie kontroli dostępu (akcje wykonujące operacje uprzywilejowane bez uwierzytelnienia).

Każdy tryb awarii pozwala na niepożądane operacje na poziomie treści (przywracanie lub trwałe usuwanie), które mogą prowadzić do utraty treści lub zakłócenia przepływu pracy.


Kto jest dotknięty?

  • Strony korzystające z wtyczki “Przywróć Trwale usuń dane Posta lub Strony” w wersji 1.0 lub wcześniejszej.
  • Administratorzy, redaktorzy lub jakakolwiek uprzywilejowana rola, której przeglądarka mogłaby zostać oszukana do wydawania żądań (w scenariuszach CSRF).
  • Potencjalnie wszystkie instalacje WordPressa z zainstalowaną podatną wtyczką, w tym sieci multisite.

Jeśli w ogóle nie używasz wtyczki, nie jesteś dotknięty. Jeśli używasz wtyczki, traktuj to jako wysoką priorytet do przeglądu i złagodzenia.


Praktyczne natychmiastowe działania (krok po kroku)

Jeśli zarządzasz stronami WordPress, wykonaj teraz te priorytetowe działania. Zaczynam od najszybszych sposobów na zmniejszenie ryzyka, a następnie podaj opcje bezpieczniejsze, ale nieco bardziej złożone w łagodzeniu.

  1. Inwentaryzacja i identyfikacja
    • Sprawdź każdą stronę, którą zarządzasz pod kątem wtyczki:
      • WordPress admin: Wtyczki → Zainstalowane wtyczki
      • CLI: wp lista wtyczek | grep -i "przywróć"
    • Zwróć uwagę na wersję. Wersje <= 1.0 są zgłaszane jako podatne.
  2. Szybkie zatrzymanie: Wyłącz wtyczkę (zalecane, jeśli możesz)
    • Panel → Wtyczki → Dezaktywuj wtyczkę.
    • CLI: wp dezaktywuj
    • Uzasadnienie: natychmiastowe usunięcie podatnego kodu z ścieżki żądania całkowicie eliminuje ryzyko.
  3. Jeśli nie możesz wyłączyć wtyczki (ograniczenia biznesowe), zastosuj jedną z tych tymczasowych ochron:
    • Użyj swojego zapory, aby zablokować bezpośredni dostęp do punktów końcowych administracyjnych wtyczki.
      • Zablokuj żądania POST do adresu URL lub punktów końcowych administratora wtyczki (jeśli możesz je zidentyfikować).
      • Ogranicz dostęp do /wp-admin/admin-post.php z filtrowaniem, które wymaga ważnych ciasteczek WordPress lub refererów niebędących administratorem.
    • Wdrożenie reguły WAF, która odrzuca żądania próbujące wykonać operacje “przywrócenie” lub “trwałe usunięcie”, chyba że obecny jest ważny nonce. Klienci WP-Firewall mogą skorzystać z wirtualnego łatania w tym przypadku.
    • Ogranicz dostęp administratora według IP: ogranicz /wp-admin i strony wtyczek do biurowych adresów IP, gdy to możliwe.
  4. Wdrożenie krótkoterminowego wzmocnienia kodu (jeśli czujesz się komfortowo)
    • Wstaw defensywny hak w funkcje.php lub małą wtyczkę mu, która sprawdza przychodzące żądania i odrzuca nieautoryzowane próby. Zobacz przykładowy kod poniżej.
  5. Potwierdź i przywróć kopie zapasowe
    • Zweryfikuj, czy istnieją niedawne kopie zapasowe i czy można je przywrócić. Natychmiast utwórz nową kopię zapasową.
    • Jeśli wykryjesz nieautoryzowane usunięcia, przywróć z kopii zapasowej w razie potrzeby.
  6. Monitoruj aktywność
    • Przejrzyj znaczniki czasowe edycji/przywracania/usuwania w wp_posts oraz w dziennikach aktywności.
    • Włącz lub przeglądaj dzienniki audytu WordPress, aby zobaczyć, kto wykonał działania i kiedy.
  7. Zaktualizuj lub usuń na stałe, gdy zostanie naprawione
    • Gdy zostanie wydana bezpieczna aktualizacja wtyczki, zweryfikuj poprawkę przed aktualizacją. Jeśli wtyczka nie jest już utrzymywana, usuń ją na stałe.

Defensywny fragment kodu (bezpieczny przykład)

Poniżej znajduje się defensywny przykład kodu, który możesz dodać jako specyficzną dla witryny wtyczkę mu (zalecane) lub do swojego motywu funkcje.php tymczasowo. To zapobiega POST-om, które próbują wykonać operacje przywracania postów/trwałego usunięcia, chyba że obecne są ważne nonce i sprawdzenie uprawnień.

Notatka: To jest ogólna obrona. Musisz dostosować nazwy akcji i parametry żądania do implementacji wtyczki. Jeśli nie czujesz się komfortowo edytując PHP, poproś dewelopera lub użyj WAF.

<?php
/*
Plugin Name: Temporary CSRF Defense for Restore/Delete Actions
Description: Intercepts requests that attempt to restore or permanently delete posts and validates WP nonces and capabilities.
Version: 1.0
Author: WP-Firewall Security Team
*/

add_action('init', function() {
    // We only inspect POST requests
    if ( 'POST' !== $_SERVER['REQUEST_METHOD'] ) {
        return;
    }

    // Identify plugin-specific parameters that indicate a restore/permanent-delete action.
    // You must update these keys to match the plugin's form fields or action names.
    $suspicious = false;
    $keys = array('restore_post_id', 'permanent_delete_post_id', 'action');

    foreach ($keys as $k) {
        if (!empty($_REQUEST[$k])) {
            $suspicious = true;
            break;
        }
    }

    if (!$suspicious) {
        return;
    }

    // 1) Require WP nonce
    $nonce_valid = false;
    if (!empty($_REQUEST['_wpnonce']) && wp_verify_nonce($_REQUEST['_wpnonce'], 'wp-restor-delete-action')) {
        $nonce_valid = true;
    }

    // 2) Require current user capability (admins or editors)
    $cap_ok = current_user_can('edit_others_posts') || current_user_can('publish_posts');

    // 3) Optionally verify referer header to make it harder to CSRF (not foolproof)
    $referer_ok = true;
    if (empty($_SERVER['HTTP_REFERER']) || parse_url($_SERVER['HTTP_REFERER'], PHP_URL_HOST) !== $_SERVER['HTTP_HOST']) {
        $referer_ok = false;
    }

    // If any of the checks fail, block the request.
    if (!($nonce_valid && $cap_ok && $referer_ok)) {
        status_header(403);
        wp_die('Unauthorized request blocked.');
    }
}, 1);

Jak używać:

  • Zapisz jako plik o nazwie mu-csrf-defender.php i umieść go w wp-content/mu-plugins/ (stwórz katalog, jeśli to konieczne).
  • Dostosuj klucze aby dopasować do parametrów wtyczki; jeśli ich nie znasz, włącz zamiast tego defensywną warstwę WAF.
  • To jest tymczasowe. Zastąp rozwiązaniem natywnym wtyczki, gdy będzie dostępne.

Dlaczego WAF / wirtualna łatka pomaga natychmiast

Gdy wtyczka nie ma oficjalnej łatki, najbezpieczniejszą opcją jest często jej usunięcie. Ale strony z ograniczeniami biznesowymi czasami nie mogą natychmiast usunąć funkcjonalności. W tym miejscu wkracza zapora aplikacji internetowej (WAF) i wirtualne łatanie:

  • Blokuj znane złośliwe wzorce żądań na krawędzi — zanim dotrą do WordPressa.
  • Egzekwuj obecność oczekiwanych nonce i nagłówków w żądaniach dotyczących wrażliwych działań.
  • Ograniczaj lub blokuj podejrzane adresy IP próbujące wywołać punkty końcowe usuwania/przywracania.
  • Zapewnij szybkie łagodzenie, nawet gdy autorzy wtyczek nie wydali poprawionej wersji.

W WP-Firewall wdrażamy ukierunkowane zasady, które:

  • Sprawdzają żądania POST pod kątem brakujących nonce dla znanych nazw działań.
  • Blokują żądania pochodzące z zewnętrznych stron (brak hosta referera) próbujące wykonywać działania administracyjne.
  • Włącz normalny ruch administracyjny, aby uniknąć wpływu na edytorów i przepływy pracy z treściami.

Wirtualne łatanie nie jest zastępstwem dla oficjalnej poprawki wtyczki, ale dramatycznie zmniejsza powierzchnię ataku, podczas gdy wtyczka jest aktualizowana lub usuwana.


Wykrywanie, czy Twoja strona była celem lub została wykorzystana

Jeśli uruchomisz podatny plugin, sprawdź następujące artefakty, aby wykryć podejrzaną aktywność. Te kontrole pomagają określić, czy jakiekolwiek treści zostały złośliwie przywrócone lub trwale usunięte.

  1. Dzienniki audytu (najlepsze źródło)
    • Jeśli masz włączony plugin/usługę audytu, szukaj zdarzeń przywracania postów i trwałego usuwania, w tym adresów IP i znaczników czasu.
  2. Kontrola bazy danych
    • Zapytanie wp_posts o ostatnie zmiany:
      • Szukaj postów, które post_status zmieniły się z kosza Do opublikowane (przywrócenia).
      • Szukaj niespodziewanych post_status of auto-szkicu lub rekordów brakujących tam, gdzie wcześniej istniały (usunięcia).
    • Przykład SQL do znalezienia przywróceń (dostosuj znaczniki czasu w razie potrzeby):
      SELECT * FROM wp_posts WHERE post_modified >= '2025-08-15' ORDER BY post_modified DESC;
  3. Logi dostępu do serwera
    • Przejrzyj dzienniki serwera WWW w poszukiwaniu żądań POST do:
      • admin-post.php
      • wp-admin/admin-ajax.php
      • Własnych punktów końcowych pluginu (sprawdź slug pluginu w systemie plików, aby zidentyfikować punkty końcowe plików).
    • Szukaj żądań z nietypowymi parametrami POST lub z nieznanych adresów IP.
  4. Media i załączniki
    • Sprawdź wp_postmeta I wp_posts wpisy dla załączników. Trwałe usunięcie załączników może sygnalizować destrukcyjne operacje.
  5. Kopie zapasowe i migawki
    • Porównaj ostatnie kopie zapasowe z aktywną stroną. Jeśli brakuje treści, może być konieczne przywrócenie.
  6. Wskaźniki kompromitacji
    • Nagłe zmiany autorów, masowe tworzenie/usuwanie treści lub zmiany w zaplanowanych postach to czerwone flagi.

Jeśli wykryjesz eksploatację, postępuj zgodnie z krokami reakcji na incydent: izoluj witrynę, zachowaj logi, przywróć czysty backup, zmień dane logowania administratora i wzmocnij dostęp.


Długoterminowe wzmocnienie (najlepsze praktyki)

Te środki zmniejszają wpływ luk wtyczek w całej flocie WordPress.

  • Zasada najmniejszego przywileju:
    • Ogranicz role administracyjne. Używaj Edytora lub Autora do codziennych przepływów treści.
    • Przejrzyj wszystkich użytkowników i usuń nieużywane konta administratorów.
  • Uwierzytelnianie dwuskładnikowe:
    • Wymuszaj 2FA dla wszystkich kont z podwyższonymi uprawnieniami.
  • Wymuś nonce i kontrole możliwości:
    • Autorzy wtyczek muszą zawsze używać pole_nonce() w formularzach i weryfikuj z wp_verify_nonce(). Muszą zawsze sprawdzać bieżący_użytkownik_może() przed wykonywaniem uprzywilejowanych działań.
  • Automatyczne kopie zapasowe i testowe przywracanie:
    • Regularne automatyczne kopie zapasowe z weryfikowanymi procedurami przywracania zmniejszają szkody spowodowane usunięciami.
  • Rejestrowanie i monitorowanie na poziomie aplikacji:
    • Utrzymuj logi audytowe dla operacji związanych z treścią i monitoruj nieprawidłowe skoki w usunięciach lub przywracaniach.
  • Bezpieczne środowisko staging/testing:
    • Testuj aktualizacje wtyczek i poprawki zabezpieczeń na stagingu przed wdrożeniem produkcyjnym.
  • Zarządzanie cyklem życia wtyczek:
    • Usuń przestarzałe lub nieutrzymywane wtyczki. Preferuj wtyczki z silnymi rekordami utrzymania i programem odpowiedzialnego ujawniania.
  • WAF i wirtualne łatanie:
    • Wdróż WAF, aby zablokować znane wzorce ataków i stosuj wirtualne poprawki, gdy poprawki dostawcy są niedostępne.

Zalecana lista kontrolna napraw (szybkie odniesienie)

  • ☐ Zidentyfikuj wszystkie przypadki podatnego wtyczki (<= 1.0).
  • ☐ Natychmiast dezaktywuj wtyczkę, jeśli to możliwe.
  • ☐ Jeśli to niemożliwe, włącz zasady WAF, aby zablokować działania przywracania/usuwania lub zastosuj defensywny fragment mu-wtyczki.
  • ☐ Upewnij się, że masz świeżą kopię zapasową; zrób ją teraz.
  • ☐ Przejrzyj dzienniki audytowe i dzienniki serwera w poszukiwaniu podejrzanej aktywności.
  • ☐ Zmień hasła administratora i wprowadź 2FA.
  • ☐ Monitoruj wersję wtyczki; zweryfikuj poprawkę i zaktualizuj.
  • ☐ Jeśli wykryto intensywną aktywność lub utratę danych: izoluj stronę, zachowaj dzienniki, przywróć z kopii zapasowej i postępuj zgodnie z procedurą reagowania na incydenty.

Przykładowy scenariusz (jak może wyglądać atak — na wysokim poziomie)

Napastnik tworzy stronę internetową zawierającą ukryty formularz lub obrazek SRC, który wywołuje POST do punktu końcowego podatnej wtyczki. Jeśli administrator odwiedza tę stronę, będąc zalogowanym na swojej stronie WordPress, przeglądarka automatycznie wysyła ciasteczka z żądaniem. Ponieważ wtyczka nie weryfikuje nonce ani nie sprawdza odpowiednio uprawnień użytkownika, serwer akceptuje żądanie i na stałe usuwa konkretne posty. Celem napastnika jest sabotaż treści, zakłócenie harmonogramów redakcyjnych lub stworzenie mylącego stanu, który prowadzi do większego kompromisu.

Jeśli punkt końcowy wtyczki jest dostępny bez uwierzytelnienia, napastnik może wywołać akcję bezpośrednio z własnego systemu, skalując ataki na wiele stron korzystających z wtyczki.


Jak my w WP-Firewall chronimy klientów (krótko)

W WP-Firewall nasze podejście do tego typu problemów obejmuje:

  • Natychmiastowe wdrożenie zasad wirtualnego łatania, które wykrywają i blokują wzorce żądań związane z podatną wtyczką (POST-y bez ważnych nonce lub żądania, które pasują do parametrów przywracania/trwałego usuwania).
  • Analiza ruchu w celu zidentyfikowania podejrzanej aktywności i zablokowania złośliwych adresów IP oraz agentów użytkownika wykonujących zautomatyzowane eksploatacje.
  • Wskazówki i kroki naprawcze dla właścicieli stron, plus monitorowanie, aby upewnić się, że środki zaradcze nie blokują normalnych procesów redakcyjnych.
  • Skoordynowane procesy ujawniania i komunikacji z utrzymującymi wtyczki, gdy to możliwe.

Jeśli się martwisz i chcesz szybkiej, nieinwazyjnej warstwy, która chroni podczas wdrażania poprawek na poziomie strony, rozważ plan zarządzanego zapory (szczegóły poniżej).


Nowość: Zabezpiecz swoją stronę za pomocą darmowego planu WP-Firewall — zaproszenie

Tytuł: Niezbędna ochrona dla każdej strony WordPress — zacznij od darmowego planu

Każda strona internetowa zasługuje na podstawowy poziom bezpieczeństwa. Jeśli chcesz szybko zmniejszyć narażenie na to i inne ryzyka związane z wtyczkami, plan podstawowy WP-Firewall (darmowy) zapewnia niezbędne zabezpieczenia bez kosztów: w pełni zarządzany zapora, nielimitowana przepustowość, zapora aplikacji internetowej (WAF), która blokuje powszechne wzorce eksploatacji, skaner złośliwego oprogramowania oraz łagodzenie zagrożeń z OWASP Top 10. Możesz zarejestrować się i uzyskać natychmiastową ochronę tutaj: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Jeśli potrzebujesz więcej zautomatyzowanej naprawy, nasze płatne plany dodają automatyczne usuwanie złośliwego oprogramowania, czarną/białą listę adresów IP, miesięczne raporty bezpieczeństwa oraz wirtualne łatanie, dzięki czemu jesteś chroniony nawet przed aktualizacją wtyczek. Rozpoczęcie od planu darmowego to prosty krok, który natychmiast zmniejsza twoje narażenie.


Często zadawane pytania

P: Wrażliwość jest oceniana jako “Niska”. Czy powinienem się tym przejmować?
O: Tak. “Niska” oznacza standardowe metryki oceny, ale nie wpływ na biznes. Jeśli polegasz na swojej treści, usunięcie lub niechciane przywrócenia są zakłócające i mogą mieć konsekwencje dla reputacji lub przychodów.

P: Czy istnieje oficjalna poprawka?
O: Na dzień wydania tego komunikatu nie ma dostępnej oficjalnej wersji wtyczki z poprawką. Dlatego tymczasowe łagodzenie (wyłączenie, WAF, fragment kodu) jest kluczowe.

P: Czy wyłączenie wtyczki zepsuje moją stronę?
O: To zależy od tego, jak twoja strona korzysta z wtyczki. Dezaktywacja może usunąć funkcję wygody, ale jest bezpieczniejsza niż uruchamianie podatnego kodu. Najpierw utwórz kopię zapasową strony.

P: Nie mam WAF. Czy mogę nadal chronić swoją stronę?
O: Tak — najszybsze opcje to: wyłączenie wtyczki, dodanie defensywnego fragmentu jako mu-wtyczki, ograniczenie dostępu administratora według adresu IP oraz zapewnienie, że kopie zapasowe i monitorowanie są w miejscu.

P: Czy logi mogą udowodnić, czy atakujący wykorzystał to?
O: Logi i ścieżki audytu pokażą podejrzany ruch POST i zmiany w wp_posts. Jednak brak dowodów nie jest dowodem na brak. Najpierw wzmocnij, potem prowadź dochodzenie.


Ostateczne myśli i zalecane priorytety

  1. Jeśli używasz wtyczki (<=1.0): wyłącz ją teraz, jeśli możesz. Jeśli nie możesz, natychmiast zastosuj regułę WAF lub defensywny fragment powyżej.
  2. Potwierdź, że kopie zapasowe i monitorowanie działają. Kopie zapasowe są często najszybszą metodą odzyskiwania.
  3. Wprowadź minimalizację ról i 2FA dla kont administratorów.
  4. Wdróż zarządzaną zaporę lub wirtualne łatanie, jeśli potrzebujesz ochrony przed dostępnością poprawki wtyczki.

Jeśli potrzebujesz pomocy w wdrażaniu jakichkolwiek łagodzeń (reguły WAF, wirtualne łatanie, wdrożenie defensywnej mu-wtyczki), zespół WP-Firewall może pomóc. Możemy przeprowadzić szybką ocenę narażenia i zalecić odpowiedni plan łagodzenia.

Bądź bezpieczny — i nie pozwól, aby “niska” powaga uśpiła twoją czujność. Treść ma znaczenie, a zapobieganie uniknionym stratom jest kluczową częścią dobrej higieny WordPressa.

— Zespół bezpieczeństwa WP-Firewall

(Jeśli chcesz uzyskać darmową warstwę bezpieczeństwa zalecaną powyżej — zarządzana zapora, nielimitowana przepustowość, WAF, skaner złośliwego oprogramowania i łagodzenie OWASP Top 10 — zarejestruj się tutaj: https://my.wp-firewall.com/buy/wp-firewall-free-plan/)


wordpress security update banner

Otrzymaj WP Security Weekly za darmo 👋
Zarejestruj się teraz
!!

Zarejestruj się, aby co tydzień otrzymywać na skrzynkę pocztową aktualizacje zabezpieczeń WordPressa.

Nie spamujemy! Przeczytaj nasze Polityka prywatności Więcej informacji znajdziesz tutaj.