Krytyczna nieautoryzowana injekcja SQL w Kalendarzu Wydarzeń//Opublikowano 2025-11-05//CVE-2025-12197

ZESPÓŁ DS. BEZPIECZEŃSTWA WP-FIREWALL

The Events Calendar CVE-2025-12197

Nazwa wtyczki Kalendarz wydarzeń
Rodzaj podatności Nieuwierzytelniony atak SQL Injection
Numer CVE CVE-2025-12197
Pilność Wysoki
Data publikacji CVE 2025-11-05
Adres URL źródła CVE-2025-12197

Pilna informacja o bezpieczeństwie: Kalendarz Wydarzeń (WP) — nieautoryzowana injekcja SQL (CVE-2025-12197)

Informacja o bezpieczeństwie WP-Firewall i przewodnik po łagodzeniu

Streszczenie: Opublikowano krytyczną lukę w zabezpieczeniach w postaci nieautoryzowanej injekcji SQL, która dotyczy wtyczki Kalendarz Wydarzeń WordPress w wersjach od 6.15.1.1 do 6.15.9 (CVE-2025-12197). Deweloper wydał poprawioną wersję 6.15.10. Ocena CVSS: 9.3 (Wysoka). Ponieważ luka jest nieautoryzowana i dotyczy szeroko stosowanej wtyczki, jej wykorzystanie może być zautomatyzowane i skierowane masowo. Ta informacja wyjaśnia ryzyko, natychmiastowe i długoterminowe środki łagodzące, wskazówki dotyczące wykrywania oraz kroki reagowania na incydenty z perspektywy profesjonalnego zespołu zabezpieczeń i zapory WordPress.

Spis treści

  • Co się stało (na wysokim szczeblu)
  • Dlaczego to ma znaczenie dla właścicieli stron WordPress
  • Czym jest nieautoryzowana injekcja SQL?
  • Dotknięte wersje i poprawiona wersja
  • Natychmiastowe działania (pierwsze 60–120 minut)
  • Zalecane środki łagodzące, gdy nie możesz natychmiast zastosować poprawki
  • Jak wykryć próby lub udane wykorzystanie
  • Kroki dochodzeniowe i naprawcze, jeśli podejrzewasz kompromitację
  • Długoterminowe wzmocnienie i zapobieganie
  • Szybka lista kontrolna (do wydruku)
  • Uzyskaj natychmiastową zarządzaną ochronę z WP-Firewall (Plan darmowy) — zarejestruj się
  • Dodatek: przydatne polecenia WP-CLI i odniesienia

Co się stało (na wysokim szczeblu)

Odkryto lukę w zabezpieczeniach o wysokim ciężarze w postaci injekcji SQL w wtyczce Kalendarz Wydarzeń dla WordPress. Luka pozwala nieautoryzowanemu atakującemu na wstrzyknięcie SQL za pomocą danych wejściowych przetwarzanych przez wtyczkę (zgłoszone przeciwko parametrowi powszechnie nazywanemu S, który jest parametrem wyszukiwania/zapytania). Luka występuje w wersjach od 6.15.1.1 do 6.15.9 i została naprawiona w wersji 6.15.10.

Ponieważ wada jest nieautoryzowana i ma ocenę 9.3 w CVSS, wykorzystanie może pozwolić atakującemu na odczyt lub modyfikację zawartości bazy danych, tworzenie kont administracyjnych lub nawet utrzymywanie tylnej furtki. Atakujący często automatyzują skanowanie i wykorzystanie takich powszechnych luk, więc okno ryzyka (czas między publicznym ujawnieniem a powszechnym wykorzystaniem) jest krótkie.

Dlaczego to ma znaczenie dla właścicieli stron WordPress

  • Kalendarz Wydarzeń jest powszechnie używany na stronach publikujących wydarzenia — często z publicznymi parametrami wyszukiwania lub zapytania. Luka w wtyczce, która obsługuje publiczne dane wejściowe, jest wysokiego ryzyka.
  • Nieautoryzowany oznacza, że nie jest wymagane logowanie — każdy w internecie może próbować wykorzystania.
  • Wstrzyknięcie SQL wpływa bezpośrednio na warstwę bazy danych. WordPress przechowuje dane uwierzytelniające, konta użytkowników, posty, konfiguracje i dane wtyczek w bazie danych; udane SQLi mogą prowadzić do kradzieży danych, eskalacji uprawnień i przejęcia witryny.
  • Ponieważ jest to błąd o wysokiej wadze, publicznie ujawniony z dostępną poprawką, atakujący prawdopodobnie podejmą próbę automatycznych skanów. Terminowe łatanie lub wirtualne łagodzenie jest niezbędne.

Czym jest nieautoryzowana injekcja SQL?

Mówiąc prosto: wstrzyknięcie SQL pozwala atakującemu na wstawienie złośliwego SQL do zapytania, które wtyczka wykonuje w bazie danych. Jeśli wtyczka używa niesanitarnych zmiennych bezpośrednio w instrukcjach SQL, atakujący może zmienić semantykę zapytania. “Nieautoryzowany” oznacza, że atakujący nie potrzebuje konta — złośliwe dane wejściowe są akceptowane z anonimowych żądań (strony publiczne, punkty końcowe REST, formularze wyszukiwania itp.).

Potencjalne skutki obejmują:

  • Odczytywanie wrażliwych danych (e-maile użytkowników, hasła w postaci skrótu, klucze API, dane płatności przechowywane w DB)
  • Tworzenie lub modyfikowanie użytkowników administracyjnych WordPressa
  • Wstrzykiwanie trwałej treści/tylnych drzwi do postów lub opcji, które umożliwiają przyszły dostęp
  • Usuwanie lub uszkadzanie danych
  • W niektórych konfiguracjach DB wykonywanie administracyjnych poleceń SQL prowadzących do dalszego kompromitowania

Dotknięte wersje i poprawiona wersja

  • Wrażliwa: wtyczka The Events Calendar — wersje 6.15.1.1 do 6.15.9
  • Naprawione w: 6.15.10
  • CVE: CVE-2025-12197
  • Kredyt za odkrycie: badacz uznany (ujawnienie publiczne)

Jeśli Twoja witryna działa na wrażliwej wersji, musisz podjąć działania natychmiast.

Natychmiastowe działania (pierwsze 60–120 minut)

Postępuj zgodnie z tą priorytetową sekwencją. Nie pomijaj kroków — im szybciej działasz, tym mniejsze ryzyko.

  1. Sprawdź wersję wtyczki (szybko)
    • Panel: WordPress admin > Wtyczki > Zainstalowane wtyczki > The Events Calendar
    • WP-CLI: wp plugin list --status=active | grep the-events-calendar
  2. Jeśli możesz zaktualizować natychmiast, zaktualizuj do 6.15.10 (zalecane)
    • UI administratora: Wtyczki > Zaktualizuj teraz dla The Events Calendar
    • WP-CLI: wp plugin update the-events-calendar --version=6.15.10
  3. Jeśli nie możesz zaktualizować natychmiast, tymczasowo dezaktywuj wtyczkę
    • Interfejs administracyjny: Wtyczki > Dezaktywuj (jeśli funkcjonalność jest akceptowalna do wyłączenia)
    • WP-CLI: wp plugin deactivate the-events-calendar
    • Jeśli wtyczka obsługuje krytyczną funkcjonalność i nie można jej wyłączyć, przejdź do opcji łagodzenia poniżej (zasady WAF, ograniczenie dostępu).
  4. Wprowadź stronę w tryb wyższej obrony
    • Włącz zasady WAF, które blokują wzorce SQLi przeciwko żądaniom, które celują w punkty końcowe wydarzeń/wyszukiwania i parametry zapytań (szczegóły poniżej).
    • Wprowadź ograniczenia szybkości i blokuj podejrzane adresy IP.
  5. Wykonaj kopię zapasową (baza danych + pliki) przed wprowadzeniem zmian
    • Stwórz teraz kopię offline — może być potrzebna do analizy kryminalistycznej.
  6. Uważnie monitoruj logi i alerty
    • Zwiększ szczegółowość logowania tam, gdzie to możliwe, zachowaj logi poza hostem.

Zalecane środki łagodzące, gdy nie możesz natychmiast zastosować poprawki

Jeśli natychmiastowa aktualizacja wtyczki nie jest możliwa (obawy dotyczące zgodności, wymagania dotyczące stagingu itp.), zastosuj środki kompensacyjne, aby zmniejszyć narażenie.

  1. Wirtualne łatanie za pomocą zapory aplikacji internetowej (WAF)
    • Wdróż zasadę blokującą podejrzane wskaźniki SQL w parametrach zapytań używanych przez wtyczkę (na przykład, parametr powszechnie nazywany S).
    • Zasada powinna być wystarczająco łagodna, aby uniknąć zakłóceń w działalności, ale wystarczająco surowa, aby wychwycić wzorce wstrzyknięć (zobacz sekcję wskazówek dotyczących zasad poniżej).
    • Wirtualne łatanie zyskuje czas, aż będziesz mógł zainstalować poprawkę upstream.
  2. Zablokuj lub ogranicz dostęp do punktów końcowych, które akceptują S lub podobne parametry zapytań
    • Jeśli wtyczka udostępnia konkretny punkt końcowy wyszukiwania front-end lub REST, ogranicz dostęp według IP (tylko dla administratorów) lub wymagaj tokena do wyszukiwania.
    • Przykład: użyj konfiguracji serwera (nginx/Apache), aby zablokować żądania z określonymi ciągami zapytań przed dostępem publicznym, chyba że pochodzą z zaufanych adresów IP.
  3. Tymczasowe wzmocnienie za pomocą .htaccess / reguł serwera 
    # Block simple SQL injection patterns in query string
<IfModule mod_rewrite.c>
  RewriteEngine On
  # Block requests with UNION, SELECT, SLEEP, or comment indicators in the query string (case insensitive)
  RewriteCond %{QUERY_STRING} (?:union|select|sleep|benchmark|information_schema|concat|--|%2F\*|%2A%2F) [NC]
  RewriteRule .* - [F,L]
</IfModule>

    Uwaga: Ta reguła jest rozwiązaniem tymczasowym i powinna być testowana na etapie przed produkcją. Zbyt rygorystyczne wzorce mogą blokować legalne zapytania wyszukiwania; dostosuj do ruchu na swojej stronie.

  4. Ograniczenie liczby żądań i filtrowanie reputacji IP
    • Ogranicz liczbę żądań na sekundę/minutę do punktów końcowych wyszukiwania.
    • Zablokuj lub wyzwól (CAPTCHA) powtarzające się żądania, które trafiają do tego samego punktu końcowego z podejrzanymi wzorcami ładunku.
  5. Minimalne uprawnienia dla użytkownika DB
    • Upewnij się, że użytkownik bazy danych WordPress nie ma więcej uprawnień niż to konieczne. Usuń SUPER, FILE lub inne podwyższone uprawnienia, jeśli są obecne. WordPress zazwyczaj potrzebuje SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX.
    • Ogranicz dostęp do bazy danych tylko do hosta serwera WWW.
  6. Tymczasowo usuń lub izoluj publicznie dostępny formularz wyszukiwania
    • Jeśli twój motyw lub strona korzysta z publicznego wyszukiwania, które zapytuje wtyczkę, rozważ tymczasowe ukrycie formularza lub zastąpienie go stroną wyników z pamięci podręcznej po stronie serwera.

Wskazówki dotyczące reguł WAF (najlepsze praktyki wirtualnego łatania)

Jako dostawca WAF i zespół ds. bezpieczeństwa, WP-Firewall zaleca podejście warstwowe w wykrywaniu:

  • Pozytywne bezpieczeństwo (lista dozwolonych) dla punktów końcowych admin/API, gdzie to możliwe.
  • Reguły kontekstowe dla punktów końcowych specyficznych dla wtyczek (blokuj podejrzane tokeny, gdy ścieżka lub odsyłacz wskazują na obsługiwacze The Events Calendar).
  • Wykrywanie heurystyczne: oznaczaj i blokuj żądania, w których ciągi zapytań zawierają metaznaki SQL połączone z słowami kluczowymi SQL.

Sugerowana logika reguły (pseudokod — dostosuj i przetestuj przed wdrożeniem):

  • Jeśli ścieżka żądania pasuje do punktów końcowych wtyczki (np. zawiera /wydarzenia/ lub znane punkty końcowe wtyczki AJAX/REST) LUB odsyłacz pasuje do stron witryny, na których używana jest wyszukiwarka wtyczki, wtedy:
  • Jeśli parametr zapytania S (lub jakikolwiek parametr zapytania) zawiera oba:
    • słowo kluczowe SQL (niewrażliwe na wielkość liter dla SELECT|UNION|INSERT|UPDATE|DELETE|DROP|INFORMATION_SCHEMA) ORAZ
    • znak meta SQL lub komentarz (--, ;, /*, */, ' LUB ", xp_),
  • Następnie zablokuj lub wyzwij za pomocą CAPTCHA (daj legalnym użytkownikom szansę na udowodnienie, że są ludźmi).

Unikaj twardego blokowania wszystkiego z słowem “select” — to spowoduje fałszywe pozytywy. Użyj warunków łączonych i najpierw ustaw tryb monitorowania, aby dostosować zasady.

Jak wykryć próby lub udane wykorzystanie

Wykrywanie jest krytyczne zarówno przed, jak i po incydencie. Szukaj tych sygnałów:

  1. Serwer WWW / dzienniki dostępu
    • Żądania GET/POST do stron wydarzeń lub punktów końcowych wyszukiwania, które zawierają słowa kluczowe SQL, komentarze lub długie zakodowane ciągi w ciągach zapytań.
    • Nagły wzrost żądań do tego samego punktu końcowego z tego samego zakresu IP.
  2. Dzienniki aplikacji i alerty WAF
    • Dopasowania reguł WAF dla wzorców SQLi, szczególnie nieautoryzowanych żądań.
    • Powtarzające się odpowiedzi 400/403/500 w okolicy tego samego znacznika czasu.
  3. Anomalie w bazie danych
    • Niespodziewane zmiany w wp_users, wp_usermeta (nowe konta administratorów, zmiany w możliwościach ról).
    • Nowe wiersze lub modyfikacje tabel zarządzanych przez wtyczkę The Events Calendar.
    • Niespodziewany wzrost aktywności odczytu bazy danych lub długoterminowych zapytań (atakujący czasami używają SQLi opartego na czasie, aby wydobyć dane).
  4. Kontrole integralności
    • Zmodyfikowane pliki rdzenia/wtyczki/motywu (zmienione znaczniki czasu, nieznane pliki PHP).
    • Różnice między haszami plików a znanym dobrym punktem odniesienia.
  5. Znaki behawioralne na stronie
    • Nieoczekiwane treści dodane do stron, przekierowania, wstrzyknięty JavaScript lub nieznane zdarzenia cron.
    • Użytkownicy administracyjni zgłaszający dziwne zachowanie lub niemożność zalogowania się.

Jeśli widzisz wiele z powyższych sygnałów, załóż kompromitację i postępuj zgodnie z poniższymi krokami śledczymi.

Kroki dochodzeniowe i naprawcze, jeśli podejrzewasz kompromitację

Jeśli podejrzewasz wykorzystanie lub wykrywasz podejrzaną aktywność, postępuj zgodnie z ostrożnym planem reakcji na incydenty. Priorytetem jest ograniczenie i zachowanie dowodów.

  1. Zawierać
    • Tymczasowo zablokuj publiczny dostęp do strony lub dotkniętych punktów końcowych (strona konserwacji).
    • Jeśli używasz WAF, przełącz się na surowy profil blokowania na dotkniętych ścieżkach.
    • Zmień dane uwierzytelniające dla kont na poziomie administratora oraz kont hostingowych/SSH (nie używaj haseł obecnych w kopiach zapasowych, które mogą być skompromitowane).
  2. Zachowaj dowody
    • Zachowaj pełne logi serwera (web, PHP, DB) z dokładnymi znacznikami czasu.
    • Utwórz obraz śledczy (obraz dysku lub kopię zapasową na poziomie plików) oraz zrzut bazy danych do analizy offline.
    • Nie przeprowadzaj agresywnego czyszczenia przed dochodzeniem; możesz zniszczyć dowody potrzebne do zrozumienia naruszenia.
  3. Zidentyfikuj zakres kompromitacji 
    wp db query "SELECT ID,user_login,user_email,user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 50;"
    znajdź /var/www/html -type f -name "*.php" -mtime -7 -print

    Sprawdź wp_options pod kątem nieoczekiwanych zmian siteurl/home lub nowych opcji autoloaded.

  4. Usuń trwałość.
    • Usuń pliki backdoor i powłoki PHP. Potwierdź usunięcie we wszystkich katalogach, które można zapisywać (uploads, katalogi wtyczek, katalogi motywów).
    • Usuń złośliwe zaplanowane zdarzenia (wp_cron entries).
    • Usuń wszelkie nieznane konta administratorów oraz wszelkie loginy związane z podejrzaną aktywnością (zapisz identyfikatory użytkowników przed usunięciem do logów audytowych).
  5. Oczyść i przywróć
    • Jeśli kompromitacja jest ograniczona i masz niedawną czystą kopię zapasową, przywróć z kopii zapasowej wykonanej przed naruszeniem. Zweryfikuj kopie zapasowe offline przed przywróceniem.
    • Zainstaluj ponownie rdzeń, motywy i wtyczki z zaufanych źródeł (pobierz świeże kopie).
    • Zaktualizuj wszystko do najnowszych wersji (rdzeń WordPress, wtyczki, motywy).
  6. Walidacja i monitorowanie
    • Po oczyszczeniu, wzmocnij i stopniowo przywracaj usługę.
    • Uważnie monitoruj ruch i logi przez co najmniej kilka tygodni w celu wykrycia nawrotów.
    • Rozważ profesjonalny audyt kodu i złośliwego oprogramowania w przypadku incydentów o dużym wpływie.
  7. Publiczne ujawnienie i zgodność
    • Jeśli dane klientów lub dane osobowe zostały ujawnione, rozważ obowiązki prawne/umowne (wymagania dotyczące powiadamiania, przepisy dotyczące prywatności).
    • Powiadom dostawcę hostingu i wszelkie strony trzecie, jeśli to konieczne.

Długoterminowe wzmocnienie i zapobieganie

Aby zmniejszyć szansę na podobne incydenty, przyjmij strategię obrony w głębokości.

  1. Utrzymuj aktualizacje na czas
    • Stwórz politykę: testuj i wdrażaj aktualizacje wtyczek i rdzenia w krótkim czasie (najlepiej w ciągu 24–72 godzin w przypadku problemów o wysokiej wadze).
    • Użyj środowiska testowego do testowania zgodności i zautomatyzowanej strategii aktualizacji dla pilnych poprawek.
  2. Pełny inwentarz wtyczek i ocena ryzyka
    • Śledź, które wtyczki są zainstalowane, aktywne i ich daty ostatnich aktualizacji.
    • Natychmiast dezaktywuj i usuń nieużywane wtyczki.
  3. Zasada najmniejszych uprawnień
    • Zmniejsz uprawnienia użytkowników bazy danych.
    • Używaj silnych uprawnień do plików i katalogów (zapobiegaj plikom zapisywalnym przez wszystkich).
    • Używaj oddzielnych kont użytkowników do administracji — nie używaj wspólnych poświadczeń.
  4. Używaj warstwowych zabezpieczeń
    • WAF z regułami specyficznymi dla aplikacji i możliwością wirtualnego łatania.
    • Monitorowanie integralności plików (FIM) w celu wykrywania manipulacji.
    • Regularne skanowanie złośliwego oprogramowania i zaplanowane audyty.
  5. Wymuszanie uwierzytelniania wieloskładnikowego (MFA) i silnych polityk haseł dla użytkowników administracyjnych
    • Połączenie z kontrolą dostępu opartą na rolach.
  6. Kopie zapasowe i plany odzyskiwania
    • Utrzymywanie niezmiennych kopii zapasowych w lokalizacji zewnętrznej i okresowe testowanie przywracania.
    • Zachowanie czystej, znanej kopii Twojej witryny i bazy danych.
  7. Rejestrowanie i powiadamianie
    • Centralizacja logów (web, aplikacja, baza danych) i ustawienie alertów na anomalie.
    • Przechowywanie logów przez odpowiedni okres retencji dla potrzeb kryminalistycznych.

Szybka lista kontrolna

Użyj tej listy kontrolnej teraz, jeśli prowadzisz The Events Calendar:

  • Zidentyfikuj wersję wtyczki (6.15.1.1 — 6.15.9 podatna)
  • Natychmiast zaktualizuj do 6.15.10 (zalecane)
  • Jeśli aktualizacja nie jest możliwa, dezaktywuj wtyczkę lub zastosuj wirtualną łatkę WAF
  • Wykonaj kopię zapasową plików i bazy danych przed wprowadzeniem dużych zmian
  • Zastosuj tymczasowe zabezpieczenia na poziomie serwera (limit szybkości, zasady .htaccess/nginx)
  • Przejrzyj logi pod kątem podejrzanych S użycia parametrów i słów kluczowych SQL
  • Skanuj w poszukiwaniu nieoczekiwanych kont administracyjnych, nowych plików i zmodyfikowanych plików
  • Rotuj krytyczne poświadczenia i włącz MFA dla użytkowników administracyjnych
  • Zaplanuj przegląd bezpieczeństwa po incydencie i plan wzmocnienia zabezpieczeń

Uzyskaj natychmiastową zarządzaną ochronę z WP-Firewall (Plan darmowy)

Natychmiastowe zabezpieczenie witryny — Zacznij od WP-Firewall Basic (Darmowy)

Jeśli potrzebujesz szybkiej, zarządzanej ochrony podczas planowania aktualizacji i kontroli forensycznych, plan WP-Firewall Basic (Darmowy) zapewnia natychmiastowe warstwy obrony:

  • Podstawowa ochrona: zarządzana zapora sieciowa, nieograniczona przepustowość, WAF, skaner złośliwego oprogramowania.
  • Ograniczenie ryzyk OWASP Top 10.
  • Łatwe wprowadzenie i możliwość wirtualnego łatania, aby zablokować próby wykorzystania bez czekania na aktualizacje.

Zacznij chronić swoją witrynę w ciągu kilku minut i zmniejsz narażenie na zautomatyzowane ataki oraz próby wykorzystania na dużą skalę. Zarejestruj się w darmowym planie i uzyskaj podstawową ochronę witryny teraz: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Przejście na płatne plany dodaje automatyczne usuwanie złośliwego oprogramowania, czarną/białą listę adresów IP, miesięczne raporty i automatyczne wirtualne łatanie dla krytycznych luk.)

Dodatek — Przydatne polecenia i odniesienia WP-CLI

Sprawdź zainstalowaną wtyczkę i wersję:

wp plugin list --format=table

lub aby filtrować

wp plugin update the-events-calendar --version=6.15.10

Dezaktywuj wtyczkę:

wp plugin deactivate the-events-calendar

wp plugin list --name=the-events-calendar --format=json

Zaktualizuj wtyczkę za pomocą WP-CLI:

Wyszukaj niedawno zmodyfikowane pliki PHP (przykład):

wp db query "SELECT ID,user_login,user_email,user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 50;"

find /var/www/html -type f -name '*.php' -mtime -14 -print

Zrzut ostatnich wpisów wp_users:

Utwórz zrzut bazy danych (zachowaj dowody):

Ostateczne uwagi od zespołu bezpieczeństwa WP-Firewall

Ta luka jest podręcznikowym przykładem, dlaczego terminowe łatanie i obrona w głębokości mają znaczenie. Łatanie powinno być twoim pierwszym planem działania. Gdy natychmiastowe łatanie nie jest możliwe, wirtualne łatanie za pomocą zarządzanego WAF i innych środków kompensacyjnych może znacznie zmniejszyć ryzyko, podczas gdy weryfikujesz aktualizacje i przeprowadzasz staranny rollout.

Jeśli jesteś właścicielem lub administratorem strony i potrzebujesz pomocy, WP-Firewall oferuje zarządzane łagodzenie, monitorowanie w czasie rzeczywistym i wirtualne łatanie, aby chronić strony w krytycznych oknach. Rozważ rozpoczęcie od darmowego planu dla szybkiej ochrony podstawowej, a następnie ocenę planów Standard lub Pro dla automatycznej naprawy, usuwania i ciągłego monitorowania.

Bądź czujny: traktuj publiczne ujawnienia nieautoryzowanych luk jako incydenty wysokiego priorytetu. Napastnicy już skanują; różnica między byciem celem a ofiarą polega na tym, jak szybko odpowiesz.

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.

Skontaktuj się z nami, aby zaplanować bezpłatną konsultację dotyczącą bezpieczeństwa WordPress

Skontaktuj się z nami

Zapora sieciowa WP
6/F, The Rays, 71 Hung To Road, Kwun Tong, Kowloon, Hongkong

Cechy Wycena Blog Login
Polityka prywatności Warunki korzystania z usługi Dokumenty Przyłączać

© 2026 WP-Firewall™