| Nazwa wtyczki | LearnPress |
|---|---|
| Rodzaj podatności | Rada dotycząca podatności |
| Numer CVE | CVE-2026-7648 |
| Pilność | Niski |
| Data publikacji CVE | 2026-05-13 |
| Adres URL źródła | CVE-2026-7648 |
Pilne: LearnPress <= 4.3.5 — Ominięcie płatności przez uwierzytelnionego subskrybenta (CVE-2026-7648) — Co właściciele stron WordPress muszą teraz zrobić
Data: 13 maja 2026
Autor: Zespół ds. bezpieczeństwa WP‑Firewall
Streszczenie
- Podatność w LearnPress (wtyczka LMS WordPress) w wersjach <= 4.3.5 pozwala uwierzytelnionym użytkownikom z rolą subskrybenta na ominięcie kontroli płatności i zapisanie się na płatne kursy bez kosztów.
- CVE: CVE-2026-7648. Łatka opublikowana w LearnPress 4.3.6.
- CVSS: 4.3 (Niska) — jednak wpływ na biznes może być istotny dla firm sprzedających kursy (straty przychodów, nadużycia).
- Natychmiastowe działanie: zaktualizuj LearnPress do 4.3.6 lub nowszej. Jeśli natychmiastowa aktualizacja nie jest możliwa, zastosuj opisane poniżej środki łagodzące i monitorowanie.
Ten post prowadzi właścicieli stron, programistów i hostów przez praktyczną ocenę zagrożeń, podejście do wykrywania, kroki ograniczające i łagodzące, zalecane zabezpieczenia WAF (jak my w WP‑Firewall do tego podchodzimy), najlepsze praktyki wzmacniania oraz działania po incydencie. Celem jest umożliwienie spokojnej, kontrolowanej reakcji, która ogranicza straty i przywraca zaufanie.
Spis treści
- Czym jest luka (na wysokim poziomie)
- Dlaczego to ma znaczenie (wpływ na biznes i bezpieczeństwo)
- Analiza techniczna (jak problem się manifestuje)
- Kto jest narażony na ryzyko
- Natychmiastowe kroki (co zrobić teraz)
- Jeśli nie możesz zaktualizować od razu — tymczasowe środki zaradcze
- Wykrywanie i wskaźniki kompromitacji (na co zwrócić uwagę)
- Przykład WAF / wskazówki dotyczące reguł (wirtualne łatanie)
- Wzmacnianie i długoterminowa prewencja
- Lista kontrolna reagowania na incydenty
- Jak WP‑Firewall pomaga (funkcje do wykorzystania już teraz)
- Zabezpiecz swoje kursy już dziś — wypróbuj darmowy plan WP‑Firewall
- Dodatek: przydatne polecenia i kontrole
Czym jest luka (na wysokim poziomie)
LearnPress <= 4.3.5 zawiera błąd logiczny w swoim przepływie płatności/zapisu, który może być nadużywany przez uwierzytelnionych użytkowników (minimalne uprawnienia: subskrybent). W określonych sekwencjach żądań subskrybent może wywołać zapis na płatny kurs bez ważnej, zakończonej transakcji płatności. To jest ominięcie logiki biznesowej / autoryzacji: wtyczka nie weryfikuje konsekwentnie, że płatne zamówienie zostało przetworzone i zarejestrowane przed przyznaniem dostępu do kursu.
Krótko mówiąc: rola, która normalnie nie może zmieniać stanu płatności, może spowodować, że system potraktuje zakup kursu jako zakończony, przyznając dostęp do kursu za darmo.
Dlaczego to ma znaczenie (wpływ na biznes i bezpieczeństwo)
Technicznie podatność ma stosunkowo niski wynik CVSS. W praktyce jednak może spowodować:
- Straty przychodów dla firm kursowych (masowe darmowe zapisy).
- Oszukańczy dostęp do treści premium i materiałów kursowych.
- Zniekształcone dane dotyczące rejestracji i raportowania, komplikujące uzgadnianie finansowe.
- Potencjalne obawy dotyczące RODO / ochrony danych, jeśli dostęp do treści tylko dla studentów lub danych osobowych zostanie rozszerzony.
- Uszkodzenie reputacji, jeśli użytkownicy wykorzystają system i publicznie udostępnią treści premium.
Ponieważ wykorzystanie wymaga tylko konta Subskrybenta i nie ma wyraźnego eskalowania uprawnień, powierzchnia ataku jest szeroka na stronach, które pozwalają na publiczną rejestrację lub mają wielu użytkowników o niskim zaufaniu.
Kto jest narażony na ryzyko
- Strony używające wersji LearnPress <= 4.3.5, które oferują płatne kursy.
- Strony, które pozwalają na samodzielną rejestrację (otwarte konta Subskrybenta) lub akceptują wielu użytkowników o niskich uprawnieniach.
- Strony z niewystarczającym monitorowaniem zamówień i rejestracji.
- Strony, które opóźniają aktualizacje wtyczek przez długi czas.
Analiza techniczna (jak problem się manifestuje)
To jest problem logiczny/autoryzacyjny w przepływie rejestracji/płatności. Na wysokim poziomie:
- Oczekiwany przepływ: bramka płatności kończy transakcję → bramka powiadamia stronę (lub strona pyta) → wtyczka rejestruje zakończone zamówienie z weryfikacją po stronie serwera → wtyczka dodaje użytkownika do kursu.
- Obserwowany wadliwy przepływ: sekwencja żądań może spowodować, że wtyczka oznaczy zamówienie lub rejestrację jako zakończoną bez zweryfikowanej transakcji płatności, a dostęp do kursu zostanie przyznany.
- Minimalne wymagane uprawnienia: Subskrybent (uwierzytelniony użytkownik).
- Typowe wektory wykorzystania obejmują żądania POST/GET do punktów końcowych AJAX wtyczki lub punktów końcowych REST, które zarządzają zamówieniami/rejestracjami, ale szczególnie polegają na braku weryfikacji po stronie serwera lub liberalnych kontrolach dostępu.
Ponieważ luka znajduje się w logice wtyczki, samo zablokowanie jednego punktu końcowego może nie być wystarczające bez zajmowania się wszystkimi ścieżkami prowadzącymi do zmian stanu rejestracji.
Ważny: unikaj publicznego udostępniania kodu dowodowego koncepcji exploita. Robienie tego pomaga obrońcom, ale także pomaga atakującym. Wskazówki tutaj koncentrują się na wykrywaniu, łagodzeniu i zasadach obronnych.
Natychmiastowe kroki (co zrobić teraz)
- Zaktualizuj LearnPress do 4.3.6 (lub najnowszej)
– To jest najlepsza pojedyncza akcja. Programiści wtyczek opublikowali poprawkę w 4.3.6, która koryguje kontrole płatności/rejestracji.
– Jeśli zarządzasz wieloma stronami, wprowadź tę aktualizację za pomocą narzędzi zarządzających lub panelu kontrolnego hosta. - Jeśli nie możesz zaktualizować natychmiast, zastosuj tymczasowe środki łagodzące (następna sekcja).
- Audytuj ostatnie rejestracje i zamówienia pod kątem anomalii (patrz sekcja Wykrywanie poniżej).
- Wzmocnij rejestrację i dostęp subskrybentów:
– Wyłącz otwartą rejestrację, jeśli nie jest potrzebna.
– Wymagaj potwierdzenia e-mailowego dla kont.
– Rozważ lekkie CAPTCHA na formularzach rejestracyjnych. - Włącz pełne logowanie i przechowuj logi przez co najmniej 30 dni:
– Logi aplikacji, logi serwera WWW oraz wszelkie logi audytowe specyficzne dla wtyczek.
– Zbieraj ładunki żądań (uważaj na dane wrażliwe) oraz adresy IP.
Jeśli prowadzisz wiele stron, priorytetowo traktuj strony o dużym ruchu lub wysokich przychodach przy łatach.
Jeśli nie możesz zaktualizować od razu — tymczasowe środki zaradcze
Jeśli nie możesz od razu zastosować aktualizacji wtyczki, podejmij warstwowe tymczasowe kroki w celu zmniejszenia ryzyka:
A. Ogranicz możliwość rejestracji za pomocą kontroli po stronie serwera
- Wyłącz płatności i ustaw kursy na “tylko ręczna rejestracja” lub “prywatne” podczas łatania.
- Gdzie to możliwe, ustaw płatne kursy na wersję roboczą lub tymczasowo ogranicz dostęp do Administratorów i Instruktorów.
B. Ogranicz punkty końcowe według IP / roli (tymczasowo)
- Zablokuj dostęp do punktów końcowych AJAX lub REST wtyczki, które dokonują zmian w rejestracji z publicznej sieci, jeśli nie są wymagane do normalnej funkcjonalności strony. Na przykład:
- Ogranicz żądania admin-ajax zawierające konkretne akcje LearnPress do zalogowanych użytkowników z zaufanymi adresami IP.
- Użyj reguł zapory na poziomie hosta, aby odrzucić podejrzane zakresy IP.
C. Dodaj regułę WAF (wirtualna łatka)
- Utwórz regułę WAF, która blokuje podejrzane działania rejestracyjne bez odpowiednich tokenów weryfikacji płatności lub żądania, które próbują ustawić status zamówienia na “zrealizowane” bez ważnego nagłówka lub podpisu weryfikacji płatności. Zobacz wskazówki WAF poniżej.
D. Zmień możliwości subskrybentów (tymczasowo)
- Usuń możliwości, które mogą być nadużywane do zmian w rejestracji. Na przykład, przeprowadź audyt, które niestandardowe możliwości kontrolują rejestrację i usuń je z roli subskrybenta do czasu załatania.
- Uwaga: zmiana możliwości ról wiąże się z ryzykiem — przetestuj na etapie przed zastosowaniem na całej stronie.
E. Monitoruj i ograniczaj podejrzaną aktywność
- Włącz ograniczenie liczby żądań na punktach końcowych związanych z rejestracją, aby utrudnić masowe nadużycia.
- Włącz ochronę przed botami i blokuj automatyczne żądania.
Wykrywanie i wskaźniki kompromitacji (na co zwrócić uwagę)
Szukaj oznak, że miały miejsce darmowe rejestracje, szczególnie w dużych ilościach lub z podobnych kont.
- Anomalie rejestracji
- Nagły wzrost rejestracji na płatne kursy bez odpowiadających rekordów płatności.
- Wiele nowo utworzonych lub mało aktywnych kont użytkowników zarejestrowanych na płatne kursy.
- Anomalie zamówień/płatności
- Zamówienia z całkowitą kwotą = 0 dla kursów, które są wycenione > 0.
- Zamówienia, w których brakuje identyfikatorów transakcji bramki płatniczej lub są oznaczone jako “oczekujące”, ale użytkownik ma dostęp do kursu.
- Zamówienia utworzone z nietypowymi metadanymi (np. dziwne agenty użytkownika, te same zakresy IP lub identyczne znaczniki czasowe).
- Wzorce logów
- Powtarzające się żądania POST do punktów końcowych z akcjami takimi jak “rejestracja”, “zamówienie_zakończone”, “lp_zamówienie” z kont na poziomie subskrybenta.
- Żądania, które nie zawierają znanych podpisów webhook bramki płatniczej, ale nadal uruchamiają rejestrację kursu.
- Przykładowe zapytania detekcyjne (koncepcyjne)
Zapytanie do bazy danych w celu znalezienia rejestracji na płatne kursy bez zakończonej płatności:SELECT enrollment.user_id, enrollment.course_id, order.txn_id, order.amount FROM lp_enrollments AS enrollment;
Uwaga: nazwy tabel różnią się w zależności od wtyczki LMS i konfiguracji — skonsultuj się ze schematem swojej witryny lub dokumentacją wtyczki. Jeśli nie jesteś pewien, wyeksportuj tabele zamówień i rejestracji i sprawdź relacje.
- Sprawdź logi serwera WWW
- Filtruj logi według znaczników czasowych wzrostów rejestracji i szukaj adresów IP, agentów użytkownika oraz punktów końcowych żądań.
- Sprawdź logi LearnPress (jeśli są włączone)
- Niektóre wtyczki LMS dostarczają logi debugowania dla bramek płatności i zdarzeń rejestracji. Przejrzyj je pod kątem niedopasowanych znaczników czasu (zdarzenie rejestracji przed potwierdzeniem płatności).
Przykładowe polecenia CLI (bezpieczne kontrole)
- Sprawdź wersję wtyczki za pomocą WP-CLI:
wp plugin get learnpress --fields=name,version,slug - Zaktualizuj wtyczkę (gdy będzie gotowa):
wp plugin update learnpress - Lista ostatnich aktywnych użytkowników (według daty rejestracji):
wp user list --role=subscriber --field=user_login,user_email,user_registered --orderby=user_registered --order=DESC --number=50 - Eksportuj zamówienia do ręcznej inspekcji (jeśli zamówienia są przechowywane jako typ postu):
wp post list --post_type=lp_order --fields=ID,post_title,post_status,post_date --format=csv
Przykładowe wskaźniki do wyszukiwania w logach:
- admin-ajax.php?action=learnpress_enroll
- Żądania REST do /wp-json/learnpress/v1/orders lub /wp-json/learnpress/v1/enrollments
- Żądania brakujące nagłówki podpisu bramki płatności (np. brakujące nagłówki webhook specyficzne dla bramki)
Przykład WAF / wskazówki dotyczące reguł (wirtualne łatanie)
Wirtualne łatanie przez zaporę aplikacji internetowej zyskuje czas podczas aktualizacji. Poniżej znajdują się zasady koncepcyjne i wzorce wykrywania, które zaleca WP‑Firewall. Dostosuj zasady do swojej witryny i przetestuj na etapie testowym.
- Zablokuj podejrzane działania rejestracyjne, które nie mają weryfikacji po stronie serwera
– Jeśli wtyczka udostępnia akcję AJAX lub punkt końcowy REST dla rejestracji, wymagaj:
– Ważnego nonce i referera, ORAZ
– Tokena weryfikacji płatności lub zamówienia w bazie danych o statusie “zrealizowane”. - Ogranicz liczbę prób rejestracji na użytkownika i na IP
– Zapobiegaj szybkim powtórnym rejestracjom przez tego samego użytkownika lub wiele kont z tego samego zakresu IP. - Zabroń żądań, które próbują nadpisać status zamówienia bez potwierdzenia bramki.
– Zablokuj żądania, które ustawiają parametry statusu zamówienia na “zrealizowane”, chyba że pochodzą z zakresu adresów IP webhooka bramki lub mają ważny podpis bramki. - Przykład logiki pseudo-reguły (koncepcyjna reguła w stylu ModSecurity — dokładnie przetestuj).
– Odrzuć żądania, w których:
– URI żądania zawiera /wp-admin/admin-ajax.php lub /wp-json/learnpress, a akcja zawiera enroll LUB order_complete, ORAZ
– rola użytkownika to Subskrybent (widoczna w aplikacji), ORAZ
– żądanie nie zawiera ważnego nonce LUB brakuje nagłówka weryfikacji płatności LUB wyszukiwanie rekordu zamówienia zwraca niezapłacone.
Notatka: WAF-y nie mogą niezawodnie widzieć stanu bazy danych po stronie serwera bez integracji aplikacji. Łącz reguły z kontrolami po stronie serwera (zalecane). - Zablokuj zautomatyzowane masowe zapisywanie na podstawie zachowania.
– Jeśli wiele różnych kont zapisuje się na płatne kursy w krótkim czasie, wymuś CAPTCHA na punktach końcowych potwierdzenia zapisu.
Przykładowy pseudokod WAF (dla zespołów bezpieczeństwa).
Jeśli żądanie do punktu końcowego zapisu:.
Wzmacnianie i długoterminowa prewencja
- Wymuś autorytatywne kontrole po stronie serwera.
– Logika biznesowa musi zweryfikować zakończenie płatności w stosunku do zarejestrowanych zamówień po stronie serwera przed przyznaniem dostępu. Nie polegaj na wskaźnikach dostarczonych przez klienta. - Waliduj powiadomienia bramki płatności.
– Zawsze weryfikuj podpisy webhooków lub tokeny weryfikacji bramki płatności podczas przetwarzania zdalnych powiadomień o płatności. - Zasada najmniejszych uprawnień
– Role powinny mieć tylko te możliwości, które są absolutnie konieczne. Unikaj niestandardowych możliwości, które pozwalają na przejścia stanu (zamówienia/zapisy) z ról o niskich uprawnieniach. - Zabezpiecz procesy rejestracji.
– Użyj weryfikacji e-mail i rozważ moderację dla nowych kont.
– Dla stron sprzedających kursy rozważ uczynienie tworzenia konta procesem dwustopniowym, który weryfikuje tożsamość użytkownika przed zezwoleniem na zakupy. - Wdrażaj logowanie i monitorowanie zamówień/zapisów
– Zachowuj logi do audytu. Twórz alerty dla anomalii w stosunku zapisów do płatności. - Testuj logikę biznesową w środowisku staging
– Uwzględnij testy w CI/CD, które symulują przepływy webhooków, tworzenie zamówień i sekwencje przyznawania zapisów, aby zapobiec regresjom. - Zarządzanie lukami
– Subskrybuj powiadomienia o wydaniach wtyczek i utrzymuj cykl aktualizacji (cotygodniowe lub co dwa tygodnie kontrole).
– Testuj aktualizacje na staging przed produkcją, ale unikaj długich opóźnień w stosowaniu poprawek bezpieczeństwa.
Lista kontrolna reakcji na incydenty (szybkie działania w przypadku podejrzenia wykorzystania)
- Natychmiast zaktualizuj LearnPress do wersji 4.3.6.
- Wymuś ręczną weryfikację:
– Cofnij dostęp dla podejrzanych kont, jeśli wykryjesz nadużycia.
– Zresetuj listy dostępu do kursów i ponownie przyznaj dostęp tam, gdzie to konieczne po weryfikacji płatności. - Zachowaj logi i dowody:
– Eksportuj logi sieciowe, logi wtyczek i migawki bazy danych (zachowanie dowodów). - Powiadom interesariuszy:
– Zespoły finansowe i zgodności, jeśli istotny jest wpływ finansowy lub ujawnienie danych. - Poinformuj dotkniętych użytkowników (jeśli wymaga tego polityka lub prawo).
- Uzgodnij płatności i popraw zamówienia:
– Cofnij zapisy, które zostały przyznane bez płatności.
– Wydaj zwroty tam, gdzie to stosowne, po ręcznej weryfikacji. - Po incydencie:
– Dodaj testy do CI, które sprawdzają poprawiony przepływ, aby zapobiec powtórzeniu.
– Przeprowadź analizę po incydencie: przyczyna źródłowa, harmonogram, wyciągnięte wnioski.
Jak WP‑Firewall pomaga
W WP‑Firewall wierzymy, że obrona w głębokości jest zasadniczą zasadą. Gdy odkryta zostanie luka w wtyczce, możesz użyć wielu funkcji WP‑Firewall razem, aby szybko złagodzić skutki:
- Zarządzane zasady WAF (wirtualne łatanie):
WP‑Firewall może wdrażać ukierunkowane zasady, aby natychmiast blokować podejrzane prośby o rejestrację i modyfikację stanu zamówienia — zyskując czas do momentu zastosowania aktualizacji wtyczki. - Egzekwowanie dostępu opartego na rolach:
Pomagamy ograniczyć, które punkty końcowe i działania są dostępne dla kont Subskrybenta oraz zapewniamy wgląd w to, które role wywołują podejrzane punkty końcowe. - Skaner złośliwego oprogramowania i kontrole integralności:
Skaner weryfikuje pliki rdzeniowe wtyczki i może wykrywać nieoczekiwane zmiany lub podejrzane dodatki do bazy kodu wtyczki, które mogą wskazywać na manipulację lub drugą fazę eksploatacji. - Ograniczanie liczby żądań i ochrona przed botami:
Zatrzymaj masowe nadużycia, egzekwując limity liczby żądań na IP i na konto na punktach końcowych rejestracji. - Aktywne monitorowanie i powiadomienia:
Otrzymuj powiadomienia natychmiast, gdy wykryte zostaną nietypowe wzorce (skoki w darmowych rejestracjach, wiele zamówień o zerowej wartości lub powtarzające się wywołania punktów końcowych rejestracji). - Opcje automatycznej aktualizacji dla wtyczek:
W środowiskach, które na to pozwalają, automatyczna aktualizacja podatnych wtyczek do wersji z poprawkami zmniejsza okno narażenia. - Szczegółowe logi do przeglądu sądowego:
WP‑Firewall może przechowywać wzbogacone logi żądań (z identyfikatorem użytkownika, rolami, danymi heurystycznymi ładunku żądania), co przyspiesza dochodzenie.
Uwaga na temat wirtualnego łatania: wirtualne łaty chronią na krawędzi bez modyfikacji kodu wtyczki. Są ważnym środkiem zapobiegawczym, ale nie zastępują zastosowania rzeczywistej poprawki wtyczki.
Zabezpiecz swoje kursy już dziś — wypróbuj darmowy plan WP‑Firewall
Tytuł: Chroń swoją platformę edukacyjną już teraz — wypróbuj plan darmowy WP‑Firewall
Jeśli prowadzisz LMS i chcesz natychmiastowej, praktycznej ochrony dla procesów rejestracji i płatności, podstawowy plan WP‑Firewall (darmowy) zapewnia niezbędną ochronę bez kosztów: zarządzany zapora, nielimitowana przepustowość, zasady WAF, skaner złośliwego oprogramowania i łagodzenie ryzyk OWASP Top 10. Zacznij chronić rejestracje, zapobiegaj próbom obejścia płatności i monitoruj podejrzaną aktywność na swoich stronach WordPress bez żadnych kosztów wstępnych. Zarejestruj się w darmowym planie tutaj: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Jeśli potrzebujesz automatycznego usuwania złośliwego oprogramowania, kontroli czarnej/białej listy IP lub zaawansowanego raportowania, rozważ aktualizację do planów Standard lub Pro. Nasz plan Pro obejmuje również automatyczne wirtualne łatanie podatności i miesięczne raporty bezpieczeństwa dla spokoju ducha.)
Dodatek: przydatne kontrole i przykładowe kroki
Szybka kontrola wersji i aktualizacja
- Uzyskaj wersję LearnPress:
wp plugin get learnpress --fields=wersja - Aktualizacja:
wp plugin update learnpress
Sprawdź ostatnie zapisy i zamówienia (koncepcyjne)
- Eksportuj ostatnie zapisy i połącz je z zamówieniami, aby znaleźć niezgodności (współpracuj z deweloperem, jeśli nazwy tabel są nieznane).
Przeszukaj dzienniki sieciowe w poszukiwaniu podejrzanych punktów końcowych (przykład)
grep -i "admin-ajax.php" /var/log/nginx/access.log | grep -i "zapisz"grep -i "/wp-json/learnpress" /var/log/apache2/access.log
Ogranicz przepustowość punktu końcowego zapisu za pomocą nginx (przykład koncepcji)
Użyj limit_req nginx dla lokalizacji, która obsługuje zapisy. Przykład:
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
(Przetestuj przed produkcją.)
Przykładowa lista kontrolna dla właścicieli stron (krótka)
- Zaktualizuj LearnPress do 4.3.6 (lub najnowszej wersji).
- Przejrzyj zamówienia i zapisy pod kątem niezgodności.
- Włącz lub zaostrz CAPTCHA / limity przepustowości w procesach rejestracji i realizacji zamówień.
- Włącz plan podstawowy WP‑Firewall dla natychmiastowego WAF + skanowania.
- Jeśli znajdziesz podejrzaną aktywność: zachowaj dzienniki, usuń nieautoryzowany dostęp, komunikuj się wewnętrznie.
Ostateczne uwagi — głos doświadczenia
Luki, które pozwalają na obejście logiki biznesowej, są frustrujące, ponieważ nie zawsze wyglądają jak “krytyczne wstrzyknięcie kodu” lub zdalne wykonanie kodu. Wykorzystują one niezgodności w założeniach między komponentami: front-endem, zarządzaniem stanem wtyczki i powiadomieniami z zewnętrznych bramek płatności. Napastnicy uwielbiają tego rodzaju problemy, ponieważ bezpośrednio przekładają się na korzyści finansowe przy minimalnej wymaganej technicznej złożoności.
Jeśli prowadzisz działalność związaną z płatnymi kursami, potraktuj to jako dwa problemy do rozwiązania:
- Napraw natychmiastową lukę (łatka).
- Popraw odporność systemu, aby podobna luka logiczna nie mogła być ponownie wykorzystana (testy, monitorowanie, autorytatywne kontrole po stronie serwera, warstwowe zasady WAF).
Jeśli masz pytania dotyczące wdrażania powyższych środków zaradczych, konfigurowania WP‑Firewall w celu ochrony punktów rejestracji lub przeglądania dzienników, nasz zespół ds. bezpieczeństwa jest dostępny, aby pomóc. Zacznij od podstawowej, darmowej ochrony, aby uzyskać natychmiastowe pokrycie WAF i przejdź do zaawansowanych planów na automatyczne łatanie wirtualne, miesięczne raporty i zarządzane usługi bezpieczeństwa.
Bądź bezpieczny i priorytetowo traktuj łatanie — najszybsza i najbardziej niezawodna ochrona to zawsze uruchomienie wersji wtyczki z poprawkami.
— Zespół ds. bezpieczeństwa WP‑Firewall
