Krytyczne XSS w Better Find and Replace//Opublikowano 2026-04-16//CVE-2026-3369

Nazwa wtyczki	Lepsze znajdowanie i zamienianie
Rodzaj podatności	Atak typu cross-site scripting (XSS)
Numer CVE	CVE-2026-3369
Pilność	Niski
Data publikacji CVE	2026-04-16
Adres URL źródła	CVE-2026-3369

Streszczenie

W dniu 16 kwietnia 2026 roku ujawniono przechowywaną podatność na Cross‑Site Scripting (XSS) wpływającą na wtyczkę WordPress “Lepsze znajdowanie i zamienianie — sugestie zasilane AI” (znaną również jako Real Time Auto Find and Replace) (CVE‑2026‑3369). Problem dotyczy wersji do 1.7.9 włącznie i został naprawiony w wersji 1.8.0.

Kluczowe fakty:

• Typ luki: Przechowywane XSS (trwałe)
• Dotknięte wersje: <= 1.7.9
• Poprawiono w: 1.8.0
• CVE: CVE‑2026‑3369
• Wymagane uprawnienia do rozpoczęcia: Autor
• Wykorzystanie wymaga interakcji użytkownika z uprzywilejowanymi kontami (zaufany użytkownik musi zobaczyć złośliwą treść)
• Zgłoszone CVSS: 5.9 (średni/niski wskaźnik wpływu w kontekście WordPressa)

Ten wpis na blogu wyjaśnia, czym jest ta podatność, dlaczego jest ważna, jakie natychmiastowe kroki należy podjąć (w tym krótkoterminowe łagodzenia), jak WP‑Firewall cię chroni (w tym wirtualne łatanie) oraz zalecane długoterminowe zmiany dla autorów wtyczek, właścicieli stron i zespołów hostingowych.

---

Dlaczego przechowywane XSS w wtyczce ma znaczenie (nawet gdy wymagane uprawnienia to “Autor”)

Cross‑Site Scripting jest jedną z najczęstszych podatności w sieci. Przechowywane (trwałe) XSS występuje, gdy dane dostarczone przez użytkownika są przechowywane przez aplikację i później renderowane na stronie bez odpowiedniej sanitizacji/escapingu. Ponieważ ładunek jest przechowywany, może wpływać na każdego użytkownika, który przegląda dotkniętą stronę lub interfejs użytkownika.

Na pierwszy rzut oka ten konkretny przypadek może wydawać się niskiego ryzyka, ponieważ:

• Podatność wymaga uwierzytelnionego użytkownika z co najmniej uprawnieniami Autora do dostarczenia złośliwego ładunku (w tym przypadku za pomocą tytułu przesłanego obrazu).
• Wykorzystanie wymaga uprzywilejowanego użytkownika (Administratora, Redaktora lub innego Autora) do interakcji z przygotowaną treścią (na przykład przeglądania interfejsu zarządzania wtyczką, gdzie tytuł obrazu jest wyświetlany bez escapingu).

Pomimo tych ograniczeń, przechowywane XSS w obszarach administracyjnych ma znaczenie:

• Konteksty administracyjne często mają podwyższone uprawnienia i dostępne operacje (edycja postów, opcje wtyczek/motywów, zarządzanie mediami).
• Skrypty wykonujące się w uwierzytelnionym kontekście administracyjnym mogą wykonywać działania w imieniu administratora (działania w stylu CSRF, wywołania API, zmiana ustawień), co potencjalnie prowadzi do eskalacji uprawnień lub przejęcia strony.
• Atakujący dostarczający ładunki jako Autor mogą pozostać uśpieni, aż wartościowy cel wejdzie w interakcję z treścią, co utrudnia wykrycie i przypisanie.

Zalecana reakcja to natychmiastowe łatanie, połączone z krótkoterminowym wzmocnieniem i monitorowaniem.

---

Zrozumienie tej podatności: co się dzieje technicznie

Opis na wysokim poziomie:

• Wtyczka akceptowała przesłany obraz i przechowywała tytuł obrazu (attachment post_title) bez usuwania lub uciekania niebezpiecznych znaków. Gdy ten tytuł był później renderowany w interfejsie wtyczki, był wyświetlany w kontekście, który pozwalał na wykonanie HTML/JavaScript.
• Użytkownik z uprawnieniami autora może przesłać plik i ustawić tytuł załącznika. Jeśli wstawi HTML/JS do tytułu, a użytkownik z uprawnieniami później załadował stronę, na której wtyczka wyświetla ten tytuł bez uciekania, wstrzyknięty skrypt działa w sesji przeglądarki użytkownika z uprawnieniami.

Dlaczego ten wzór jest ryzykowny:

1. Dane wejściowe są przechowywane (metadane załącznika) i nie są oczyszczane.
2. Wyjście nie jest ucieczone dla kontekstu HTML, w którym jest wyświetlane.
3. Interfejs wtyczki prawdopodobnie działa w wp-admin, obszarze o wysokich uprawnieniach.

Połączenie (przechowywanie + niebezpieczne wyjście) to klasyczny przepis na XSS przechowywane.

Notatka: Unikamy podawania dowodów koncepcji tutaj. Jeśli jesteś odpowiedzialny za bezpieczeństwo witryny, traktuj wszelkie XSS przechowywane w interfejsie administracyjnym jako poważny problem i postępuj zgodnie z poniższymi krokami naprawczymi.

---

Realistyczne scenariusze ataków

• Autor przesyła pozornie nieszkodliwy obraz z przygotowanym tytułem. Administrator później przegląda interfejs “zamień” wtyczki lub listę mediów, gdzie tytuł jest wyświetlany, co uruchamia przechowany skrypt. Skrypt wykonuje się w kontekście administratora, umożliwiając działania dostępne dla administratora (np. tworzenie postów, modyfikowanie opcji za pomocą punktów końcowych AJAX administratora, tworzenie nowych użytkowników administratora, jeśli interfejs wtyczki ujawnia te przepływy, lub ładowanie dalszych ładunków, które próbują skompromitować witrynę).
• Atakujący, który może rejestrować konta autorów (poprzez otwarte rejestracje, skompromitowane konta lub ataki na łańcuch dostaw), może umieścić wiele ładunków i czekać, aż właściciel witryny lub użytkownik redakcyjny o wysokiej wartości je uruchomi.
• W połączeniu z słabymi hasłami, brakiem MFA i nie monitorowanymi sesjami administratora, udany XSS może być wykorzystany do instalacji tylnej furtki, wykradania danych lub utrzymywania dalszego dostępu.

---

Natychmiastowe działania dla właścicieli stron i administratorów

Jeśli używasz WordPressa i wtyczki Better Find and Replace:

1. Zaktualizuj wtyczkę natychmiast do wersji 1.8.0 lub nowszej.
   • Aktualizacja jest najskuteczniejszym środkiem zaradczym.
   • Jeśli zarządzasz wieloma witrynami, priorytetowo traktuj witryny z wieloma autorami, redaktorami lub administratorami.
2. Jeśli nie możesz natychmiast zaktualizować, zastosuj tymczasowe środki zaradcze:
   • Ogranicz lub usuń możliwość przesyłania mediów dla nieufnych ról (autorzy). Ogranicz zdolność ‘upload_files’ do ról, którym ufasz.
   • Ręcznie audytuj ostatnie przesyłki: szukaj ostatnich załączników z nietypowymi tytułami zawierającymi nawiasy kątowe, fragmenty skryptów, encje HTML lub znaki nie drukowalne.
   • Tymczasowo ogranicz dostęp do stron interfejsu wtyczki (np. poprzez ograniczenia IP serwera lub ustawienia wtyczki), aż będziesz mógł załatać.
   • Edukuj autorów: poproś ich, aby nie przesyłali plików zewnętrznych, dopóki witryna nie zostanie załatana, i aby powstrzymali się od klikania w nieznane linki.
3. Sprawdź aktywne sesje i unieważnij podejrzane sesje:
   • Wymuś wylogowanie wszystkich użytkowników, jeśli podejrzewasz naruszenie, i wymagaj resetowania haseł dla użytkowników z podwyższonymi rolami.
4. Wykonaj szybkie skanowanie:
   • Uruchom skaner złośliwego oprogramowania na swojej stronie (jeśli go masz) i sprawdź oznaki naruszenia: nowych użytkowników, nowe wtyczki, zmodyfikowane pliki rdzenia/wtyczek/motywów, podejrzane zaplanowane zadania i nieznane posty administratorów.
5. Zwiększ monitoring:
   • Włącz i zachowaj szczegółowe dzienniki dostępu oraz dzienniki działań administratorów przez co najmniej 30 dni.
   • Obserwuj nieoczekiwane wychodzące połączenia, skoki w działaniach administratorów lub zmiany w plikach wtyczek/motywów.

---

Krótkie środki zaradcze, które możesz wdrożyć teraz (bezpieczna sanitizacja podczas dodawania mediów)

Jeśli nie możesz natychmiast zaktualizować wtyczki (na przykład na stronie produkcyjnej z rygorystycznymi oknami zmian), praktycznym krokiem krótkoterminowym jest sanitizacja tytułów załączników podczas przesyłania i usunięcie tagów z istniejących tytułów załączników.

Możesz dodać mały fragment kodu do swojej strony (za pomocą wtyczki must-use lub wtyczki specyficznej dla strony), który będzie sanitizować tytuły załączników podczas przesyłania. To sanitizuje metadane tekstowe, a nie zmienia nazwy plików.

Przykład (koncepcyjny) fragmentu — sanitizacja tytułów załączników podczas dodawania i aktualizacji:

<?php
// mu-plugin/wpfirewall-sanitize-attachment-title.php
add_action('add_attachment', 'wpfirewall_sanitize_attachment_title');
add_action('edit_attachment', 'wpfirewall_sanitize_attachment_title');

function wpfirewall_sanitize_attachment_title($attachment_id) {
    $post = get_post($attachment_id);
    if (!$post) {
        return;
    }

    // Sanitize the post_title and post_excerpt (caption)
    $sanitized_title = sanitize_text_field(wp_strip_all_tags($post->post_title));
    $sanitized_excerpt = sanitize_text_field(wp_strip_all_tags($post->post_excerpt));

    $updated = false;
    $args = array('ID' => $attachment_id);
    if ($post->post_title !== $sanitized_title) {
        $args['post_title'] = $sanitized_title;
        $updated = true;
    }
    if ($post->post_excerpt !== $sanitized_excerpt) {
        $args['post_excerpt'] = $sanitized_excerpt;
        $updated = true;
    }
    if ($updated) {
        wp_update_post($args);
    }
}

Uwagi:

• Uruchom to tylko, jeśli nie możesz zaktualizować wtyczki. Poprawnym rozwiązaniem jest, aby wtyczka przestała generować nieescapowaną zawartość; poprawka wtyczki jest lepsza.
• Po wdrożeniu fragmentu, zeskanuj istniejące załączniki i zsanityzuj wszelkie podejrzane tytuły (możesz uruchomić jednorazowy skrypt, aby przejść przez załączniki i zaktualizować tytuły w podobny sposób).

---

Jak zapora aplikacji internetowej (WAF) / wirtualna łatka pomaga

WAF lub wirtualna łatka mogą zapewnić skuteczną ochronę krótkoterminową, szczególnie dla stron, które nie mogą być natychmiast zaktualizowane. WP-Firewall zapewnia warstwową ochronę, która może być stosowana podczas planowania trwałych poprawek.

Praktyczne środki WAF/wirtualnej łatki dla tego problemu:

• Sprawdź przychodzące przesyłki multipart/form-data i odrzucaj lub neutralizuj wszelkie pola formularzy ‘title’ lub ‘caption’ zawierające tagi skryptów lub podejrzane znaki HTML (np. “<script”, “<svg on*”, “onerror”).
• Zastosuj regułę transformacji: usuń tagi HTML z pól tekstowych, które nie wymagają HTML podczas przesyłania, zamiast blokować legalne przesyłki.
• Blokuj znane złośliwe wzorce ładunków lub żądania pochodzące z nieznanych źródeł podczas przesyłania mediów.
• Zapobiegaj lub oznaczaj wszelkie żądania administratorów, które zawierają nieoczekiwany HTML w polach metadanych.

Ważny: Wirtualne łatanie powinno być stosowane jako tymczasowe rozwiązanie podczas aktualizacji wtyczki. Nie jest to zamiennik dla naprawy podatnego kodu.

---

Zalecane trwałe poprawki dla autorów wtyczek i deweloperów

Deweloperzy wtyczek powinni przestrzegać najlepszych praktyk w zakresie bezpiecznego rozwoju, aby uniknąć problemów związanych z wejściem/wyjściem:

1. Oczyść dane wejściowe i escape'uj dane wyjściowe:
   • Oczyść dane na wejściu, gdzie to odpowiednie (np. użyj sanitize_text_field dla zwykłego tekstu).
   • Zawsze stosuj escapowanie na wyjściu w kontekście, w którym dane są renderowane:
     • esc_html() dla treści ciała HTML
     • esc_attr() dla wartości atrybutów
     • wp_kses(), jeśli celowo zezwalasz na ograniczony zestaw HTML
2. Zasada najmniejszych uprawnień i kontrole możliwości:
   • Weryfikuj możliwości użytkownika przed przetwarzaniem przesyłek lub zapisywaniem metadanych.
   • Używaj nonce'ów dla działań administracyjnych i sprawdzaj je.
3. Waliduj i normalizuj dane przed zapisaniem:
   • Usuń lub znormalizuj nieoczekiwane znaki z tytułów i podpisów.
   • Używaj bezpiecznych domyślnych ustawień (np. traktuj tytuł jako zwykły tekst, chyba że wyraźnie zezwolono).
4. Używaj interfejsów API WordPressa poprawnie:
   • Podczas renderowania tytułów mediów w interfejsie administracyjnym, używaj funkcji, które domyślnie escapują wyjście, lub owiń je w esc_html() / esc_attr().
5. Dodaj testy jednostkowe i integracyjne dla przypadków brzegowych:
   • Uwzględnij testy, które próbują wstrzyknąć HTML/JS do wszystkich pól metadanych i upewnij się, że wyjścia są bezpieczne.
6. Przegląd bezpieczeństwa w procesie wydania:
   • Uwzględnij listę kontrolną bezpieczeństwa dla wszystkich wydań i najlepiej krótki krok SAST/skanowania.

---

Dla dostawców hostingu i zarządzanych zespołów WordPress

Dostawcy hostingu i zarządzane zespoły WordPress powinny traktować luki w wtyczkach z pilnością:

• Wdróż możliwość wirtualnego łatania na poziomie platformy, aby zablokować znane niebezpieczne ładunki na wszystkich stronach najemców.
• Oferuj aktualizacje jednym kliknięciem dla wtyczek i zapewnij zaplanowane okna konserwacyjne, które umożliwiają szybkie łatanie poprawek bezpieczeństwa.
• Zapewnij rejestrowanie i monitorowanie aktywności w obszarze administracyjnym oraz zmian plików.
• Edukuj klientów na temat minimalnych uprawnień i zarządzania użytkownikami: wiele problemów z wtyczkami jest potęgowanych przez zbyt permissywne role lub wspólne konta autorów.
• Utrzymuj podręczniki reakcji na incydenty oraz plan komunikacji na wypadek, gdyby luka została wykorzystana w środowiskach klientów.

---

Wykrywanie: oznaki, że mogłeś być celem lub doszło do naruszenia

Jeśli podejrzewasz, że twoja strona mogła być celem przy użyciu tego wektora lub podobnego przechowywanego XSS, szukaj:

• Tytułów załączników zawierających “”, “skrypt”, atrybuty obsługi zdarzeń takie jak “onerror”, “onload” lub osadzone ładunki SVG.
• Podejrzane interakcje administratora krótko po przesłaniu nowych mediów.
• Niespodziewane zmiany w ustawieniach wtyczek lub motywów, lub nieautoryzowane posty/strony utworzone.
• Niezwykły ruch wychodzący z serwera lub zaplanowane zadania (cron), których nie utworzyłeś.
• Zmodyfikowane pliki w wp-content, nowe pliki PHP zawierające zakodowane ładunki lub sygnatury webshelli.
• Nieautoryzowani użytkownicy administratora lub zmienione hasła.

Jeśli widzisz którykolwiek z powyższych:

• Wprowadź stronę w tryb konserwacji i ogranicz dostęp publiczny, gdzie to możliwe.
• Utwórz zrzut/backup do celów kryminalistycznych.
• Zmień dane uwierzytelniające dla kont administratorów, użytkowników bazy danych i kluczy API.

---

Lista kontrolna reakcji na incydent (jeśli podejrzewasz udane wykorzystanie)

1. Izolować:
   • Tymczasowo zablokuj dostęp administratora z publicznych adresów IP, jeśli to możliwe, lub wymuś resetowanie haseł i zakończ sesje.
2. Zawierać:
   • Wyłącz podatną wtyczkę (jeśli można to zrobić bezpiecznie).
   • Zastosuj łagodzenia (krótkie oczyszczanie kodu, zasady WAF).
3. Zbadać:
   • Zachowaj logi i utwórz pełną kopię zapasową witryny.
   • Szukaj webshelli, nieznanych plików PHP, podejrzanych zadań zaplanowanych oraz niedawno zmodyfikowanych plików wtyczek/motywów/rdzenia.
   • Przejrzyj aktywność użytkowników: kto, co i kiedy przesłał.
4. Wytępić:
   • Usuń złośliwe pliki i ładunki.
   • Zastąp skompromitowane pliki czystymi kopiami z zaufanych kopii zapasowych lub świeżych pobrań wtyczek/motywów.
5. Odzyskiwać:
   • Załatw lukę (zaktualizuj wtyczkę do v1.8.0+).
   • Bezpiecznie przywróć wszelkie zmienione ustawienia.
   • Przetestuj przepływy administracyjne i zweryfikuj, że funkcjonalność jest nienaruszona.
6. Po incydencie:
   • Zmień wszystkie odpowiednie dane uwierzytelniające (admin, FTP/SFTP, baza danych).
   • Rozważ ponowne wydanie kluczy/sól uwierzytelniających w wp-config.php.
   • Powiadom zainteresowane strony (użytkowników, klientów), jeśli doszło do ujawnienia danych.

Jeśli nie masz wewnętrznej ekspertyzy w zakresie bezpieczeństwa, rozważ zaangażowanie profesjonalisty do przeprowadzenia dochodzenia.

---

Rekomendacje dotyczące wzmocnienia — poza natychmiastową naprawą

Aby zmniejszyć zasięg podobnych luk w przyszłości:

• Zasada najmniejszego przywileju:
  • Ogranicz liczbę użytkowników posiadających role Edytora/Administratora. Przeglądaj konta użytkowników co kwartał.
  • Ogranicz możliwość przesyłania plików do zaufanych ról.
• Uwierzytelnianie wieloskładnikowe (MFA):
  • Wymagaj MFA dla wszystkich kont administratorów i edytorów.
• Monitorowanie integralności plików:
  • Użyj monitorowania, aby wykrywać nieoczekiwane zmiany plików w wp-content, motywach i wtyczkach.
• Regularne kopie zapasowe i testowanie przywracania:
  • Utrzymuj automatyczne kopie zapasowe i okresowo testuj przywracanie.
• Inwentaryzacja wtyczek i zarządzanie lukami:
  • Utrzymuj listę zainstalowanych wtyczek, wersji i daty ostatniej aktualizacji. Wyłącz wtyczki, których już nie potrzebujesz.
• Automatyczne aktualizacje (gdzie to bezpieczne):
  • Włącz automatyczne aktualizacje dla drobnych i zabezpieczeń, lub użyj procesów aktualizacji etapowej dla głównych wydań.
• Testowanie bezpieczeństwa:
  • Dodaj okresowe skany (SCA, SAST) i ręczne przeglądy bezpieczeństwa dla niestandardowego kodu.
• Monitoruj dzienniki:
  • Zachowaj logi dostępu i aplikacji oraz monitoruj podejrzane wzorce.

---

QA i testowanie po łataniu

• Po zaktualizowaniu wtyczki do 1.8.0+:
  • Wyczyść pamięci podręczne (serwera, obiektów, CDN).
  • Ponownie zeskanuj załączniki multimedialne pod kątem nietypowych tytułów lub podpisów i oczyść, jeśli to konieczne.
  • Testuj przepływy wtyczki i operacje multimedialne jako role Administratora i Redaktora, aby upewnić się, że nie ma regresji.
  • Jeśli wdrożyłeś kod sanitizacyjny na krótki okres, zachowaj go na krótki okres weryfikacji, a następnie usuń, jeśli jest zbędny i upewnij się, że łatka wtyczki obejmuje te przypadki.
  • Przeprowadź pełne skanowanie witryny pod kątem złośliwego oprogramowania, aby upewnić się, że nie wystąpiło wcześniejsze naruszenie.

---

Komunikacja i edukacja użytkowników

• Poinformuj swoje zespoły redakcyjne o ryzyku i przypomnij im, aby nie przesyłali plików z nieznanych źródeł.
• Jeśli niedawno dodano nowe role lub konta, przeprowadź audyt ich konieczności i uprawnień.
• Podziel się zwięzłym powiadomieniem o incydencie z kierownictwem IT, wyjaśniając podjęte kroki (aplikacja łatki, zakończone dochodzenia, zachowane logi).

---

Dlaczego klienci WP‑Firewall są chronieni

W WP‑Firewall traktujemy ujawnienia wtyczek tego typu poważnie. Nasza zarządzana zapora i wzmocnione zestawy reguł koncentrują się na:

• Szybkiej wirtualnej łatce dla znanych luk w wtyczkach, aby chronić witryny, które nie mogą być natychmiast zaktualizowane.
• Inspekcji przesyłek wieloczęściowych pod kątem podejrzanych metadanych i usuwaniu niebezpiecznych treści, zanim dotrą do WordPressa.
• Ciągłe monitorowanie i aktualizacje sygnatur w celu ochrony przed przechowywanymi wektorami XSS i innymi atakami typu injection.
• Łączenie skanowania, wykrywania zachowań i rekomendacji dotyczących reakcji, aby właściciele stron mogli szybko i bezpiecznie usunąć problemy.

Jeśli już korzystasz z WP‑Firewall, upewnij się, że twoje zasady i sygnatury są aktualne oraz przeglądaj wszelkie alerty związane z przesyłaniem mediów i skryptami interfejsu administracyjnego.

---

Zacznij chronić swoją stronę za darmo — plan WP‑Firewall Basic

Tytuł: Wzmocnij obronę swojej strony dzięki darmowemu planowi WP‑Firewall

Jeśli chcesz szybko uzyskać skuteczną podstawową ochronę podczas oceny aktualizacji i wzmocnienia, rozważ plan WP‑Firewall Basic (darmowy). Zawiera on:

• Zarządzany firewall i ochrony WAF dostosowane do WordPressa
• Nielimitowane zarządzanie przepustowością dla ruchu atakującego
• Skaner złośliwego oprogramowania do wykrywania podejrzanych plików i ładunków.
• Środki zaradcze dla 10 najważniejszych ryzyk OWASP

Zacznij teraz i dodaj odporną, zarządzaną warstwę ochrony, podczas gdy łatasz i wzmacniasz swoją stronę: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Jeśli potrzebujesz dodatkowej automatyzacji i raportowania, nasze plany Standard i Pro oferują automatyczne usuwanie złośliwego oprogramowania, kontrolę czarnych/białych list IP, miesięczne raporty, automatyczne łatanie wirtualne i premium dodatki.)

---

Co powinni zrobić autorzy i utrzymujący wtyczki

Jeśli jesteś autorem lub osobą odpowiedzialną za wtyczkę, która ujawnia metadane mediów lub wyświetla treści w interfejsach administracyjnych:

• Audytuj wszystkie miejsca, w których przechowywane lub renderowane są dane wejściowe użytkownika.
• Priorytetowo traktuj naprawę wszelkiego kodu, który wyświetla dane kontrolowane przez użytkownika bez odpowiedniego zabezpieczenia.
• Wydaj poprawkę i jasno komunikuj się z użytkownikami. Podaj wyraźny dziennik zmian i doradź co do minimalnej wymaganej wersji.
• Gdzie to możliwe, dodaj testy jednostkowe i testy bezpieczeństwa, które potwierdzają, że żaden HTML ani skrypt nie jest wykonywany, gdy renderowane są nieufne metadane.
• Rozważ odpowiedzialny proces ujawniania i kontakt w sprawie bezpieczeństwa, aby badacze mogli zgłaszać problemy prywatnie.

---

Ostateczne myśli — obrona w głębokości wygrywa

Ten przechowywany XSS jest podręcznikowym przykładem, jak nawet niekrytyczne funkcje (tytuły mediów i podpisy) mogą stać się wektorami ataku, jeśli obsługa wejścia/wyjścia jest niespójna. Odpowiednie podejście to podejście warstwowe:

• Szybko łataj podatne wtyczki.
• Wzmocnij role i możliwości.
• Zastosuj wirtualne poprawki i zasady WAF dla natychmiastowej ochrony.
• Oczyść i escape w kodzie; waliduj w danych wejściowych i escape w danych wyjściowych.
• Monitoruj i bądź gotowy do reakcji.

Jeśli potrzebujesz pomocy w ocenie swojego środowiska, WP‑Firewall oferuje opcje skanowania i zarządzanej ochrony, które mogą szybko zmniejszyć twoje narażenie i pomóc ci osiągnąć w pełni załatane, odporny stan witryny.

Bądź bezpieczny, aktualizuj swoje wtyczki i egzekwuj zasadę najmniejszych uprawnień — małe nawyki, które znacznie zmniejszają prawdopodobieństwo kompromitacji.

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