| Nazwa wtyczki | Wtyczka JAY Logowanie i Rejestracja WordPress |
|---|---|
| Rodzaj podatności | Luka w uwierzytelnianiu |
| Numer CVE | CVE-2025-14440 |
| Pilność | Wysoki |
| Data publikacji CVE | 2025-12-16 |
| Adres URL źródła | CVE-2025-14440 |
PILNE: Ominięcie uwierzytelnienia w JAY Logowanie i Rejestracja (<= 2.4.01) — Co właściciele stron WordPress muszą zrobić teraz
Autor: Zespół ds. bezpieczeństwa WP‑Firewall
Data: 2025-12-16
Tagi: WordPress, Bezpieczeństwo, Luka, Ominięcie uwierzytelnienia, WAF, Reakcja na incydenty
Streszczenie: Krytyczna luka w uwierzytelnieniu (CVE-2025-14440) wpływająca na wtyczkę JAY Logowanie i Rejestracja (wersje <= 2.4.01) została ujawniona 16 grudnia 2025 roku. CVSS 9.8. Luka pozwala nieautoryzowanym atakującym na ominięcie uwierzytelnienia poprzez manipulację logiką opartą na ciasteczkach. Jeśli używasz tej wtyczki, musisz działać natychmiast — postępuj zgodnie z poniższymi krokami łagodzenia i wykrywania.
Dlaczego to ma znaczenie (krótko)
Luki w uwierzytelnieniu są jednymi z najniebezpieczniejszych problemów dla stron WordPress. Atakujący, który skutecznie omija uwierzytelnienie, może wykonywać działania normalnie zarezerwowane dla administratorów — tworzyć lub modyfikować użytkowników, wprowadzać tylne drzwi, zmieniać treści lub przechodzić do innych części środowiska hostingowego. Ten konkretny problem ma zarówno wysoką powagę, jak i możliwość wykorzystania bez ważnych poświadczeń, co oznacza, że czas jest kluczowy.
Co wiemy o podatności
- Oprogramowanie dotknięte: Wtyczka JAY Logowanie i Rejestracja WordPress
- Wersje podatne: <= 2.4.01
- Klasyfikacja: Ominięcie uwierzytelnienia (OWASP A07 / Błędy identyfikacji i uwierzytelnienia)
- CVE: CVE-2025-14440
- Powaga: Wysoka (CVSS 9.8)
- Wymagane uprawnienia: Nieautoryzowane (brak wymaganego logowania)
- Opublikowane: 16 grudnia 2025
- Kredyt badawczy: zgłoszone przez badacza bezpieczeństwa
Podsumowanie techniczne (nieeksploatacyjne):
- Luka dotyczy obsługi ciasteczek i logiki walidacji sesji wtyczki. Z powodu niewystarczającej walidacji ciasteczka lub sposobu, w jaki stan sesji jest wnioskowany z wartości ciasteczka, atakujący może stworzyć lub zmodyfikować ciasteczko, aby aplikacja uwierzyła, że użytkownik jest uwierzytelnionym użytkownikiem.
- Ponieważ to ominięcie dotyczy uwierzytelnienia, może być używane do interakcji z punktami końcowymi chronionymi przez administratora lub innymi funkcjami z przywilejami, jeśli logika aplikacji internetowej polega wyłącznie na ciasteczku uwierzytelniającym wtyczki.
Nie opublikujemy tutaj eksploitu ani PoC. Odpowiednie podejście dla właścicieli stron i obrońców to skupienie się na wykrywaniu, ograniczaniu i naprawie.
Natychmiastowe działania dla właścicieli stron (usystematyzowane według priorytetu)
- Zidentyfikuj i zrób inwentaryzację dotkniętych stron
- Zaloguj się do swojej sieci WordPress lub każdej strony i sprawdź, czy wtyczka JAY Logowanie i Rejestracja jest zainstalowana.
- Potwierdź wersję wtyczki. Jeśli jest <= 2.4.01, traktuj stronę jako podatną.
- Weź wtyczkę offline (jeśli to możliwe)
- Jeśli to możliwe i jeśli wprowadzenie strony w tryb konserwacji jest akceptowalne, natychmiast dezaktywuj wtyczkę.
- Jeśli strona polega na wtyczce do bieżącej autoryzacji produkcji i nie można jej wyłączyć, przejdź do poniższych działań łagodzących.
- Unieważnij sesje i zmień sekrety
- Zmień sól WordPressa i klucze bezpieczeństwa (w wp-config.php). To unieważnia istniejące ciasteczka autoryzacyjne i sesje.
- Wymuś wylogowanie dla wszystkich użytkowników: w panelu administracyjnym WordPressa > Użytkownicy, edytuj każde konto i użyj Unieważnij sesje (lub zmień hasło), aby wymusić wylogowanie.
- Jeśli masz pamięć podręczną sesji po stronie serwera dla wtyczki, wyczyść ją.
- Zmień hasła administratorów i przejrzyj konta administratorów
- Zresetuj hasła dla wszystkich użytkowników na poziomie administratora. Wymuś silne, losowe hasła.
- Przeprowadź audyt listy użytkowników w poszukiwaniu nieznanych lub podejrzanych kont administratorów i usuń lub wyłącz je.
- Wdróż zabezpieczenia zapory aplikacji internetowej (WAF) / wirtualne łatanie
- Jeśli korzystasz z WP-Firewall, włącz regułę wirtualnej łatki awaryjnej, którą opublikowaliśmy (patrz sekcja łagodzenia WP-Firewall poniżej).
- Dla hostów i właścicieli stron na innych WAF-ach, wdroż reguły blokujące podejrzane żądania kierujące się do punktów końcowych autoryzacji, stron administracyjnych lub żądań zawierających podejrzane wartości ciasteczek.
- Odrzuć nieautoryzowane żądania, które próbują działać jak autoryzowani użytkownicy (patrz poniżej wskazówki dotyczące wykrywania i WAF).
- Skanuj w poszukiwaniu tylnej furtki i wskaźników kompromitacji (IoCs)
- Przeprowadź pełne skanowanie złośliwego oprogramowania za pomocą renomowanego skanera i narzędzia do sprawdzania integralności plików.
- Szukaj podejrzanych plików, zmodyfikowanych plików rdzeniowych, nieoczekiwanych plików PHP w przesyłkach, nowych użytkowników administratorów, nietypowych zadań zaplanowanych (cron) lub połączeń wychodzących, które wcześniej nie występowały.
- Jeśli znajdziesz dowody na kompromitację, załóż, że atakujący miał dostęp na poziomie administratora i postępuj zgodnie z krokami reakcji na incydent (izoluj, twórz kopie zapasowe, czyść, przywracaj z znanej dobrej kopii zapasowej, zmień dane uwierzytelniające).
- Łataj, gdy będzie dostępna — lub usuń wtyczkę
- Jeśli autor wtyczki opublikuje poprawioną wersję, zastosuj ją niezwłocznie i zweryfikuj swoją stronę.
- Jeśli nie możesz szybko załatać lub nie ufasz, że wtyczka zostanie wkrótce naprawiona, usuń lub zastąp wtyczkę utrzymywaną alternatywą. Upewnij się, że masz eksport/kopia zapasowa wszelkich ważnych danych używanych przez wtyczkę.
- Monitoruj logi i aktywność sieciową
- Sprawdź logi serwera WWW (logi dostępu i błędów) pod kątem żądań do punktów końcowych administratora, admin-ajax.php, wp-login.php, punktów końcowych AJAX oraz stron, które dostarcza wtyczka.
- Szukaj nietypowych żądań HTTP z pojedynczych adresów IP lub skoncentrowanego zestawu adresów IP, szczególnie tych, które zawierają zmiany ciasteczek lub powtórzone ciasteczka.
Konkretne wzorce wykrywania i na co zwracać uwagę
Poniżej znajdują się praktyczne rzeczy, na które warto zwrócić uwagę w swoich logach i telemetrii. Są one jedynie wskazówkami i celowo unikają publikowania treści dotyczących exploitów.
- Niespodziewane wartości ciasteczek w żądaniach do wp-admin, wp-login lub punktów końcowych AJAX.
- Żądania, które ustawiają lub modyfikują ciasteczka tuż przed uzyskaniem dostępu do stron administracyjnych.
- Powtarzające się żądania, które naśladują uwierzytelnione zachowanie z tego samego adresu IP, ale bez znanej ważnej sesji (na przykład identyczna wartość ciasteczka w wielu różnych adresach IP lub agentach użytkownika).
- Nowe konta administracyjne utworzone z podejrzanych adresów IP lub agentów użytkownika.
- Wysoka liczba żądań zawierających nagłówki ciasteczek, ale skutkujących odpowiedziami 200 dla zasobów chronionych przez administratora.
- Nietypowe żądania POST do punktów końcowych obsługiwanych przez wtyczkę (rejestracja, logowanie, niestandardowe akcje AJAX) towarzyszące modyfikacjom ciasteczek.
Kiedy zauważysz podejrzane wzorce:
- Zrób zrzut i zachowaj logi oraz znaczniki czasu.
- Jeśli masz środowisko kryminalistyczne, skopiuj logi do głębszej analizy.
- Tymczasowo zablokuj podejrzane adresy IP lub ogranicz ich liczbę podczas prowadzenia dochodzenia.
Łagodzenie WP-Firewall i wirtualne łatanie (jak cię chronimy)
Jako zespół bezpieczeństwa WP-Firewall traktujemy tego rodzaju problemy z omijaniem uwierzytelniania jako pilne. Przygotowaliśmy i wdrożyliśmy zautomatyzowaną wirtualną łatkę (reguła WAF), która blokuje znane wzorce exploitów dla tej podatności bez czekania na oficjalną aktualizację wtyczki.
Co robi WP-Firewall:
- Blokuje żądania, które pasują do wzorców sygnatur, które opracowaliśmy w koordynacji z raportem o podatności.
- Zatrzymuje żądania, które próbują eskalować do funkcjonalności administratora, nadużywając przepływów uwierzytelniania opartych na ciasteczkach.
- Zapewnia powiadomienia i raportowanie w czasie rzeczywistym, aby właściciele witryn widzieli próby i mogli zareagować.
- Umożliwia tymczasowe środki wzmacniające (zabrania określonych punktów końcowych, egzekwuje nagłówki bezpieczeństwa ciasteczek i blokuje nieoczekiwane manipulacje ciasteczkami).
Jeśli używasz WP-Firewall:
- Upewnij się, że Twoja witryna jest połączona i że automatyczne aktualizacje zasad zagrożeń są włączone.
- Potwierdź, że zasada awaryjna dla obejścia uwierzytelniania JAY Login & Register jest aktywna w Twoim panelu.
- Dla klientów zarządzanych nasz zespół automatycznie zastosuje środki łagodzące i powiadomi Cię o podjętych działaniach.
Ważny: Zasady WAF są środkiem łagodzącym, a nie trwałym rozwiązaniem. Musisz nadal zaktualizować wtyczkę lub usunąć ją, gdy dostępne będzie oficjalne rozwiązanie.
Praktyczne wskazówki dotyczące zasad WAF (ogólne i bezpieczne — przykłady dla obrońców)
Jeśli zarządzasz własnym WAF lub korzystasz z innego dostawcy, rozważ wdrożenie następujących ogólnych zabezpieczeń, unikając fałszywych pozytywów. To są typy zasad koncepcyjnych — dostosuj je do swojego środowiska i testowania.
- Blokuj nieautoryzowane żądania POST do punktów końcowych administratora lub specyficznych dla wtyczek, gdy towarzyszą im nowo ustawione/zmodyfikowane ciasteczka uwierzytelniające.
- Blokuj żądania próbujące bezpośrednio uzyskać dostęp do funkcjonalności administratora, gdy żądanie nie zawiera ważnego ciasteczka sesji zalogowanego w WordPressie (lub gdy ciasteczko nie mapuje się na sesję w pamięci serwera).
- Ograniczaj liczbę lub tymczasowo odrzucaj powtarzające się żądania z jednego adresu IP, które ustawiają ciasteczka, a następnie uzyskują dostęp do punktów końcowych administratora.
- Odrzuć żądania, które zawierają zachowanie ustawiające ciasteczka w połączeniu z dostępem do /wp-admin/ lub punktów końcowych AJAX administratora.
- Egzekwuj bezpieczne atrybuty ciasteczek (HttpOnly, Secure, SameSite) dla ciasteczek tworzonych przez wtyczkę (gdzie to możliwe).
Notatka: Nie stosuj zbyt szerokich zasad, które blokują legalnych użytkowników. Zawsze najpierw testuj w trybie monitorowania i dostosowuj zasady, aby uniknąć zablokowania administratorów.
Jak sprawdzić, czy Twoja witryna była już wykorzystana
Jeśli podejrzewasz kompromitację, natychmiast przeprowadź następujące kontrole:
- Konta użytkowników
- Audytuj wszystkie konta użytkowników. Szukaj kont z rolą administratora, których nie utworzyłeś.
- Sprawdź znaczniki czasu utworzenia i adresy IP dla kont administratorów.
- Pliki i kod
- Porównaj bieżące pliki z znanym dobrym kopią zapasową lub czystymi plikami rdzenia/tematu/wtyczek WordPress.
- Szukaj nieoczekiwanych plików PHP w wp-content/uploads lub wp-includes.
- Sprawdź zmodyfikowane znaczniki czasu, które nie pasują do normalnych aktualizacji.
- Zaplanowane zadania
- Wypisz zadania cron (wp-cron entries). Szukaj zaplanowanych zadań utworzonych przez nieznane wtyczki lub użytkowników.
- Połączenia wychodzące
- Sprawdź nieoczekiwane połączenia HTTP wychodzące lub zapytania DNS z serwera, które mogą wskazywać na wyciek danych.
- Zmiany w bazie danych
- Przejrzyj wp_options, wp_users i tabelę wtyczek w poszukiwaniu nieoczekiwanych wpisów. Szukaj modyfikacji danych zserializowanych, które umożliwiają backdoory.
- Wskaźniki backdoora
- Szukaj zafałszowanych wzorców kodu, eval(), base64_decode() lub wywołań funkcji system/exec w plikach wtyczek/tematów.
Jeśli znajdziesz dowody na kompromitację:
- Izoluj witrynę (włącz tryb konserwacji, ogranicz dostęp).
- Wykonaj pełną kopię zapasową bieżącej witryny do celów kryminalistycznych.
- Wyczyść witrynę i przywróć z znanej czystej kopii zapasowej, jeśli to możliwe.
- Po przywróceniu, zmień wszystkie dane uwierzytelniające (panel hostingowy, baza danych, FTP/SFTP, SSH, użytkownicy WP).
- Rozważ zaangażowanie specjalisty ds. reakcji na incydenty, jeśli brakuje Ci zasobów do dokładnego czyszczenia.
Rekomendacje dotyczące wzmocnienia bezpieczeństwa w celu zmniejszenia ryzyka związanego z problemami związanymi z ciasteczkami
Nawet po natychmiastowym złagodzeniu, wzmocnienie środowiska WordPress zmniejsza ryzyko podobnych problemów:
- Wymuś MFA dla wszystkich kont administratorów (użyj aplikacji uwierzytelniającej lub tokenów sprzętowych).
- Ogranicz dostęp administratorów według IP, gdzie to możliwe (na przykład, ograniczenia zapory ogniowej lub oparte na hoście).
- Użyj kontroli dostępu opartej na rolach i zasady najmniejszych uprawnień — unikaj niepotrzebnego przyznawania uprawnień administratora wielu osobom.
- Utrzymuj aktualne rdzenie WordPressa, motywy i wtyczki oraz subskrybuj usługę powiadamiania o lukach/łatkach.
- Włącz flagi bezpiecznych ciasteczek (HttpOnly, Secure, SameSite) dla ciasteczek sesyjnych i uwierzytelniających, gdzie twoja infrastruktura to wspiera.
- Wdrażaj silne logowanie i monitorowanie (dzienniki audytowe, wykrywanie zmian w plikach, powiadomienia o nieudanych logowaniach).
- Użyj zarządzanego WAF z możliwością wirtualnego łatania, aby szybko blokować znane wzorce exploitów.
- Regularnie twórz kopie zapasowe swojej witryny i weryfikuj, czy kopie zapasowe można przywrócić.
Wytyczne dotyczące komunikacji dla agencji i hostów zarządzających witrynami klientów
Jeśli zarządzasz wieloma witrynami klientów lub hostujesz instalacje WordPress klientów:
- Przeprowadź masowe skanowanie wtyczki w całej flocie i stwórz priorytetową listę dotkniętych witryn.
- Natychmiast zastosuj automatyczne środki zaradcze we wszystkich hostach (zasady WAF lub zasady zapory ogniowej oparte na hoście).
- Powiadom klientów jasno i szybko: wyjaśnij ryzyko, co zrobiłeś, aby je złagodzić, i co klienci muszą zrobić (zresetować hasła, włączyć MFA).
- Oferuj ukierunkowaną pomoc (usunięcie wtyczki, migracja do alternatywnego rozwiązania uwierzytelniającego lub tymczasowe wzmocnienie).
- Jeśli witryna klienta zostanie potwierdzona jako skompromitowana, udokumentuj incydent i podjęte działania dla zgodności i przejrzystości.
Dla deweloperów wtyczek: wnioski i wskazówki dotyczące bezpiecznego kodowania
Ta luka podkreśla powszechne pułapki podczas wdrażania uwierzytelniania z niestandardowymi ciasteczkami.
- Waliduj stan sesji po stronie serwera — nie ufaj wartościom ciasteczek po stronie klienta bez mapowania i weryfikacji po stronie serwera.
- Podpisuj i/lub szyfruj ładunki ciasteczek za pomocą sekretów po stronie serwera i weryfikuj podpis przy każdym żądaniu.
- Używaj tokenów o krótkim czasie życia i rotuj klucze, gdzie to możliwe.
- Unikaj polegania na obecności pliku cookie jako jedynego wskaźnika uwierzytelnienia.
- Używaj standardowych, sprawdzonych bibliotek do uwierzytelniania i zarządzania sesjami, zamiast niestandardowych implementacji ad-hoc.
- Ustaw atrybuty pliku cookie jako bezpieczne (HttpOnly, Secure, SameSite), aby zmniejszyć ryzyko kradzieży lub ataków między witrynami.
- Przeprowadź modelowanie zagrożeń dla przepływów uwierzytelniania i uwzględnij testy negatywne (co się stanie, jeśli plik cookie zostanie zmanipulowany).
- Opublikuj informacje kontaktowe dotyczące bezpieczeństwa oraz proces odpowiedzialnego ujawniania, aby problemy były zgłaszane prywatnie i odpowiedzialnie.
Jak klienci WP-Firewall byli chronieni (co zrobiliśmy)
- Opracowaliśmy i rozdystrybuowaliśmy zasady awaryjnych wirtualnych poprawek dla wzorców sygnatur podatności.
- Wdrożyliśmy zautomatyzowane monitory wykrywania, aby powiadamiać klientów, gdy wykryto próby wykorzystania.
- Zaleciliśmy klientom standardową listę kontrolną reakcji na incydenty: rotacja soli, resetowanie haseł administratorów, skanowanie w poszukiwaniu tylnych drzwi i (jeśli to konieczne) wyłączenie wtyczki.
- Dla zarządzanych klientów nasz zespół ds. incydentów proaktywnie wdrożył środki zaradcze i poinformował właścicieli witryn o konkretnych krokach naprawczych.
Jeśli jesteś klientem WP-Firewall i masz pytania dotyczące alertu lub potrzebujesz pomocy w realizacji kroków naprawczych, skontaktuj się z naszym zespołem wsparcia za pośrednictwem swojego panelu.
Lista kontrolna odzyskiwania i długoterminowych działań naprawczych
Po zakończeniu natychmiastowego łagodzenia, postępuj zgodnie z tą listą kontrolną, aby przywrócić i wzmocnić swoją witrynę:
- Potwierdź, że wtyczka została załatana lub wymieniona
- Jeśli dostępna jest poprawka od dostawcy, zastosuj ją i zweryfikuj funkcjonalność.
- Jeśli nie ma dostępnej poprawki, usuń wtyczkę i przenieś funkcje do bezpiecznej alternatywy.
- Zweryfikuj integralność witryny
- Przeprowadź kontrole integralności plików w porównaniu do czystych kopii WordPressa i motywów.
- Ponownie przeskanuj w poszukiwaniu złośliwego oprogramowania i wskaźników kompromitacji.
- Higiena poświadczeń
- Rotuj wszystkie dane uwierzytelniające: baza danych, hosting, FTP/SFTP, panele sterowania, klucze API i dane uwierzytelniające SMTP.
- Wymagaj MFA dla uprzywilejowanych kont.
- Monitorowanie i powiadomienia
- Włącz monitorowanie witryny i powiadomienia o logowaniu.
- Wdrażaj powiadomienia o zmianach administracyjnych i modyfikacjach plików.
- Dokumentuj i raportuj
- Udokumentuj oś czasu incydentu, co zostało dotknięte, podjęte kroki naprawcze i kroki weryfikacyjne.
- Jeśli Twoja organizacja wymaga raportowania regulacyjnego lub powiadomień dla klientów, postępuj zgodnie z wytycznymi prawnymi i zgodności.
- Analiza po incydencie i zapobieganie
- Przeprowadź analizę po incydencie, aby zidentyfikować przyczynę źródłową i poprawić kontrole.
- Zaktualizuj polityki zarządzania zmianami oraz zakupu dostawców/wtyczek, aby uwzględnić przeglądy bezpieczeństwa.
Często zadawane pytania (FAQ)
P: Czy moja witryna jest na pewno skompromitowana, jeśli używała podatnej wtyczki?
O: Niekoniecznie. Podatność umożliwia wykorzystanie, ale wymaga działania atakującego. Witryny są narażone i muszą być traktowane jako potencjalnie skompromitowane, dopóki nie zweryfikujesz ich za pomocą skanów, audytów i przeglądów dzienników.
P: Czy wyłączenie wtyczki to naprawi?
O: Wyłączenie wtyczki zmniejsza natychmiastową powierzchnię ataku. Zapobiega również używaniu logiki wtyczki do uwierzytelniania. Ale jeśli witryna została już wykorzystana, samo wyłączenie nie usuwa tylnej furtki. Musisz przeprowadzić skanowanie i dochodzenie.
P: Czy mogę polegać tylko na WAF?
O: WAF jest niezbędnym środkiem zaradczym i może blokować aktywne wykorzystanie, ale powinien być częścią wielowarstwowego podejścia: łatanie, wzmacnianie, rotacja poświadczeń i kontrole kryminalistyczne.
P: Jak szybko powinienem działać?
O: Natychmiast. Ponieważ podatność jest wykorzystywalna bez uwierzytelnienia i ma wysoką ocenę powagi, zastosuj środki zaradcze teraz.
Chroń swoją stronę już dziś — zacznij od darmowego planu WP‑Firewall
Jeśli nie masz jeszcze silnych zabezpieczeń perymetralnych, zacznij od naszego podstawowego (bezpłatnego) planu, aby zyskać czas i zatrzymać aktywne próby wykorzystania, podczas gdy naprawiasz:
- Podstawowa ochrona: zarządzana zapora sieciowa, nieograniczona przepustowość, WAF, skaner złośliwego oprogramowania i łagodzenie 10 największych zagrożeń OWASP.
- Nie jest wymagana karta kredytowa — zarejestruj się i włącz ochronę w ciągu kilku minut.
- Adres URL: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Nasz bezpłatny plan jest zaprojektowany, aby zapewnić małym witrynom i środowiskom testowym natychmiastową sieć bezpieczeństwa. Obejmuje zarządzany WAF i skanowanie złośliwego oprogramowania, które pomagają wykrywać podejrzane próby manipulacji ciasteczkami i blokować znane wzorce wykorzystania — dokładnie taki rodzaj ochrony, który pomaga w incydentach takich jak ten.
Ostateczne słowa od zespołu bezpieczeństwa WP‑Firewall
Ta luka jest wyraźnym przypomnieniem: uwierzytelnienie to krytyczna granica, a każda słabość w tym obszarze może być katastrofalna. Traktuj kod uwierzytelnienia wtyczek z taką samą starannością, z jaką traktujesz rdzeń WordPressa. Jeśli używasz dotkniętej wtyczki (JAY Login & Register <= 2.4.01), działaj teraz — albo wyłącz wtyczkę, zastosuj środki zaradcze, albo usuń ją, aż dostępna będzie poprawiona wersja i zostanie zweryfikowana.
Jeśli używasz WP‑Firewall, upewnij się, że Twoja strona jest połączona, a zasady dotyczące zagrożeń są aktualne. Dla agencji i hostów, priorytetem powinno być łatanie i komunikacja: Twoi klienci polegają na Tobie.
Jeśli potrzebujesz pomocy w praktyce, nasze zespoły reagowania na incydenty i zarządzanej bezpieczeństwa mogą pomóc w triage, łagodzeniu i odzyskiwaniu. Ochrona stron internetowych to nasza specjalność — zacznij od włączenia ochrony, którą kontrolujesz już dziś.
— Zespół ds. bezpieczeństwa WP‑Firewall
