| Nazwa wtyczki | Synchronizacja mediów |
|---|---|
| Rodzaj podatności | Przeglądanie katalogów |
| Numer CVE | CVE-2026-6670 |
| Pilność | Niski |
| Data publikacji CVE | 2026-05-13 |
| Adres URL źródła | CVE-2026-6670 |
Uwierzytelniona (Autor+) podatność na przejście katalogu w Synchronizacji Mediów (<= 1.4.9): Co właściciele stron WordPress muszą teraz zrobić
Krótko mówiąc — Podatność na przejście katalogu wpływająca na wersje Synchronizacji Mediów do i włącznie z 1.4.9 (CVE‑2026‑6670, CVSS 6.5) pozwala uwierzytelnionemu użytkownikowi z uprawnieniami na poziomie Autora lub wyższymi na żądanie plików poza zamierzonym katalogiem wtyczki. Może to prowadzić do ujawnienia informacji i może być wykorzystane jako punkt wyjścia do innych ataków. Autor wtyczki wydał poprawkę w wersji 1.5.0, która naprawia problem. Natychmiastowe działania: zaktualizować do 1.5.0 (lub nowszej), przejrzeć konta z podwyższonymi uprawnieniami, włączyć WAF/wirtualne łatanie i postępować zgodnie z poniższymi krokami naprawczymi.
W tym poście wyjaśniamy w prostych słowach, co się stało, jak atakujący mogą (i nie mogą) to wykorzystać, jak wykrywać próby wykorzystania, praktyczne kroki łagodzące — w tym dokładne przykłady reguł WAF, które możesz zastosować teraz — oraz pełną listę kontrolną odpowiedzi na incydent dostosowaną do stron WordPress.
Dlaczego to ma znaczenie dla Ciebie
- Podatność może być wykorzystana przez każdego użytkownika z rolą Autora (lub wyższą). Wiele stron ma wielu Autorów lub współpracowników z uprawnieniami do przesyłania.
- Przejście katalogu to ryzyko ujawnienia informacji: atakujący może odczytać pliki, których nie powinien widzieć (pliki konfiguracyjne, kopie zapasowe, klucze API, eksporty e-maili) i wykorzystać je do dalszej eskalacji.
- Nawet jeśli Twoja strona ma niewielu odwiedzających, zautomatyzowane skanery exploitów celują w podatności wtyczek masowo. Pozostawiona bez łatania, Twoja strona może być skanowana i wykorzystywana bez interakcji człowieka.
- Ta podatność ma średni poziom zagrożenia (CVSS 6.5) — nie jest trywialna, ale nie jest też od razu katastrofalna. Mimo to, jest wykonalna: najprostszym rozwiązaniem jest zaktualizowanie wtyczki.
Czym jest podatność na przejście katalogu (przejście ścieżki)?
Przejście katalogu (znane również jako przejście ścieżki) występuje, gdy aplikacja akceptuje dane wejściowe ścieżki pliku, które nie są odpowiednio walidowane ani oczyszczane, co pozwala użytkownikowi na nawigację po systemie plików poza zamierzonym katalogiem przy użyciu sekwencji takich jak ../ (lub ich odpowiedników zakodowanych w URL %2e%2e/) i żądanie plików takich jak /wp-config.php lub inne wrażliwe zasoby.
W kontekście WordPressa często wygląda to tak:
- Wtyczka udostępnia punkt końcowy AJAX lub skrypt, który odczytuje lub zwraca zawartość pliku na podstawie parametru ścieżki.
- Kod ufa podanej ścieżce i łączy ją z katalogiem bazowym bez kanonizacji lub ograniczenia.
- Uwierzytelniony użytkownik (w tym przypadku Autor+) dostarcza
../../../../etc/passwdścieżkę w stylu - i aplikacja zwraca zawartość pliku, której nie powinna.
Ponieważ exploit wymaga uwierzytelnienia (Autor+), nie jest to czysty zdalny dostęp bez uwierzytelnienia, ale nadal jest poważny: konta Autorów są powszechnie obecne na blogach z wieloma autorami, stronach z treściami przesyłanymi przez użytkowników oraz w niektórych większych organizacjach, gdzie redaktorzy i twórcy treści mają role Autorów.
Techniczne podsumowanie podatności Media Sync (na wysokim poziomie)
- Parametr ścieżki ujawniony przez wtyczkę Media Sync był niewystarczająco walidowany.
- Użytkownik na poziomie Autora mógł przesłać skonstruowane wartości ścieżki, aby spowodować, że wtyczka odczyta pliki poza bezpiecznym katalogiem wtyczki.
- Wtyczka nie znormalizowała ścieżki, nie znormalizowała
..sekwencji ani nie wymusiła ścisłej białej listy. - Wersja 1.5.0 naprawiła problem, zapewniając odpowiednią sanitację, kanonizację i/lub kontrole dostępu.
Notatka: Nie dołączamy ładunków PoC exploitów w tym komunikacie. Jeśli potrzebujesz pomocy w potwierdzeniu, czy dana strona została dotknięta, postępuj zgodnie z poniższymi krokami wykrywania i forensyki lub skontaktuj się z zaufanym dostawcą zabezpieczeń WordPress.
Natychmiastowe działania (co zrobić w ciągu następnych 60 minut)
- Aktualizacja wtyczki
– Natychmiast zaktualizuj Media Sync do wersji 1.5.0 lub nowszej. To najszybsza metoda łagodzenia.
– Jeśli nie możesz teraz zaktualizować, wyłącz wtyczkę: dezaktywuj wtyczkę z panelu administracyjnego WordPress lub zmień nazwę katalogu wtyczki za pomocą SFTP/SSH(wp-content/plugins/media-sync -> media-sync.disabled). - Zmniejsz narażenie, ograniczając możliwości Autora
– Tymczasowo usuń lub ogranicz możliwości przesyłania lub odczytu plików dla kont Autorów.
– Audytuj wszystkie konta na poziomie Autora i zweryfikuj, czy są ważne. Usuń lub zresetuj hasła dla nieznanych kont. - Włącz/weryfikuj WAF lub wirtualne łatanie
– Jeśli używasz WP‑Firewall (lub jakiegokolwiek WAF), włącz zasady, które wykrywają i blokują wzorce przechodzenia przez katalogi (przykłady poniżej).
– Jeśli nie masz WAF, rozważ wirtualne łatanie (tymczasowa zasada) podczas aktualizacji. - Monitorowanie dzienników pod kątem podejrzanej aktywności
– Sprawdź logi serwera WWW i logi WordPress w poszukiwaniu żądań zawierających..,%2e%2e, lub podejrzane nazwy parametrów odnoszące się do plików.
– Przeszukaj dzienniki audytu w poszukiwaniu nietypowych żądań autora do punktów końcowych AJAX lub punktów końcowych związanych z mediami. - Zrób kopię zapasową przed zastosowaniem poprawek
– Utwórz nową kopię zapasową (pliki + DB) przed wprowadzeniem zmian, jeśli planujesz bardziej inwazyjne działania naprawcze.
Jak sprawdzić, czy Media Sync jest zainstalowane i podatne
Z WP Admin:
Dashboard → Wtyczki → Zainstalowane wtyczki → poszukaj “Media Sync” i sprawdź kolumnę wersji.
Używając WP‑CLI (SSH):
# Lista wtyczek i wersji
# Lub bardziej czytelnie:.
Jeśli wersja wtyczki jest zgłaszana jako 1.4.9 lub niższa, traktuj witrynę jako podatną.
Jeśli nie możesz zaktualizować natychmiast, dezaktywuj wtyczkę:
wp plugin deactivate media-sync
Wykrywanie: na co zwracać uwagę w dziennikach i wskaźnikach kompromitacji
- Przeszukaj dzienniki dostępu i błędów serwera WWW (Apache, Nginx) oraz dzienniki WordPressa (jeśli istnieją) w poszukiwaniu podejrzanych żądań:
../Lub..\Żądania zawierające sekwencje przechodzenia ścieżek:- (po dekodowaniu URL)
%2e%2e%2f,%2e%2e%5c
- Requests to plugin endpoints (AJAX or API endpoints) by Author accounts
- Żądania do punktów końcowych wtyczek (punkty końcowe AJAX lub API) przez konta autorów
- Nietypowe skoki w żądaniach z tego samego adresu IP lub agenta użytkownika
- Pliki odczytane, które nie powinny być dostępne, lub żądania pobrania wrażliwych nazw plików
- Nagła tworzenie plików w
wp-content/przesyłaniektóre wyglądają jak kopie zapasowe lub zrzuty
Przykładowe polecenia grep:
# Search access logs for encoded ../ sequences
zgrep -i "%2e%2e" /var/log/nginx/access.log* /var/log/nginx/*.log* | less
# Search for raw ../ sequences
zgrep -E "\.\./|\.\.\\\\" /var/log/nginx/access.log* | less
# Look for requests to admin-ajax.php with suspicious parameters
zgrep -i "admin-ajax.php" /var/log/nginx/access.log* | egrep -i "%2e%2e|../" | less
Jeśli znajdziesz dowody na podejrzane odczyty, zrób forensyczny zrzut (logi + system plików) i postępuj zgodnie z poniższą listą kontrolną reakcji na incydent.
Co zrobić, jeśli podejrzewasz, że strona została już skompromitowana
- Izolować
Tymczasowo wyłącz stronę lub włącz tryb konserwacji, jeśli podejrzewasz wyciek danych lub dodatkową kompromitację. - Zachowaj dowody
Zachowaj kopie logów i zrzutów systemu plików. Nie nadpisuj logów; archiwizuj je. - Obracanie sekretów
Zresetuj hasła administratora WordPress i autora (wymuś reset hasła).
Zastąp wszelkie klucze API, hasła do bazy danych lub tokeny, które mogły zostać ujawnione. - Skanuj w poszukiwaniu złośliwego oprogramowania i tylnej furtki
Użyj skanera złośliwego oprogramowania i sprawdzenia integralności kodu (porównaj pliki z znanym dobrym kopią zapasową).
Wyszukaj pliki PHP wwp-content/przesyłanie, nieznane zadania cron, zmodyfikowane pliki rdzenia lub nowi użytkownicy administratora. - Przywróć lub usuń
Jeśli masz czystą kopię zapasową sprzed podejrzewanej kompromitacji, przywróć ją, a następnie zaktualizuj wtyczki i wzmocnij konfigurację.
Jeśli przywrócenie nie jest możliwe, rozważ odbudowę strony z najnowszym WordPress, motywami i wtyczkami. - Szukaj pomocy
Jeśli Twoja firma jest dotknięta i brakuje Ci pracowników wewnętrznych, zorganizuj profesjonalną reakcję na incydent.
Rekomendacje dotyczące wzmocnienia, aby zredukować podobne ryzyko w przyszłości
- Zasada najmniejszego przywileju:
- Przejrzyj role WordPress. Autorzy często potrzebują praw do publikacji i przesyłania, ale rozważ przyznanie węższych uprawnień lub użycie niestandardowej roli dla ścisłej kontroli.
- Usuń
przesyłanie_plikówzdolność autorów, jeśli nie jest potrzebna.
- Inwentaryzacja wtyczek i zarządzanie ryzykiem:
- Utrzymuj inwentarz zainstalowanych wtyczek i ich wersji. Użyj automatycznego skanowania, aby ostrzegać o podatnych wersjach wtyczek.
- Testowanie i próby:
- Zawsze testuj aktualizacje wtyczek na środowisku testowym. Jednak w przypadku wysokiego ryzyka podatności, priorytetowo traktuj natychmiastowe łatanie w produkcji, jeśli występuje aktywne wykorzystanie.
- Bezpieczna konfiguracja serwera:
- Wyłącz listowanie katalogów na serwerze WWW.
- Ogranicz bezpośredni dostęp do plików PHP w katalogach przesyłania:
- Dodać
Plik .htaccesszasady lub fragmenty Nginx, aby odmówić wykonania lub dostępu według ścieżki.
- Dodać
- Uprawnienia do plików i katalogów:
- Użyj bezpiecznych uprawnień do plików (np. 640 dla plików konfiguracyjnych, 644 dla plików, 750 dla katalogów, gdzie to stosowne).
- Zapewnić
wp-config.phpnie jest dostępny przez sieć.
- Monitorowanie i logowanie:
- Włącz i monitoruj szczegółowe logi.
- Użyj monitorowania integralności plików, aby wykrywać nieautoryzowane zmiany.
- Regularne kopie zapasowe:
- Przechowuj zautomatyzowane, wersjonowane kopie zapasowe offline lub na oddzielnym koncie.
- Często testuj przywracanie.
Zalecane zasady WAF / wirtualnego łatania WP-Firewall
Jeśli używasz WP‑Firewall (lub jakiegokolwiek produktu WAF, który pozwala na dodawanie niestandardowych zasad), rozważ dodanie następujących zasad jako tymczasowej wirtualnej łatki podczas aktualizacji wtyczki. Te zasady koncentrują się na blokowaniu prób przechodzenia przez katalogi i podejrzanych parametrów. Są celowo konserwatywne, aby uniknąć zakłócania normalnej funkcjonalności witryny — testuj ostrożnie w środowisku testowym przed pełnym wdrożeniem produkcyjnym.
Ostrzeżenie: zastosuj je najpierw jako wykrywanie/tylko powiadomienie, jeśli masz wiele legalnych integracji zewnętrznych, które mogą je wywołać.
Ogólny regex do przechodzenia przez katalogi, aby uchwycić ../ i zakodowane odpowiedniki
Zasada ModSecurity (format zgodny z OWASP CRS):
# Detect common ../ patterns including URL encoded forms
SecRule ARGS|ARGS_NAMES|REQUEST_URI|REQUEST_HEADERS "@rx (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c)" \n "id:100001,phase:2,deny,log,msg:'Directory traversal attempt detected',severity:2,rev:'1',tag:'wp-firewall,path-traversal'"
Nginx (z modułem ngx_http_modsecurity_module) również to wychwyci, jeśli ModSecurity jest obecny. Jeśli używasz Nginx bez ModSecurity, możesz dodać regułę lokalizacji:
# Example Nginx rule to block URL-encoded ../ patterns
if ($request_uri ~* "(%2e%2e%2f|%2e%2e%5c|\.\./|\.\.\\)") {
return 403;
}
Zasada blokowania podejrzanych parametrów ścieżki pliku (dotyczy punktów końcowych wtyczek)
Wiele punktów końcowych wtyczek akceptuje ścieżka, plik, parametr, Lub cel filepath. Poniższa zasada blokuje żądania do wspólnych punktów końcowych wtyczek, które zawierają wzorce przejścia w parametrach:
ModSecurity:
SecRule REQUEST_FILENAME|ARGS "@contains media-sync" \n "id:100002,phase:2,pass,log,ctl:ruleEngine=DetectionOnly,msg:'Media Sync endpoint accessed'"
SecRule REQUEST_URI "@rx (media-sync|media_sync|media-sync/.*/download|admin-ajax.php.*action=media_sync)" \n "id:100003,phase:2,deny,log,msg:'Possible traversal against media-sync plugin',chain"
SecRule ARGS "@rx (\.\./|\.\.\\|%2e%2e)" "t:none"
SecRule REQUEST_URI "@rx (media-sync|media_sync|media-sync/.*/download|admin-ajax.php.*action=media_sync)" \n "id:100003,phase:2,deny,log,msg:'Możliwe przejście przeciwko wtyczce media-sync',chain"
- SecRule ARGS "@rx (\.\./|\.\.\\|)" "t:none"
../lub zakodowane warianty - Jeśli uruchamiasz jakiekolwiek UI WAF, które akceptuje proste wyrażenia reguł, blokuj żądania z:
multipart/form-datawartościami parametrów zawierającymi.. - content-type
z podejrzanie długimi ścieżkami nazw plików, które zawierają
Konta na poziomie autora wykonujące powtarzające się żądania do punktów końcowych wtyczek — ogranicz lub blokuj anomalie
- Ograniczanie tempa podejrzanych użytkowników.
- Ogranicz powtarzające się żądania POST/GET do punktów końcowych wtyczek z tego samego adresu IP lub tego samego tokena użytkownika:.
Zastosuj krótkoterminowe limity tempa (np. 10 żądań w ciągu 30 sekund), aby zmniejszyć próby automatycznego wykorzystania.
Wprowadź tymczasowe blokady IP dla wzorców ruchu nadużywającego.
Ochrony na poziomie serwera (fragmenty Nginx / Apache)
Odrzuć dostęp do wrażliwych plików (przykład Nginx):
location ~* /(wp-config.php|readme.html|license.txt|\.env)$ {
Apache Plik .htaccess aby zapobiec wyświetlaniu katalogów i wyłączyć PHP w przesyłkach:
# Wyłącz wyświetlanie katalogów
Małe fragmenty kodu, które możesz użyć w functions.php, aby zmniejszyć ryzyko
Usunąć przesyłanie_plików uprawnienia dla Autorów (tymczasowe rozwiązanie, jeśli Autorzy nie muszą przesyłać):
add_action('init', function() {;
Ogranicz dostęp do adresów URL mediów dla uwierzytelnionych użytkowników (przykład):
// Zablokuj bezpośredni dostęp do plików za pomocą parametrów zapytania (przykładowe podejście);
Ważny: Każda tymczasowa zmiana uprawnień powinna być rejestrowana i przywracana, jeśli zakłóca przepływy pracy. Używaj tych środków jako tymczasowych rozwiązań, a nie stałych substytutów dla łatania.
Testowanie obrony po łatanie
- Potwierdź, że wtyczka jest zaktualizowana do 1.5.0+ (WP Admin i WP‑CLI).
- Ponownie przeskanuj witrynę za pomocą skanera bezpieczeństwa, który sprawdza tę konkretną lukę w wtyczce.
- Zweryfikuj, że zasady WAF są aktywne i nie rejestrują fałszywych pozytywów dla normalnych funkcji witryny.
- Monitoruj logi przez 24–72 godziny w poszukiwaniu powtarzających się prób z tych samych adresów IP lub agentów użytkownika — zablokuj i zgłoś je, jeśli są złośliwe.
Lista kontrolna reagowania na incydenty (krok po kroku)
- Potwierdź wersję wtyczki i natychmiast zaktualizuj do 1.5.0+.
- Zapisz logi (serwer www, WAF, WordPress) za okres przed i po łatanie.
- Utwórz pełną kopię zapasową witryny (pliki + DB) i zarchiwizuj ją offline.
- Audytuj konta użytkowników (Autorzy i wyżej). Zresetuj hasła i usuń podejrzane konta.
- Skanuj w poszukiwaniu złośliwego oprogramowania/backdoorów w całym systemie plików (szczególnie w przesyłkach i wp-content).
- Rotuj wszystkie sekrety, które mogą być narażone (poświadczenia DB, klucze API).
- Wydaj ponownie certyfikaty SSL/TLS, jeśli klucze prywatne są przechowywane w sposób niebezpieczny na serwerze i istnieją jakiekolwiek wskazania, że mogą być narażone.
- Przywróć z czystej kopii zapasowej, jeśli potwierdzono naruszenie i naprawa na miejscu nie jest możliwa.
- Złóż wewnętrzny raport o incydencie i powiadom zainteresowane strony (zgodność/prawo/klientów) zgodnie z Twoimi politykami.
- Po oczyszczeniu, wzmocnij stronę (WAF, ścisłe uprawnienia, monitorowanie, regularne skany).
Plan zapobiegania (co zalecamy dla każdej strony)
- Utrzymuj wtyczki, motywy i rdzeń WordPressa na bieżąco.
- Prowadź dokładny rejestr wtyczek i subskrybuj powiadomienia o lukach w zabezpieczeniach.
- Używaj kontroli dostępu opartych na rolach i regularnie przeglądaj użytkowników i ich uprawnienia.
- Wdróż WAF z możliwością wirtualnego łatania, aby szybko blokować wzorce eksploatacji.
- Wdrażaj monitorowanie integralności plików i scentralizowane logowanie.
- Okresowo przeprowadzaj ręczne przeglądy kodu (szczególnie dla wtyczek, które obsługują operacje na plikach).
- Utrzymuj przetestowane kopie zapasowe i udokumentowany plan odzyskiwania.
Dlaczego WAF i wirtualne łatanie są pomocne
Zapora aplikacji internetowej (WAF) daje dodatkową warstwę ochrony podczas aktualizacji: może wykrywać wzorce ataków, takie jak ../ i blokować je na krawędzi, zapobiegając ruchowi eksploatacyjnemu docierającemu do podatnego kodu wtyczki. Wirtualne łatanie (tymczasowe zasady zaprojektowane w celu zablokowania zidentyfikowanej luki) jest praktycznym rozwiązaniem tymczasowym — szczególnie przydatnym, gdy:
- Zarządzasz wieloma stronami i nie możesz ich natychmiast zaktualizować.
- Musisz zredukować ryzyko podczas testowania aktualizacji wtyczek na etapie.
- Potrzebujesz automatycznej ochrony przed botami skanującymi masowo.
WP‑Firewall może stosować wirtualne łaty i niestandardowe zasady, blokować podejrzany ruch i zapewniać automatyczne skany złośliwego oprogramowania w celu wykrywania oznak naruszenia. Należy jednak pamiętać, że WAF nie zastępuje łatania; zmniejsza narażenie, ale nie naprawia podatnego kodu.
Przydatne polecenia i kontrole (szybki przewodnik)
- Sprawdź wersję wtyczki:
wp plugin list --format=csv | grep -i media-sync - Dezaktywuj wtyczkę:
wp plugin deactivate media-sync - Przeszukaj logi w poszukiwaniu wzorców przejścia:
zgrep -E "\.\./|%2e%2e" /var/log/nginx/access.log* - Lista użytkowników z rolą Author+:
# Wklej w WP-CLI eval-file lub functions.php tymczasowo
Zalecana komunikacja do interesariuszy (szablon)
Jeśli zarządzasz wieloma stronami lub obsługujesz strony dla klientów, wyślij jasną, wykonalną notatkę:
- Streszczenie: Wersje wtyczki Media Sync <= 1.4.9 mają lukę w przejściu ścieżki (CVE‑2026‑6670). Wersja 1.5.0 to naprawia.
- Uderzenie: Uwierzytelniony Autor mógł odczytać pliki poza katalogiem wtyczki. Możliwe ujawnienie informacji i ryzyko pivotowania.
- Wymagana akcja: Natychmiast zaktualizuj Media Sync do 1.5.0+. Jeśli aktualizacja nie może być przeprowadzona w ciągu 24 godzin, tymczasowo dezaktywujemy wtyczkę i włączamy wirtualne poprawki WAF.
- Weryfikacja: Po aktualizacji przeskanujemy w poszukiwaniu wskaźników kompromitacji i podzielimy się wynikami.
Zacznij od Ochrony Podstawowej — Darmowy Plan WP‑Firewall
Jeśli nie masz jeszcze ochrony zapory, rozważ rozpoczęcie od naszego planu Podstawowego (Darmowego), aby zablokować najczęstsze ataki internetowe i uzyskać natychmiastową ochronę podczas łatania podatnych wtyczek.
Co otrzymujesz z darmowym planem:
- Podstawowa ochrona: zarządzana zapora, nielimitowana przepustowość.
- Pokrycie rdzenia WAF i łagodzenie ryzyk OWASP Top 10.
- Skaner złośliwego oprogramowania do sprawdzania znanych wskaźników i podejrzanych plików.
- Łatwe włączanie/wyłączanie reguł wirtualnych poprawek, aby szybko zatrzymać próby wykorzystania.
Gotowy, aby chronić swoją stronę teraz? Dowiedz się więcej i zarejestruj się w darmowym planie WP‑Firewall: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Darmowy plan jest idealny do natychmiastowego pokrycia; dostępne są opcje aktualizacji do automatycznego usuwania, zaawansowanego raportowania i zarządzanych usług.)
Zakończenie uwag od ekspertów ds. bezpieczeństwa WP‑Firewall
Ta luka przypomina, że nawet powszechnie używane wtyczki mogą zawierać błędy, które wpływają na autoryzację i obsługę ścieżek. Dobra wiadomość: ten problem wymaga uwierzytelnionego dostępu (Author+), łatka jest dostępna, a skuteczne zabezpieczenia (WAF + natychmiastowa aktualizacja wtyczki) można zastosować już dziś.
Jeśli zarządzasz wieloma stronami WordPress, zautomatyzuj inwentaryzację i łatanie tak bardzo, jak to możliwe. Jeśli potrzebujesz pomocy w stosowaniu wirtualnych poprawek, skanowaniu w poszukiwaniu wskaźników kompromitacji lub wzmacnianiu ról i uprawnień WordPress, nasi inżynierowie ds. bezpieczeństwa są dostępni, aby pomóc.
Zachowaj bezpieczeństwo, aktualizuj na bieżąco i uważnie obserwuj logi — napastnicy często szukają łatwych celów, a zapobieganie oraz szybkie łagodzenie to najpewniejsza ochrona.
— Zespół ds. bezpieczeństwa WP‑Firewall
