| Nazwa wtyczki | Kamień węgielny |
|---|---|
| Rodzaj podatności | Wykonanie dowolnego kodu |
| Numer CVE | CVE-2026-49113 |
| Pilność | Wysoki |
| Data publikacji CVE | 2026-06-06 |
| Adres URL źródła | CVE-2026-49113 |
Pilna porada dotycząca bezpieczeństwa — Wykonanie dowolnego kodu w wtyczce Cornerstone (< 7.8.8) i co musisz teraz zrobić
Data: 2026-06-05
Autor: Zespół ds. bezpieczeństwa WP-Firewall
Krótko mówiąc
Wysokosekwencyjna podatność na wykonanie dowolnego kodu (CVE-2026-49113, CVSS 8.5) dotyczy wersji wtyczki Cornerstone przed 7.8.8. Użytkownik z niskimi uprawnieniami (poziom subskrybenta) może wykorzystać lukę w iniekcji i eskalować do zdalnego wykonania kodu na podatnych stronach. Problem został zgłoszony przez badacza bezpieczeństwa Nguyena Ba Khana w kwietniu 2026 roku i publicznie opublikowany na początku czerwca 2026 roku.
Jeśli Twoja strona WordPress korzysta z Cornerstone i działa na wersji starszej niż 7.8.8, zaktualizuj ją natychmiast. Jeśli nie możesz zaktualizować od razu, zastosuj wirtualne łatanie i środki łagodzące z WAF, ogranicz dostęp i postępuj zgodnie z poniższą listą kontrolną odpowiedzi na incydenty.
Ta porada pochodzi od zespołu bezpieczeństwa WP‑Firewall i jest napisana dla właścicieli stron, deweloperów i dostawców hostingu, którzy potrzebują jasnych, praktycznych wskazówek — bez technicznego żargonu.
Co się stało
- Podatność: Wykonanie dowolnego kodu (zdalne)
- Dotknięte oprogramowanie: Wtyczka Cornerstone WordPress
- Wersje podatne: każda wersja wcześniejsza niż 7.8.8
- Poprawione w: 7.8.8
- CVE: CVE-2026-49113
- Zgłoszone: 23 kwietnia 2026 (badacz); ujawnienie publiczne 4 czerwca 2026
- Powaga: Wysoki (CVSS 8.5)
- Wymagane uprawnienia: Abonent (użytkownik z niskimi uprawnieniami, uwierzytelniony)
Krótko mówiąc: luka pozwala uwierzytelnionemu użytkownikowi z niskimi uprawnieniami na wstrzykiwanie danych, które mogą być wykorzystane do wykonania dowolnego kodu w kontekście użytkownika serwera WWW/PHP. Napastnicy mogą to wykorzystać do instalacji tylnej furtki, tworzenia nieautoryzowanych kont administratorów lub przejęcia pełnej kontroli nad stroną i przejścia do innych systemów.
Dlaczego to jest niebezpieczne
Oto kluczowe powody, dla których ta klasa podatności jest szczególnie poważna:
- Wykonanie dowolnego kodu oznacza, że napastnik może uruchamiać polecenia PHP lub systemowe w kontekście Twojego serwera WWW. Może to prowadzić do całkowitego kompromitacji strony.
- Wymagane uprawnienia napastnika są niskie (subskrybent). Każda strona, która pozwala na rejestrację użytkowników lub ma subskrybentów — w tym członkostwa, blogi i sklepy eCommerce — jest narażona.
- Podobne podatności są często wykorzystywane w zautomatyzowanych kampaniach masowego wykorzystania. Gdy dostępny jest PoC, zazwyczaj szybko następują zautomatyzowane skany na dużą skalę.
- Wykrywanie jest często opóźnione: napastnicy mają tendencję do instalowania ukrytych tylnych furtek, które przetrwają aktualizacje wtyczek, chyba że czyszczenie będzie dokładne.
Jak napastnicy mogą to wykorzystać (na wysokim poziomie, bez wykorzystania)
Zamiast pokazywać kod exploita, oto przepływ pracy atakującego, przeciwko któremu musisz się bronić:
- Utwórz lub użyj konta subskrybenta (lub skompromituj jedno).
- Prześlij przygotowany input do podatnego punktu końcowego Cornerstone (akcja AJAX, admin-ajax, trasy AJAX wtyczki lub pola formularza), który nie sanitizuje ani nie waliduje treści.
- Wstrzyknij ładunki, które powodują, że aplikacja ocenia lub zapisuje PHP dostarczone przez atakującego (lub tworzy przechowywany ładunek, który później wyzwala wykonanie kodu).
- Wykorzystaj zdalne wykonanie kodu do napisania PHP webshella, utworzenia nowego użytkownika administratora, modyfikacji plików motywu lub utrzymania stałego dostępu.
- Wykonaj kradzież danych, nadużycie SEO, spam, pivotowanie w środowisku hostingowym lub szyfruj treści dla okupu.
Ponieważ pierwszy krok wymaga tylko uprawnień subskrybenta, strony z otwartą rejestracją, zapisami członkowskimi lub podatnymi przepływami komentarz-do-użytkownika są w podwyższonym ryzyku.
Kto jest narażony na ryzyko
- Strony z wersjami wtyczki Cornerstone starszymi niż 7.8.8.
- Strony umożliwiające rejestrację użytkowników lub z użytkownikami na poziomie subskrybenta.
- Środowiska współdzielone i multi-site, w których atakujący może pivotować.
- Strony, które nie mają włączonego WAF/łatki wirtualnej ani agresywnego monitorowania.
Jeśli hostujesz wiele instalacji WordPress, sprawdź wszystkie z nich. Atakujący zazwyczaj skanują domeny i subdomeny, więc jedna podatna strona w klastrze często wystarcza do skompromitowania wielu zasobów.
Natychmiastowe kroki (co zrobić w ciągu następnej godziny)
- Zaktualizuj Cornerstone do wersji 7.8.8 lub nowszej — łatka jest ostatecznym rozwiązaniem. Zrób to natychmiast, jeśli możesz.
- Jeśli nie możesz zaktualizować teraz, wyłącz wtyczkę Cornerstone lub wyłącz funkcję, która ujawnia podatny punkt końcowy (przetestuj na stagingu, jeśli to możliwe).
- Włącz łatki wirtualne za pomocą swojego WAF — zastosuj regułę(-y) do zablokowania podatnych wzorców żądań i wyłącz niebezpieczne punkty końcowe AJAX związane z wtyczką.
- Wymuś reset haseł dla wszystkich kont użytkowników powyżej “subskrybenta” oraz dla podejrzanych kont. Rozważ zresetowanie wszystkich haseł administratorów.
- Wzmocnij rejestrację użytkowników — tymczasowo wyłącz publiczne rejestracje, jeśli je masz.
- Włącz lub zwiększ monitorowanie/rejestrowanie i skanuj w poszukiwaniu wskaźników kompromitacji (patrz poniżej).
- Jeśli podejrzewasz, że zostałeś skompromitowany, wyłącz stronę lub przełącz ją w tryb konserwacji podczas badania i usuwania problemu.
Wskaźniki naruszenia (IoCs) — na co zwracać uwagę
Skanuj w poszukiwaniu tych oznak w swoich plikach, bazie danych i logach serwera:
- Nieoczekiwani użytkownicy administratora lub użytkownicy z podwyższonymi rolami, których nie utworzyłeś.
- Nowe lub zmodyfikowane pliki PHP w wp-content/uploads, motywach lub wtyczkach; szczególnie pliki o losowych nazwach lub zawierające wywołania eval/base64_decode/system.
- Podejrzane zaplanowane zadania (wp_cron entries) lub nieznane zadania cron.
- Połączenia wychodzące z serwera WWW do nietypowych adresów IP/domen.
- Abnormalne skoki w CPU, pamięci lub ruchu wychodzącym.
- Błędy serwera 500/503 skorelowane z żądaniami POST do punktów końcowych wtyczek.
- Dziwne wpisy w logach dostępu: POST do admin-ajax.php lub niestandardowych punktów końcowych wtyczek z nietypowymi ładunkami (długie ciągi Base64, zserializowane dane z klasami, których nie rozpoznajesz).
- Artefakty webshell: pliki z długimi liniami zakodowanych danych lub wywołania do eval, preg_replace z /e, assert() lub create_function().
Przydatne grepy (uruchomione na konsoli serwera; dostosuj ścieżki do swojego środowiska):
- Znajdź niedawno zmodyfikowane pliki PHP:
find /var/www/html -type f -name "*.php" -mtime -30 -print - Szukaj wzorców base64 i eval:
grep -R --line-number -I --exclude-dir=vendor -E "base64_decode|eval\(|assert\(|preg_replace\(|create_function\(" /var/www/html - Przeszukaj logi dostępu w poszukiwaniu podejrzanych POSTów do admin-ajax:
zgrep "POST .*admin-ajax.php" /var/log/apache2/*access* | grep -E "base64|eval|wp-content"
Notatka: Jeśli znajdziesz pozytywne wskaźniki, zachowaj logi i znaczniki czasowe plików. Zrób zrzut forensyczny przed wprowadzeniem zmian, jeśli to możliwe.
Szczegółowa strategia usuwania
Krok po kroku podejście do ograniczenia, eliminacji i odzyskiwania.
1. Ograniczenie
- Zaktualizuj podatny wtyczkę do 7.8.8 jako pierwszy krok w ograniczaniu.
- Jeśli aktualizacja nie jest możliwa, wyłącz wtyczkę lub zablokuj żądania do podatnych punktów końcowych.
- Zastosuj zasady WAF, aby zablokować wzorce exploitów (wirtualne łatanie).
- Wyłącz publiczną rejestrację i ogranicz logowania za pomocą białej listy adresów IP, gdzie to możliwe.
2. Dochodzenie
- Zbierz logi: serwera WWW, PHP-FPM, dostępu, błędów oraz logi WordPressa (jeśli są).
- Porównaj sumy kontrolne plików z znanym dobrym kopią zapasową lub z oryginalną dystrybucją wtyczki/tematu.
- Sprawdź zmodyfikowane pliki rdzenia/tematu/wtyczki oraz nowo utworzone pliki w wp-content/uploads, wp-content/plugins i wp-content/themes.
3. Eliminacja
- Usuń wszelkie odkryte webshale lub tylne drzwi (zrób to ostrożnie; jeśli nie jesteś pewien, przywróć z czystej kopii zapasowej).
- Usuń wszelkich niepożądanych użytkowników administratora i zresetuj wszystkie hasła.
- Zmień wszystkie klucze API i dane uwierzytelniające, które mogły zostać ujawnione.
4. Odzyskiwanie
- Przywróć pliki witryny i bazę danych z czystej kopii zapasowej przed kompromitacją, a następnie natychmiast zaktualizuj wtyczki/tematy.
- Zainstaluj Cornerstone ponownie za pomocą świeżego pobrania z oficjalnego źródła, a następnie zaktualizuj do 7.8.8 lub nowszej.
- Ponownie zastosuj wzmocnienia bezpieczeństwa: uprawnienia do plików, wyłącz edytowanie plików w wp-config.php, role użytkowników z minimalnymi uprawnieniami.
5. Po incydencie
- Przeprowadź dokładne skanowanie bezpieczeństwa (skaner złośliwego oprogramowania, sprawdzenie integralności plików).
- Przejrzyj logi pod kątem ruchu bocznego lub powracających wskaźników.
- Edukuj użytkowników i personel na temat incydentu oraz wdrażaj długoterminowe środki zaradcze.
Jeśli nie masz odpowiednich umiejętności wewnętrznych, skontaktuj się ze specjalistą ds. bezpieczeństwa, który może przeprowadzić analizę forensyczną i dostarczyć czysty plan odzyskiwania. Gospodarze powinni rozważyć kwarantannę dotkniętych kont, podczas gdy trwa dochodzenie.
Jak WP‑Firewall cię chroni (praktyczne opcje łagodzenia)
W WP‑Firewall zalecamy podejście warstwowe. Oto jak nasza zarządzana zapora, WAF i usługi bezpieczeństwa pomagają blokować ten typ ataku, podczas gdy stosujesz długoterminowe poprawki:
- Wirtualne łatanie (zasady WAF): Możemy wdrożyć ukierunkowane zasady, które przechwytują i blokują złośliwe ładunki skierowane na wrażliwe punkty końcowe Cornerstone, zapobiegając próbom wykorzystania bez konieczności natychmiastowej aktualizacji wtyczki.
- Wykrywanie behawioralne: Wykrywanie i ograniczanie podejrzanych wzorców POST, nietypowych rozmiarów żądań i źle sformatowanych ładunków (np. nietypowo dużych blobów Base64 lub zserializowanych ładunków).
- Kontrola dostępu oparta na rolach: Ogranicz dostęp do administracyjnych punktów końcowych według IP lub wymagaj dodatkowej autoryzacji do uzyskania dostępu do obsługi AJAX wtyczek.
- Skanowanie i usuwanie złośliwego oprogramowania: Ciągłe skanowanie pod kątem znanych wzorców webshell i automatyczna kwarantanna/usuwanie złośliwych plików.
- Powiadomienia i logi w czasie rzeczywistym: Wysyłaj wykonalne powiadomienia (e-mail/SMS/UI), gdy możliwa próba wykorzystania zostanie zablokowana, z kontekstowymi logami do dalszego działania.
- Wsparcie incydentowe: Wskazówki i zarządzane usuwanie, jeśli odkryjesz kompromitację.
Te kontrole natychmiast zmniejszają ryzyko i dają czas na przeprowadzenie zalecanych aktualizacji i kroków forensycznych.
Sugerowane koncepcje zasad WAF (nie wklejaj surowych ładunków exploitów)
Poniżej znajdują się ogólne wzorce i działania, które powinieneś rozważyć dla zasad WAF. Wdrażaj ostrożnie — najpierw testuj w trybie wykrywania/nauki, aby uniknąć blokowania legalnego ruchu.
- Blokuj oczywiste wzorce zdalnego kodu:
- Blokuj żądania zawierające podejrzane nazwy funkcji w danych POST:
oceniać(,zapewniać(,dekodowanie_base64(,system(,exec(,shell_exec(,przepustka(,preg_replace("/e"). - Działanie: BLOKUJ i LOGUJ.
- Blokuj żądania zawierające podejrzane nazwy funkcji w danych POST:
- Ogranicz administracyjne punkty końcowe AJAX:
- Ogranicz dostęp do admin-ajax.php i wszelkich specyficznych punktów końcowych AJAX wtyczek dla użytkowników nieautoryzowanych.
- Dla znanych punktów końcowych wtyczek, które wykonują uprzywilejowane działania, wymagaj wewnętrznego tokena lub pochodzenia od zalogowanych administratorów.
- Progi rozmiaru i kontrole zestawu znaków:
- Zablokuj ciała POST zawierające bardzo duże zakodowane ciągi, intensywne użycie znaków nieczytelnych lub ekstremalnie długie ładunki zserializowane.
- Działanie: WYZWANIE/ODRZUCENIE z CAPTCHA lub 403.
- Podpis dla wstrzykiwania zserializowanych obiektów PHP:
- Wykryj/klasyfikuj zserializowane ładunki, które zawierają nieoczekiwane nazwy klas (szczególnie klasy aplikacji, które mogą być monster-deserializowane).
- Działanie: BLOKADA + ALARM.
- Profiluj zachowanie użytkowników:
- Ogranicz powtarzające się żądania z nowo utworzonych kont lub adresów IP, szczególnie podczas przesyłania długich ładunków.
- Działanie: OGRANICZENIE TEMPA lub TYMCZASOWY ZAKAZ.
- Ograniczenia geograficzne/IP (jeśli dotyczy):
- W obszarach administracyjnych zezwól tylko na znane regiony geograficzne lub znane zakresy IP; blokuj lub wyzywaj inne.
- Polityka dotycząca przesyłania:
- Zapobiegaj wykonywaniu plików PHP w katalogach przesyłania. Odrzuć wszelkie .php, .phtml, .phar w przesyłkach przez konfigurację serwera.
- Wprowadź ścisłe kontrole typów plików dla przesyłek.
Notatka: To są kontrolki koncepcyjne — WP‑Firewall może wdrożyć dostosowane, niskie zasady fałszywych pozytywów dla Ciebie. Nigdy nie stosuj zasad w trybie “blokady” bez wcześniejszego weryfikowania logów w trybie wykrywania.
Podręcznik wykrywania i polowania (praktyczne zapytania)
Użyj tych przykładów, aby poszukiwać dowodów prób lub udanych eksploatacji.
Baza danych WordPress: wyszukaj podejrzane opcje lub treści postów:
SELECT option_name, option_value
FROM wp_options
WHERE option_name LIKE '%cornerstone%' OR option_value LIKE '%eval(%' OR option_value LIKE 'se64_%';
WYBIERZ ID, user_login, user_email, user_registered, user_status;
Logi serwera: szukaj podejrzanych żądań:
zgrep -i "admin-ajax.php" /var/log/apache2/*access* | zgrep -Ei "base64|eval|serialize|object"
System plików: sprawdź nowe pliki PHP w uploads:
find /var/www/html/wp-content/uploads -type f -name "*.php" -print
Jeśli zauważysz oznaki nadużycia serializacji lub zakodowanych ładunków, załóż potencjalne naruszenie i eskaluj do reakcji na incydenty.
Rekomendacje dotyczące wzmocnienia (zapobieganie przyszłym incydentom)
- Utrzymuj wszystkie wtyczki, motywy i rdzeń zaktualizowane. Włącz automatyczne aktualizacje tam, gdzie to bezpieczne.
- Ogranicz role użytkowników i zastosuj zasadę najmniejszych uprawnień.
- Wyłącz edytory wtyczek i motywów: dodaj
define('DISALLOW_FILE_EDIT', true);w wp-config.php. - Wymuszaj silne hasła i MFA dla wszystkich uprzywilejowanych kont.
- Użyj zarządzanego WAF z wirtualnym łatającym i automatycznym skanowaniem.
- Wyłącz wykonywanie PHP w przesyłanych plikach:
<FilesMatch "\.php$"> Deny from all </FilesMatch> - Regularnie twórz kopie zapasowe i weryfikuj kopie zapasowe w zewnętrznych lokalizacjach.
- Przeprowadzaj regularne kontrole integralności plików i skanowanie złośliwego oprogramowania.
- Monitoruj logi pod kątem anomalii i centralnie przechowuj logi w celu zachowania/ gotowości do analizy kryminalistycznej.
- Edukuj personel i użytkowników na temat phishingu i higieny poświadczeń.
Rekomendacje dla dostawców hostingu
- Proaktywnie skanuj strony najemców pod kątem podatnych wersji Cornerstone i powiadamiaj klientów.
- Oferuj automatyczne wirtualne łatanie lub zasady WAF dla dotkniętych najemców.
- Zapewnij wskazówki i pomoc klientom w aktualizacji do łatki dostarczonej przez dostawcę.
- Kwarantanna stron podejrzewanych o kompromitację i powiadomienie klientów o krokach naprawczych oraz opcjach forensycznych.
- Zablokuj bezpośrednie wykonywanie PHP w katalogach przesyłania we wszystkich kontach, chyba że jest to wyraźnie wymagane.
Lista kontrolna odzyskiwania (jeśli zostałeś skompromitowany)
- Wyłącz stronę lub włącz tryb konserwacji w celu ograniczenia.
- Zamroź zmiany w logach i zrób forensyczny zrzut.
- Zidentyfikuj początkowy wektor dostępu; skataloguj wszystkie wskaźniki.
- Usuń webshale/backdoory lub przywróć z czystej kopii zapasowej.
- Zaktualizuj podatne wtyczki (Cornerstone 7.8.8+).
- Zmień wszystkie hasła i klucze API (baza danych, administrator, FTP/SFTP, panel hostingowy).
- Ponownie zainstaluj wszystkie wtyczki/motywy z oficjalnych źródeł.
- Ponownie uruchom pełne skanowanie złośliwego oprogramowania i kontrole integralności plików.
- Włącz ponownie usługi i uważnie monitoruj pod kątem powtórzenia.
- Zgłoś incydent swojemu hostowi / partnerowi ds. bezpieczeństwa i rozważ ujawnienie go dotkniętym interesariuszom.
Jak my w WP‑Firewall doradzamy w sprawie obsługi tej konkretnej porady dotyczącej Cornerstone
- Jeśli używasz Cornerstone <7.8.8, priorytetowo traktuj natychmiastową aktualizację do 7.8.8 lub nowszej.
- Użyj naszego zarządzanego WAF, aby zastosować ukierunkowane wirtualne łatki, podczas gdy planujesz aktualizację.
- Jeśli masz otwartą rejestrację, tymczasowo ją zamknij lub wprowadź dodatkowe kroki weryfikacyjne dla nowych kont.
- Włącz pełne skanowanie złośliwego oprogramowania na stronie i uruchom jednoklikową kontrolę integralności z WP‑Firewall.
- Aktywuj automatyczną czarną listę i ochronę przed ograniczeniem liczby zapytań dla podejrzanych punktów końcowych i nowych kont.
Nasz zespół zarządzanych operacji bezpieczeństwa jest dostępny, aby pomóc w dochodzeniach i pilnych działaniach naprawczych dla klientów na płatnych planach. Dla zespołów, które chcą natychmiastowej obrony w trybie samoobsługowym, nasz bezpłatny plan Basic obejmuje zarządzany firewall, WAF, skaner złośliwego oprogramowania oraz łagodzenie ryzyk OWASP Top 10 (szczegóły poniżej).
Nowość: Natychmiastowa ochrona dla właścicieli stron — przegląd planu bezpłatnego
Uzyskaj natychmiastową darmową ochronę z WP‑Firewall
Jeśli chcesz uzyskać natychmiastową, bezkosztową podstawową ochronę podczas przygotowywania aktualizacji i działań naprawczych, nasz plan Basic (bezpłatny) zapewnia niezbędne zabezpieczenia:
- Zarządzany firewall i zasady WAF do blokowania znanych exploitów, w tym wektorów OWASP Top 10
- Nielimitowana przepustowość i blokowanie ataków w czasie rzeczywistym
- Skaner złośliwego oprogramowania do wykrywania powszechnych webshelli i podejrzanych plików
- Zautomatyzowane zasady łagodzenia dla powszechnych wzorców wstrzykiwania i RCE
Zarejestruj się teraz, aby włączyć natychmiastowe wirtualne łatanie i ciągłą ochronę: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Jeśli potrzebujesz automatycznego czyszczenia, białej/czarnej listy adresów IP lub miesięcznych raportów, sprawdź nasze poziomy Standard i Pro w celu zaawansowanego usuwania, usług zarządzanych i automatycznego wirtualnego łatania.)
Często zadawane pytania
P — Już zaktualizowałem do 7.8.8. Czy jestem bezpieczny?
O — Aktualizacja usuwa lukę; jednak jeśli Twoja strona była wykorzystywana przed aktualizacją, możesz nadal mieć tylne drzwi lub mechanizmy utrzymania. Przeprowadź pełne skanowanie złośliwego oprogramowania, sprawdź pliki i użytkowników oraz zweryfikuj kopie zapasowe.
P — Nie mogę wyłączyć strony — co powinienem zrobić?
O — Włącz tryb blokowania WAF i natychmiast włącz wirtualne łatanie. Izoluj i blokuj rejestrację użytkowników oraz wszelki zewnętrzny dostęp do punktów końcowych wtyczki, aż będziesz mógł zastosować łatkę.
P — Czy odwiedzający może to wykorzystać bez logowania?
O — Luka wymaga uwierzytelnionego dostępu na poziomie subskrybenta. Jednak napastnicy często tworzą lub uzyskują konta subskrybentów poprzez rejestrację lub kradzież poświadczeń, więc publiczne rejestracje zwiększają ryzyko.
P — Czy aktualizacja zepsuje projekt mojej strony lub dostosowania?
O — Aktualizacje wtyczek mogą czasami wpływać na niestandardowe integracje. Zawsze testuj aktualizacje najpierw na etapie testowym. Jeśli natychmiastowa aktualizacja jest konieczna, aby zapobiec kompromitacji, zastosuj aktualizację, a następnie przetestuj; jeśli coś się zepsuje, przywróć z czystej kopii zapasowej i współpracuj z autorem wtyczki lub deweloperem.
Ostatnie słowa
To jest luka o wysokim priorytecie. Mimo że wymagany poziom uprawnień atakującego jest niski, konsekwencje mogą prowadzić do całkowitego przejęcia strony. Nie zwlekaj: zaktualizuj Cornerstone do 7.8.8 teraz, włącz wirtualne łatanie WAF, jeśli nie możesz zaktualizować natychmiast, i przeprowadź skoncentrowane dochodzenie w poszukiwaniu wskaźników kompromitacji. Jeśli potrzebujesz pomocy, rozważ zaangażowanie doświadczonych responderów incydentów WordPress.
My w WP‑Firewall monitorujemy sytuację i mamy dostępne zasady ochronne dla wszystkich klientów. Jeśli potrzebujesz szybkiej, praktycznej pomocy, nasz zespół ds. bezpieczeństwa jest gotowy do pomocy.
Bądź bezpieczny,
Zespół ds. bezpieczeństwa WP‑Firewall
