Nazwa wtyczki	Monki
Rodzaj podatności	Lokalne włączenie plików
Numer CVE	CVE-2025-24769
Pilność	Wysoki
Data publikacji CVE	2026-04-25
Adres URL źródła	CVE-2025-24769

Lokalna Włączenie Plików w Motywie WordPress Monki (≤ 2.0.5): Co Musisz Wiedzieć (CVE‑2025‑24769)

Streszczenie

• Wysokoprioritetowa luka w Lokalnym Włączeniu Plików (LFI) dotyczy wersji motywu WordPress Monki do i włącznie z 2.0.5.
• CVE: CVE‑2025‑24769. CVSS/Severność: CVSS ~8.1 (Wysoka).
• Uwierzytelnienie: Brak — nieautoryzowani atakujący mogą wywołać problem.
• Naprawione w wersji 2.0.6. Jeśli nie możesz zaktualizować natychmiast, zdecydowanie zaleca się wirtualne łatanie za pomocą WAF.

Ten post jest napisany z perspektywy WP‑Firewall — dostawcy zapory i zabezpieczeń WordPress — przez nasz zespół ds. bezpieczeństwa z praktycznymi, krok po kroku wskazówkami, które możesz wdrożyć już dziś.

---

Dlaczego ta podatność ma znaczenie

Luki w Lokalnym Włączeniu Plików pozwalają atakującym oszukać aplikację po stronie serwera, aby włączyła i zwróciła zawartość plików z lokalnego systemu plików. Na stronach WordPress często oznacza to ujawnienie wrażliwych plików, takich jak:

• wp-config.php (poświadczenia bazy danych)
• .env lub inne pliki konfiguracyjne
• Pliki kopii zapasowej lub archiwalne przechowywane w katalogu głównym
• Pliki dziennika zawierające sekrety lub ciasteczka

Ponieważ problem z motywem Monki można zdalnie wykorzystać przez nieautoryzowanych użytkowników, jest on szczególnie niebezpieczny: może być wykorzystywany w masowych kampaniach eksploatacyjnych przeciwko tysiącom stron, zautomatyzowanym skanerom i oportunistycznym atakującym.

---

Krótkie techniczne podsumowanie (na wysokim poziomie, bezpieczne)

Luka to Lokalna Włączenie Plików (LFI). W podatnych wersjach motyw akceptuje dane wejściowe (na przykład parametr lub ścieżkę), które są później używane do załadowania lokalnego pliku bez odpowiedniej walidacji lub sanitizacji. Jeśli aplikacja łączy dane wejściowe użytkownika w ścieżkę pliku, a następnie włącza lub wyświetla zawartość pliku, sekwencje przejścia katalogu (../) lub bezpośrednie ścieżki mogą być używane do odczytu lokalnych plików.

Kluczowe atrybuty:

• Dane wejściowe nie są sanitizowane / nie są walidowane w stosunku do listy dozwolonych.
• Ścieżka danych wejściowych użytkownika jest używana do skonstruowania ścieżki systemu plików, a następnie włączana lub wyświetlana.
• Nie są wymagane żadne uprawnienia do wywołania podatnej ścieżki kodu.

Ponieważ wrażliwy kod działa w kontekście serwera WWW i procesu PHP, wszelkie lokalne pliki, które mogą być odczytywane przez konto serwera WWW, są potencjalnie narażone.

---

Scenariusze wpływu w rzeczywistym świecie

1. Kradzież danych uwierzytelniających i kompromitacja bazy danych
   • Atakujący odczytuje wp-config.php, który zawiera dane uwierzytelniające do bazy danych. Następnie używają tych danych do połączenia z bazą danych, wykradania danych użytkowników, tworzenia kont administratorów lub dalszej eskalacji.
2. Pełne przejęcie witryny
   • Odczytywanie plików kopii zapasowych, plików dziennika lub plików kluczy prywatnych może ułatwić eskalację i utrzymanie dostępu. Atakujący mogą przesyłać tylne drzwi do katalogów, w których można zapisywać, i tworzyć użytkowników administratorów za pomocą dostępu do bazy danych.
3. Ujawnienie informacji i pivotowanie
   • Ujawnione szczegóły konfiguracji lub zmienne środowiskowe pozwalają atakującym na tworzenie bardziej ukierunkowanych ataków przeciwko twojemu hostowi, innym stronom internetowym lub nawet wewnętrznym usługom.
4. Masowe wykorzystanie i spam SEO
   • Atakujący automatyzują exploit, aby dodawać spam, tworzyć strony phishingowe lub używać twojej witryny jako punktu dystrybucji złośliwego oprogramowania, co wpływa na SEO i reputację.

---

Wskaźniki wykrywania — na co zwracać uwagę

Monitoruj logi i alerty WAF w poszukiwaniu tych podejrzanych wzorców:

• Żądania zawierające sekwencje przechodzenia przez katalogi: ../ Lub ..
• Parametry z wartościami, które wydają się być ścieżkami systemu plików: /etc/passwd, wp-config.php, .env, /var/www/
• Żądania do punktów końcowych motywów z nietypowymi parametrami zapytania, takimi jak ?file=, ?page=, ?template=, ?theme_file=, ?ścieżka=
• Niespodziewane odpowiedzi 200, które zwracają tekst zwykły z stałymi konfiguracyjnymi PHP lub hasłami do bazy danych
• Wzrost liczby odpowiedzi 404/200 z tego samego zakresu IP skanującego ścieżki motywów

Przykład (ogólny, nie‑exploit) wzorców logów do wyszukiwania:

• GET /wp-content/themes/monki/some-endpoint?file=../../../../wp-config.php
• GET /wp-content/themes/monki/?template=/etc/passwd

Uwaga: Nie próbuj reprodukować eksploatacji na stronie produkcyjnej. Do testów użyj izolowanego środowiska stagingowego.

---

Potwierdzone fakty dotyczące tej podatności motywu Monki

• Affected software: Motyw WordPress Monki (typ motywu).
• Wersje podatne: ≤ 2.0.5.
• Naprawione w: 2.0.6 (aktualizacja zalecana).
• CVE: CVE‑2025‑24769 (odniesienie zawarte przez badania bezpieczeństwa).
• Wymagane uprawnienia: Brak (nieautoryzowany).
• Klasa OWASP: A3 / Wstrzyknięcie (LFI jest uważane za błąd typu wstrzyknięcia, ponieważ wstrzykuje przepływ włączenia pliku).
• Priorytet łaty: Wysoki — zastosować natychmiast.

---

Natychmiastowe kroki zaradcze (zalecana kolejność)

1. Zaktualizuj motyw do 2.0.6 (lub nowszej) natychmiast
   • To jest jedyna prawdziwa poprawka. Autorzy motywu poprawili obsługę wejścia, aby zapobiec LFI.
2. Jeśli nie możesz zaktualizować od razu, zastosuj wirtualne łatanie za pośrednictwem swojego WAF
   • Blokuj podejrzane wzorce żądań, które próbują przejścia katalogowego lub przekazują podejrzane parametry ścieżki.
   • Całkowicie zablokuj dostęp do podatnego punktu końcowego motywu, jeśli to możliwe (reguła odmowy dla ścieżki punktu końcowego).
3. Wzmocnij uprawnienia plików i przenieś wrażliwe pliki poza katalog główny, jeśli to możliwe
   • Upewnij się, że uprawnienia do wp-config.php są restrykcyjne (np. 640) i należą do odpowiedniego użytkownika.
   • Zapobiegaj przechowywaniu kopii zapasowych lub archiwów w katalogu głównym.
4. Monitoruj logi i alerty
   • Tymczasowo zwiększ poziom logowania, obserwuj aktywność skanowania i zapisuj podejrzane logi żądań do celów kryminalistycznych.
5. Zmień hasła i dane uwierzytelniające bazy danych, jeśli wykryjesz jakiekolwiek oznaki kompromitacji
   • Jeśli znajdziesz dowody, że pliki konfiguracyjne były odczytywane, rozważ rotację danych uwierzytelniających bazy danych i ponowną ocenę tokenów dostępu.

---

Dlaczego wirtualne łatanie jest konieczne (i jak WP‑Firewall pomaga)

Nawet gdy łata istnieje, wiele stron opóźnia aktualizacje z powodu dostosowań, cykli testowych lub opóźnień administracyjnych. Wirtualne łatanie (reguła WAF) blokuje próby wykorzystania na poziomie HTTP, aby atakujący nie mogli dotrzeć do podatnej ścieżki kodu, podczas gdy planujesz testowanie i bezpieczną aktualizację.

WP‑Firewall zapewnia następujące odpowiednie zabezpieczenia:

• Zarządzane zasady WAF dostosowane do wzorca Monki LFI (blokuje znane sygnatury exploitów i próby przejścia do katalogu).
• Niskie fałszywe alarmy wirtualnego łatania, aby normalne operacje na stronie mogły się odbywać, podczas gdy niebezpieczne żądania są blokowane.
• Skaner złośliwego oprogramowania i monitorowanie w celu wykrycia, czy luka została wykorzystana przed załataniem.

Przykład logiki zasad obronnych (koncepcyjny):

Dopasuj, jeśli:

Rzeczywisty zestaw reguł WP‑Firewall zawiera zaawansowane kodowania, wiele kontroli (nagłówki, zachowanie agenta użytkownika, limity szybkości) oraz precyzyjnie dostosowane wyjątki, aby uniknąć blokowania legalnego ruchu.

---

Praktyczne sygnatury WAF i wzorce obronne (wyjaśnienie, bezpieczne)

Przy tworzeniu zasad WAF dla LFI, weź pod uwagę następujące elementy:

• Wykrywanie przejścia do katalogu
  • Wzorce do wykrycia: "../", "..", "", "", mieszane kodowania
  • Normalizuj dane wejściowe przed dopasowaniem (dekoduj kodowania URL, normalizacja Unicode)
• Znane wrażliwe nazwy plików
  • wp-config.php, .env, .htpasswd, id_rsa, id_dsa, authorized_keys, .git/config, .svn/entries
• Podejrzane nazwy parametrów w punktach końcowych motywów
  • plik, szablon, dołącz, strona, ścieżka, widok, tpl, skórka
• Metoda żądania i heurystyki odsyłacza
  • Żądania POST z parametrami ścieżki pliku, które generują natychmiastowe odpowiedzi na treść, są podejrzane
  • Żądania bez referrera trafiające na punkty końcowe motywu mogą być aktywnością skanowania
• Ograniczanie szybkości i reputacja IP
  • Zastosuj limity szybkości dla wzorców skanowania i zastosuj ocenę reputacji, aby zablokować agresywnych skanerów.

Przykładowa reguła (koncepcyjny fragment regex do wykrywania znormalizowanej ścieżki):

(?i)(\.\.(/|%2[fF]|%5[cC]|2[fF]))|((wp-config\.php)|(\.env)|(/etc/passwd))

Ważny: Twórz reguły, które dekodują dane wejściowe, sprawdzają zarówno ciąg zapytania, jak i informacje o ścieżce, i unikają naiwnego blokowania jakiegokolwiek parametru o nazwie “file”, ponieważ niektóre legalne wtyczki/motywy mogą używać tego parametru.

---

Lista kontrolna wzmacniania dla operatorów stron

• Zaktualizuj motyw Monki do wersji 2.0.6 lub nowszej.
• Przeprowadź pełne skanowanie strony pod kątem złośliwego oprogramowania i integralności.
• Przejrzyj logi serwera WWW i aplikacji w poszukiwaniu podejrzanych wzorców LFI.
• Tymczasowo ogranicz dostęp do katalogów motywów za pomocą reguły WAF.
• Upewnij się, że uprawnienia do plików i katalogów są restrykcyjne (konfiguracje nie są dostępne do odczytu dla wszystkich).
• Wyłącz wykonywanie plików PHP w katalogach przesyłania i motywów, gdzie nie jest to wymagane.
• Usuń lub przenieś kopie zapasowe, pliki .zip, .tar poza katalog główny.
• Zmień wszelkie poświadczenia, jeśli występuje podejrzana aktywność.
• Wdróż monitorowanie i powiadamianie (zmiany plików, nowi użytkownicy, podejrzane żądania).

---

Jak deweloperzy powinni naprawić podstawowy kod (dla autorów motywów)

Poprawka na poziomie aplikacji powinna opierać się na tych zasadach:

1. Użyj listy dozwolonej (nie czarnej listy)
   • Zdefiniuj wyraźną listę akceptowalnych plików lub zasobów i zezwól tylko na te. Na przykład, jeśli motyw musi zawierać mały zestaw szablonów, mapuj logiczne nazwy na nazwy plików w kodzie serwera — nigdy nie dołączaj dowolnych ścieżek dostarczonych przez użytkownika.
2. Normalizuj i waliduj dane wejściowe
   • Użyj realpath() i porównaj z znanym bezpiecznym katalogiem bazowym. Odrzuć wszelkie dane wejściowe, w których rozwiązana ścieżka opuszcza zamierzony katalog.
3. Unikaj bezpośrednich włączeń systemu plików z danych wejściowych użytkownika
   • Preferuj mapowanie identyfikatorów do znanych nazw plików zamiast włączania na podstawie danych wejściowych ścieżki.
4. Escapuj wyjścia i nigdy nie wyświetlaj zawartości plików, chyba że jest to wyraźnie zamierzone
   • Przy zwracaniu plików upewnij się, że aplikacja zwraca tylko zamierzone typy zawartości i egzekwuje kontrole uprawnień.

Bezpieczny wzór przykładu dla podejścia z listą dozwoloną (pseudo‑PHP):

$allowed_templates = [

Nigdy nie rób:

// niebezpieczne: NIE używaj; podatne na LFI;

---

Jeśli podejrzewasz, że Twoja strona została już wykorzystana

Jeśli Twoje logi lub skany sugerują wykorzystanie, postępuj zgodnie z listą kontrolną reakcji na incydenty:

1. Izolować: Wprowadź stronę w tryb konserwacji i zablokuj ruch z podejrzanych adresów IP.
2. Zachowaj dowody: Zapisz logi, zrzuty żądań, migawki stanu serwera do celów kryminalistycznych.
3. Skanuj: Przeprowadź kompleksowe skanowanie złośliwego oprogramowania i sprawdzenie integralności plików (porównaj z czystymi kopiamy zapasowymi).
4. Zidentyfikuj punkt wejścia: Szukaj zmodyfikowanych plików, powłok webowych, nowych użytkowników administratora lub podejrzanych zadań cron.
5. Usuń trwałość: Usuń powłoki webowe, przywróć zmodyfikowane pliki do znanych dobrych wersji i usuń podejrzanych użytkowników.
6. Obracanie sekretów: Zmień dane uwierzytelniające bazy danych, klucze API i wszelkie tokeny znalezione w ujawnionych plikach.
7. Przywróć: Jeśli to konieczne, przywróć z zweryfikowanej czystej kopii zapasowej i zastosuj wszystkie aktualizacje zabezpieczeń.
8. Po incydencie: Zaktualizuj polityki wzmacniania, zastosuj wirtualne poprawki WAF i monitoruj uważnie.

Jeśli nie czujesz się komfortowo wykonując wszystkie te kroki, skontaktuj się z doświadczonym specjalistą WordPress lub zarządzaną usługą bezpieczeństwa.

---

Zalecana konfiguracja WP‑Firewall dla tego LFI

Poniższy zarys konfiguracji to to, co nasi inżynierowie ds. bezpieczeństwa zazwyczaj stosują, aby chronić witryny przed lukami LFI, takimi jak problem Monki. Dokładne zasady są wdrażane w naszym zarządzanym konsoli WAF z poprawkami, aby uniknąć fałszywych alarmów.

• Zasada 1: Zablokuj próby przechodzenia przez katalogi
  • Normalizuj dane wejściowe i blokuj żądania zawierające ../ Lub %2e%2e sekwencje w URL, zapytaniu lub ścieżce.
• Zasada 2: Blokuj żądania, które odnoszą się do wrażliwych plików
  • Blokuj każde żądanie, w którym parametry lub ścieżka zawierają wzorce takie jak wp-config.php, .env, /etc/passwd, .git
• Zasada 3: Ogranicz dostęp do wrażliwego punktu końcowego motywu
  • Dla witryn korzystających z Monki, zablokuj bezpośredni dostęp do wewnętrznych elementów motywu, które nie są wymagane do dostarczania na frontend (na przykład, zablokuj punkty końcowe pobierania szablonów).
• Zasada 4: Ogranicz zachowanie skanowania
  • Zastosuj tymczasowe limity szybkości IP na punktach końcowych, które otrzymują podejrzane wzorce zapytań.
• Zasada 5: Rejestrowanie i powiadamianie
  • Powiadomienia o wysokim priorytecie do e-maila/SMS administratora oraz przechowywanie surowych ładunków zapytań przez 30 dni.

Uwaga: Zasady WP‑Firewall są najpierw testowane w trybie “obserwacji” na produkcji przez krótki okres, aby dostroić i zredukować fałszywe alarmy przed włączeniem blokowania.

---

Testowanie po zastosowaniu łagodzenia

Po zaktualizowaniu motywu i włączeniu zasad WAF, zweryfikuj:

• Testy funkcjonalności: Przejdź przez witrynę i jej krytyczne strony (logowanie, realizacja zamówienia, jeśli e‑commerce, formularze), aby upewnić się, że nic nie jest zepsute.
• Kontrola fałszywych alarmów: Szukaj legalnych żądań, które zostały zablokowane i dodaj dostosowane wyjątki tam, gdzie to konieczne.
• Walidacja penetracji: Użyj zaufanego środowiska stagingowego do przeprowadzenia testów bezpieczeństwa (unikaj uruchamiania aktywnych exploitów na produkcji).
• Dzienniki audytu: Potwierdź, że WP‑Firewall rejestruje i powiadamia oraz że zablokowane próby są rejestrowane.

---

Długoterminowe zapobieganie i najlepsze praktyki

• Szybko aktualizuj wszystkie motywy, wtyczki i rdzeń WordPressa.
• Uruchom zarządzany WAF i zautomatyzowaną usługę wirtualnego łatania luk.
• Użyj zasady najmniejszych uprawnień dla uprawnień plików i kont bazy danych.
• Wzmocnij wp-admin: ogranicz dostęp według IP tam, gdzie to możliwe, i włącz silne 2FA dla użytkowników administracyjnych.
• Przechowuj kopie zapasowe poza siedzibą i poza katalogiem głównym; regularnie testuj przywracanie.
• Utrzymuj inwentarz motywów/wtyczek i usuwaj nieużywane komponenty.
• Używaj stron stagingowych i automatycznych przepływów testowych aktualizacji, gdy to możliwe.

---

Często zadawane pytania dotyczące bezpieczeństwa związane z LFI

Q: Czy LFI zawsze prowadzi do zdalnego wykonania kodu (RCE)?
A: Nie zawsze. LFI odczytuje lokalne pliki. RCE może wystąpić, gdy pliki dziennika lub katalogi przesyłania z treścią kontrolowaną przez atakującego są uwzględnione (na przykład, jeśli atakujący może zapisać PHP do dziennika, a następnie go uwzględnić). Środki zaradcze koncentrują się na zapobieganiu odczytom plików i kontrolowaniu uprawnień do zapisu.

Q: Czy exploit LFI jest wykrywalny przez programy antywirusowe?
A: Narzędzia AV mogą wykrywać powłoki sieciowe lub złośliwe oprogramowanie zainstalowane po wykorzystaniu, ale często pomijają początkowe żądania odczytu LFI. WAF i rejestrowanie żądań to główne obrony.

Q: Czy powinienem wymienić motyw, jeśli go mocno dostosowałem?
A: Jeśli nie możesz zaktualizować z powodu dostosowań, stwórz motyw podrzędny i przenieś dostosowania do zaktualizowanej wersji motywu. W międzyczasie wirtualne łatanie za pomocą WAF jest niezbędne.

---

Harmonogram i zalecana pilność

• Łata dostępna: 2.0.6 (zastosuj natychmiast).
• Jeśli aktualizacja nie jest możliwa w ciągu 24–72 godzin, natychmiast włącz wirtualne łatanie WAF i surowsze rejestrowanie.
• Skanuj w poszukiwaniu kompromitacji i zmień dane uwierzytelniające, jeśli zauważysz jakąkolwiek podejrzaną aktywność.

---

Jak WP‑Firewall wspiera Cię podczas luk w zabezpieczeniach

Jako WP‑Firewall oferujemy:

• Zarządzane, dostosowane wirtualne łatki wdrażane szybko, aby zablokować próby wykorzystania na poziomie HTTP.
• Ciągłe aktualizacje zestawów reguł, gdy pojawiają się nowe sygnatury luk w zabezpieczeniach.
• Wykrywanie złośliwego oprogramowania i opcjonalne usługi automatycznego usuwania (w zależności od planu).
• Monitorowanie, raportowanie i fachowe doradztwo w celu naprawy i wzmocnienia instalacji WordPress.

Łączymy automatyczną ochronę z ludzkimi operacjami bezpieczeństwa, aby zredukować fałszywe alarmy i zapewnić, że Twoja strona działa normalnie, pozostając jednocześnie chroniona.

---

Szybka ochrona Twojej strony — darmowy plan WP‑Firewall

Jeśli jeszcze nie zabezpieczyłeś swojej strony, zacznij od naszego darmowego planu podstawowego i zyskaj natychmiastową, niezbędną ochronę. Plan podstawowy (darmowy) obejmuje:

• Zarządzany firewall i WAF
• Nieograniczona ochrona przepustowości
• Skaner złośliwego oprogramowania
• Ograniczenia 10 największych ryzyk OWASP

Zarejestruj się tutaj, aby skorzystać z bezpłatnego planu: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Dlaczego warto spróbować darmowego planu teraz?

• Daje Ci natychmiastową możliwość wirtualnego łatania zagrożeń, takich jak Monki LFI, podczas gdy planujesz i testujesz aktualizacje motywów.
• Otrzymasz podstawowe monitorowanie i automatyczne zabezpieczenia reguł, aby zredukować ryzyko, aż będzie możliwa pełna aktualizacja.
• Brak kosztów na rozpoczęcie — później możesz przejść na plan Standard lub Pro, aby uzyskać automatyczne usuwanie, wirtualne łatanie luk w zabezpieczeniach i zaawansowane usługi zarządzane.

---

Przykładowy przepływ reakcji na incydent (zwięzły)

1. Wykrycie: WAF blokuje podejrzane próby LFI → uruchomienie alertu.
2. Triage: Przegląd próbek zablokowanych żądań i dzienników serwera.
3. Natychmiastowe ograniczenie: Zastosowanie wirtualnej łatki i zablokowanie naruszających adresów IP.
4. Naprawa: Aktualizacja motywu do wersji 2.0.6 i skanowanie w poszukiwaniu kompromitacji.
5. Odzyskiwanie: Rotacja sekretów i weryfikacja integralności strony.
6. Analiza po incydencie: Dokumentacja wniosków i wzmocnienie obrony (reguły WAF, limity, monitorowanie).

---

Zakończenie — pragmatyczne porady dotyczące bezpieczeństwa

• Najpierw aktualizacja. Jeśli możesz zrobić tylko jedną rzecz: natychmiast zaktualizuj motyw Monki do wersji 2.0.6 lub nowszej. To jest ostateczne rozwiązanie.
• Wirtualne łatanie nie jest zastępstwem dla aktualizacji, ale jest ratunkiem, gdy nie możesz natychmiast załatać. Użyj go, aby zmniejszyć okno narażenia.
• Rejestrowanie, monitorowanie i okresowe audyty to twój system wczesnego ostrzegania — upewnij się, że są aktywne i przeglądane.
• Jeśli nie jesteś pewien, czy twoja strona została dotknięta, skontaktuj się z profesjonalistą lub zaufanym dostawcą usług bezpieczeństwa, aby przejrzeć logi i zeskanować w poszukiwaniu kompromitacji.

Jeśli potrzebujesz pomocy w wdrażaniu powyższych środków zaradczych, konfigurowaniu bezpiecznej polityki WAF dla tej podatności lub przeprowadzaniu ukierunkowanego przeglądu incydentów, inżynierowie bezpieczeństwa WP‑Firewall są dostępni, aby pomóc. Zacznij od naszej darmowej podstawowej ochrony, aby uzyskać natychmiastowe pokrycie i zapoznaj się z naszymi planami Standard lub Pro, gdy potrzebujesz automatycznego usuwania złośliwego oprogramowania, wirtualnego łatania, miesięcznych raportów i zarządzanych usług.

---

Odniesienia i dalsza lektura

• CVE: CVE‑2025‑24769 (identyfikator podatności do odniesienia)
• OWASP Top 10: wskazówki dotyczące wstrzykiwania i dołączania plików
• Przewodniki dotyczące wzmocnienia WordPressa i najlepsze praktyki dotyczące uprawnień do plików

---

Autor

Zespół bezpieczeństwa WP‑Firewall — doświadczeni inżynierowie bezpieczeństwa WordPressa i respondenci incydentów. Tworzymy i utrzymujemy zasady WAF, wirtualne łaty i zarządzane usługi zaprojektowane w celu ochrony stron WordPress przed obecnymi i pojawiającymi się zagrożeniami.