Nazwa wtyczki	Riaxe Product Customizer
Rodzaj podatności	Ujawnienie danych
Numer CVE	CVE-2026-3594
Pilność	Niski
Data publikacji CVE	2026-04-07
Adres URL źródła	CVE-2026-3594

Ujawnienie danych wrażliwych w Riaxe Product Customizer (<=2.4): Co właściciele WordPressa powinni wiedzieć i jak WP‑Firewall cię chroni

Data: 2026-04-08
Autor: Zespół ds. bezpieczeństwa WP‑Firewall

Streszczenie

Niedawno ujawniona luka (CVE-2026-3594) dotyczy wtyczki WordPress “Riaxe Product Customizer” w wersji 2.4 i wcześniejszych. Problem pozwala nieautoryzowanym atakującym na uzyskanie wrażliwych informacji związanych z zamówieniami za pośrednictwem punktu końcowego REST API (/orders) ujawnionego przez wtyczkę. Chociaż luka została oceniona na umiarkowany poziom CVSS (5.3) i sklasyfikowana jako Ujawnienie Danych Wrażliwych (OWASP A3), może być nadal wykorzystywana w kampaniach masowych do zbierania danych klientów, szczegółów zamówień i innych wrażliwych rekordów z wielu stron szybko.

W WP‑Firewall proaktywna obrona stron przed tego rodzaju problemami ujawnienia jest kluczowym priorytetem. Ten post wyjaśnia lukę w prostych słowach, przeprowadza przez kroki wykrywania i łagodzenia dla właścicieli stron i zespołów hostingowych, zaleca działania wzmacniające dla programistów i pokazuje, jak nasze zarządzane WAF i możliwości wirtualnego łatania mogą natychmiast cię chronić, podczas gdy stosowana jest oficjalna łatka.

---

Co się stało (zwięźle)

• Wrażliwość: Nieautoryzowane ujawnienie informacji wrażliwych za pośrednictwem punktu końcowego REST API (/orders) w wersjach wtyczki Riaxe Product Customizer <= 2.4.
• CVE: CVE-2026-3594
• Uderzenie: Atakujący może zapytać o podatny punkt końcowy bez uwierzytelnienia i uzyskać dostęp do wrażliwych informacji o zamówieniach/klientach, które powinny być chronione.
• Powaga: Umiarkowane (ujawnienie danych wrażliwych może umożliwić dalsze ataki, takie jak phishing, przejęcia kont, oszustwa).
• Dotyczy wersji: Riaxe Product Customizer ≤ 2.4
• Natychmiastowe działanie: Zastosuj oficjalną łatkę dostawcy, gdy będzie dostępna. Jeśli nie ma jeszcze łatki, wdroż środki łagodzące: ogranicz lub zablokuj punkt końcowy, zastosuj zasady WAF/wirtualne łatanie, audytuj logi i zamówienia, zmień dane uwierzytelniające, jeśli są podejrzane, i rozważ tymczasowe wyłączenie wtyczki.

---

Dlaczego to ma znaczenie — rzeczywiste ryzyko dla stron WordPress

Wiele sklepów i stron WordPress korzysta z dostosowań/wtyczek, które ujawniają trasy REST, aby zapewnić funkcje oparte na API. Gdy wtyczka niewłaściwie ujawnia dane zamówienia bez wymagania uwierzytelnienia lub sprawdzania uprawnień, wrażliwe pola, takie jak imiona klientów, adresy, e-maile, numery telefonów, przedmioty zamówienia, a nawet odniesienia do płatności, mogą wyciekać.

Nawet jeśli nie wyciekną pełne dane płatności, ujawnione metadane zamówienia są cenne dla atakujących:

• Listy klientów i e-maile napędzają ukierunkowany phishing i spear-phishing.
• Historie zamówień mogą być wykorzystywane do inżynierii społecznej lub oszustwa.
• W połączeniu z innymi ujawnionymi informacjami, atakujący mogą dążyć do przejęcia kont.
• Automatyzacja masowa pozwala atakującemu szybko zbierać dane z tysięcy podatnych stron.

Dlatego rozwiązanie problemów z ujawnieniem danych jest niezbędne, nawet gdy nie występuje bezpośrednie przejęcie konta ani zdalne wykonanie kodu.

---

Przegląd techniczny (nieeksploatacyjny)

Na podstawie publicznych raportów i harmonogramów odpowiedzialnego ujawnienia, przyczyną podatności jest trasa REST API stworzona przez wtyczkę, która nie wymusza uwierzytelniania ani sprawdzania uprawnień. wywołanie_zwrotne_uprawnienia W WordPressie trasy REST powinny być zazwyczaj rejestrowane z.

która weryfikuje, czy użytkownik lub token żądający ma niezbędne uprawnienia lub kontekst. Jeśli ten callback jest nieobecny lub wadliwy, punkt końcowy staje się publicznie dostępny.

Typowy bezpieczny wzór rejestracji trasy REST:;

Jeśli wywołanie_zwrotne_uprawnienia register_rest_route( prawda jest nieobecny lub zwraca.

---

Natychmiastowe działania dla właścicieli stron (krok po kroku)

bezwarunkowo, trasa staje się dostępna dla nieautoryzowanych żądań. Atakujący mogą następnie enumerować lub żądać konkretnych identyfikatorów zamówień i zbierać dane.

1. Jeśli prowadzisz stronę WordPress, która używa Riaxe Product Customizer (<=2.4), natychmiast wykonaj te priorytetowe kroki:
   • Zidentyfikuj, czy Twoja strona używa dotkniętej wtyczki.
   • WP‑CLI: WP Admin > Wtyczki: poszukaj 'Riaxe Product Customizer" i sprawdź zainstalowaną wersję."
2. wp plugin list --format=json | jq -r '.[] | select(.name|test("Riaxe"))'
   • Jeśli dostępna jest aktualizacja, zastosuj ją natychmiast.
3. Zaktualizuj do poprawionej wersji, gdy tylko dostawca wtyczki ją wyda.
   • Jeśli jeszcze nie ma oficjalnej poprawki, złagodź:.
     • Tymczasowo wyłącz wtyczkę, jeśli nie jest niezbędna.
     • WP‑CLI: WP Admin: dezaktywuj wtyczkę.
   • wp plugin deactivate riaxe-product-customizer.

     Ogranicz dostęp do konkretnego punktu końcowego REST na poziomie serwera WWW (preferowane w krótkim okresie). Przykład Apache (.htaccess) do zablokowania dostępu zewnętrznego do:

     <IfModule mod_rewrite.c>
       RewriteEngine On
       RewriteCond %{REQUEST_URI} ^/wp-json/riaxe/v1/orders [NC]
       RewriteRule .* - [F]
     </IfModule>
     

     Przykład Nginx:

     location ~* ^/wp-json/riaxe/v1/orders {
     

   • Wdróż blokadę na poziomie WordPressa za pomocą punkty_koniec filtru, aby usunąć lub ograniczyć trasę:

     add_filter('rest_endpoints', function($endpoints) {;
     

     Umieść ten kod w wtyczce specyficznej dla witryny lub mu-wtyczce (nie modyfikuj plików wtyczek bezpośrednio, aby uniknąć utraty zmian podczas aktualizacji).

4. Zastosuj zasady WAF / wirtualne łatanie
   • Skonfiguruj swój WAF, aby blokował nieautoryzowane żądania do podatnej ścieżki końcowej lub zwracał 403, gdy żądanie nie zawiera nagłówków autoryzacji lub ciasteczek.
   • Ogranicz liczbę wywołań do końcowych punktów REST, aby zmniejszyć ryzyko masowego wydobycia.
5. Audytuj zamówienia i logi
   • Eksportuj ostatnie zamówienia i skanuj pod kątem nieoczekiwanych pobrań lub dostępu w okresie możliwej ekspozycji.
   • Sprawdź logi dostępu serwera WWW pod kątem żądań do /wp-json/ końcowych punktów i szukaj podejrzanych agentów użytkownika lub dużej liczby żądań z pojedynczych adresów IP.
     • Przykład grep: grep "/wp-json/riaxe/v1/orders" /var/log/apache2/access.log*
   • Jeśli hostujesz logi zewnętrznie (LogDNA, Papertrail itp.), uruchom zapytania dla ścieżki końcowej.
6. Rotuj klucze i poświadczenia
   • Jeśli znajdziesz dowody kradzieży danych lub podejrzanej aktywności, zmień wszelkie klucze API, sekrety integracji lub dane uwierzytelniające, które mogły zostać ujawnione lub są związane z przetwarzaniem zamówień.
7. Powiadom dotkniętych klientów, jeśli to konieczne
   • Jeśli potwierdzono, że wrażliwe dane klientów zostały ujawnione i podlegasz przepisom o ochronie danych, przestrzegaj swoich obowiązków w zakresie powiadamiania o naruszeniach.

---

Wykrywanie: Jak sprawdzić, czy Twoja strona była badana lub dane zostały wyodrębnione

Użyj następujących sygnałów, aby wykryć możliwe wykorzystanie:

• Logi dostępu serwera WWW pokazujące nieautoryzowane żądania GET do /wp-json/ trasy, szczególnie Przykład Apache (.htaccess) do zablokowania dostępu zewnętrznego do Lub /wp-json/*zamówienia*.
• Niezwykle wysokie wskaźniki żądań do punktów końcowych REST w krótkim okresie czasu.
• Żądania z podejrzanymi agentami użytkownika, które wielokrotnie uzyskują dostęp do identyfikatorów zamówień w sposób sekwencyjny (wzorzec enumeracji).
• Nowe adresy IP wykonujące liczne żądania, które różnią się od normalnych wzorców ruchu.
• Niespodziewany ruch wychodzący lub wzorce eksfiltracji danych (jeśli monitorujesz ruch wychodzący).
• Powiadomienia z programów skanujących złośliwe oprogramowanie lub dzienników WAF pokazujące zablokowane próby ataków na punkty końcowe REST API.

Przykładowe szybkie kontrole:

• Sprawdź dostęp do punktów końcowych w dziennikach Apache:
  • zgrep "wp-json/riaxe/v1/zamówienia" /var/log/apache2/access.log* | awk '{print $1}' | sort | uniq -c | sort -nr | head
• Sprawdź ostatni ruch REST API za pomocą logowania debugowania WordPress (jeśli włączone) lub dzienników dostępu.

Jeśli odkryjesz dowody na eksfiltrację, traktuj incydent jako naruszenie danych: zbierz dzienniki, zachowaj dowody i postępuj zgodnie z planem reakcji na incydenty.

---

Lista kontrolna reagowania na incydenty

Jeśli potwierdzisz nadużycie:

1. Izolować: Zablokuj adresy IP atakującego i tymczasowo wyłącz podatny wtyczkę lub zablokuj punkt końcowy za pomocą WAF/serwera WWW.
2. Zachowaj dowody: Eksportuj dzienniki, zdarzenia WAF i migawki bazy danych do analizy kryminalistycznej.
3. Zidentyfikuj zakres: Wypisz dotknięte zamówienia, użytkowników i zakresy dat.
4. Zawierać: Zmień dane uwierzytelniające, tokeny i sekrety integracji. Wyłącz wszelkie ujawnione klucze API.
5. Wytępić: Usuń złośliwe pliki, tylne drzwi lub podejrzanych użytkowników administratora.
6. Odzyskiwać: Zastosuj poprawki dostawcy, przywróć czyste kopie zapasowe w razie potrzeby i stopniowo przywracaj usługi z monitorowaniem.
7. Powiadomienie: Poinformuj klientów i odpowiednie władze, jeśli wymaga tego prawo.
8. Po incydencie: Przeprowadź przegląd przyczyn źródłowych i wprowadź zmiany techniczne oraz procesowe, aby zapobiec powtórzeniu się.

---

Jak WP‑Firewall może teraz chronić Twoją stronę

Jako zarządzany dostawca usług WAF i bezpieczeństwa WordPress, WP‑Firewall zapewnia kilka warstw ochrony, które są skuteczne przeciwko lukom, takim jak CVE-2026-3594:

• Zarządzane zasady WAF: Możemy szybko wdrożyć wirtualną łatkę, aby zablokować nieautoryzowany dostęp do konkretnego wzoru trasy REST Przykład Apache (.htaccess) do zablokowania dostępu zewnętrznego do na wszystkich chronionych stronach. To zatrzymuje próby masowego wydobycia jeszcze przed wydaniem łatki przez dostawcę wtyczki.
• Mitigacje OWASP Top 10: Nasze zasady obejmują ochronę przed powszechnymi błędami konfiguracji API oraz wektorami ujawnienia wrażliwych danych.
• Skaner złośliwego oprogramowania i monitorowanie: Ciągłe skanowanie w poszukiwaniu podejrzanych plików lub oznak, że atakujący wykorzystał lukę.
• Inteligencja zagrożeń i automatyczne blokowanie: Jeśli wykryjemy aktywność eksploatacyjną, WAF proaktywnie blokuje złośliwe adresy IP i wzory.
• Nielimitowana przepustowość i ochrona o niskim opóźnieniu: Zapewnia, że strony pozostają dostępne, podczas gdy ataki są łagodzone na krawędzi.
• Wirtualne łatanie: W przypadku luk, dla których nie ma jeszcze dostępnej łatki od dostawcy, wirtualne łatki (zasady WAF) dają czas na zastosowanie odpowiednich poprawek kodu.

Dla właścicieli stron, którzy wolą podjąć działania natychmiast, nasz zarządzany WAF może być skonfigurowany do blokowania podatnego punktu końcowego lub zwracania oczyszczonej odpowiedzi na nieautoryzowane żądania.

---

Przykłady wzorców reguł WAF (koncepcyjne)

Poniżej znajdują się przykłady zasad koncepcyjnych, które możesz wykorzystać do poinstruowania swojego dostawcy hostingu lub wdrożenia w produkcie WAF. Unikaj kopiowania/wklejania ich w publicznych miejscach, gdzie atakujący mogą dostosować swoje sygnały; zamiast tego wdrażaj je wewnętrznie.

• Zablokuj nieautoryzowane żądania do podatnej trasy:
  • Warunek: REQUEST_URI pasuje do regex ^/wp-json/(riaxe|riaxe-product-customizer)/v\d+/zamówienia
  • I: Brak pliku cookie uwierzytelniającego WordPress (!CIASTKO:wordpress_logged_in)
  • Akcja: Zwróć HTTP 403 lub 404
• Ogranicz liczbę i blokuj podejrzane wzory enumeracji:
  • Warunek: Więcej niż X żądań do /wp-json/*zamówienia* z tego samego IP w ciągu Y sekund
  • Akcja: Tymczasowa blokada (np. 1 godzina) i dodanie do czarnej listy botów za powtarzające się wykroczenia
• Blokuj znane złośliwe agenty użytkowników lub narzędzia skanujące celujące w punkty końcowe REST.

Jeśli korzystasz z hostowanego WAF, poproś swojego dostawcę o wdrożenie tych wirtualnych poprawek dla Ciebie.

---

Wskazówki dla deweloperów: Najlepsze praktyki zabezpieczania REST API

Autorzy wtyczek i deweloperzy motywów powinni przestrzegać tych najlepszych praktyk, aby uniknąć ujawniania wrażliwych danych za pośrednictwem punktów końcowych REST:

1. Zawsze wdrażaj ścisły callback uprawnień
   • Waliduj użytkownika lub token żądający; użyj kontroli uprawnień (np., bieżący_użytkownik_może()).
   • Unikaj zwracania prawda bezwarunkowo.
2. Minimalizuj ujawnianie danych
   • Zwracaj tylko pola niezbędne dla klienta. Unikaj dołączania pełnych rekordów klientów, jeśli to możliwe.
   • Domyślnie maskuj lub redaguj PII (adres e-mail, telefon, adresy), chyba że jest to wyraźnie wymagane.
3. Używaj nieprzewidywalnych identyfikatorów
   • Unikaj ujawniania sekwencyjnych identyfikatorów numerycznych, jeśli mogą być użyte do enumeracji rekordów; używaj UUID lub wymagaj autoryzacji do rozwiązania identyfikatorów.
4. Ograniczaj szybkość wrażliwych tras
   • Wdrażaj ograniczenia prędkości lub limitowanie dla punktów końcowych, które zwracają dane.
5. Waliduj dane wejściowe i wyjściowe
   • Oczyść parametry wejściowe i zastosuj filtry wyjściowe, aby uniknąć nieoczekiwanego wycieku.
6. Zabezpiecz wrażliwe dane w spoczynku
   • Szyfruj lub chroń wrażliwe przechowywane pola i przestrzegaj polityk ochrony danych PCI lub lokalnych, jeśli to możliwe.
7. Używaj kontroli opartych na uprawnieniach do dostępu do danych na poziomie administratora.
   • Nie polegaj wyłącznie na uwierzytelnianiu; sprawdź konkretne uprawnienia.
8. Rejestruj dostęp i zapewnij ścieżki audytu.
   • Zachowuj logi dostępu do REST API, szczególnie dla punktów końcowych, które udostępniają dane osobowe.

---

Wskazówki dla partnerów hostingowych.

Dostawcy hostingu i operatorzy platform mogą pomóc chronić klientów przed tymi klasami podatności:

• Wdrożenie WAF na krawędzi i utrzymanie zestawu reguł zdolnego do wirtualnego łatania.
• Monitoruj nietypowy ruch REST API na stronach klientów i automatycznie powiadamiaj właścicieli.
• Zapewnij zarządzane usługi łatania lub aktualizacji wtyczek, lub przynajmniej wyraźnie informuj klientów, gdy publikowane są krytyczne aktualizacje wtyczek.
• Oferuj ograniczenie szybkości na poziomie strony, aby zmniejszyć prędkość masowego wydobycia.
• Zapewnij mechanizm blokowania konkretnych punktów końcowych globalnie dla konta, aż właściciel strony usunie problem.

---

Jak bezpiecznie ograniczyć punkty końcowe REST w WordPressie (więcej szczegółów).

Jeśli wolisz łatanie na poziomie WordPressa i nie chcesz modyfikować konfiguracji serwera, użyj mu-wtyczki (wtyczki, która musi być używana), aby przetrwała aktualizacje wtyczek:

Utwórz plik. wp-content/mu-plugins/block-riaxe-orders.php z:

<?php
/**
 * Block unauthenticated access to vulnerable Riaxe REST endpoint.
 */

add_filter('rest_endpoints', function($endpoints) {
    foreach ($endpoints as $route => $handlers) {
        // Adjust route pattern to match exact endpoint in your installation
        if (strpos($route, '/riaxe/v1/orders') !== false) {
            // Remove endpoints that match the vulnerable pattern
            unset($endpoints[$route]);
        }
    }
    return $endpoints;
});

To usuwa trasę z rejestru REST API, więc nie może być wywoływana. Testuj dokładnie: jeśli twoja strona polega na punkcie końcowym dla legalnej funkcjonalności publicznej, skoordynuj z deweloperem bezpieczną alternatywę.

---

Sprawdzanie bazy danych pod kątem podejrzanego dostępu do zamówień.

Jeśli podejrzewasz eksfiltrację, zidentyfikuj zamówienia utworzone lub zmodyfikowane w czasie podatności:

• Eksportuj tabele zamówień i sprawdź pod kątem nieregularnych modyfikacji:
  • Zamówienia WooCommerce są przechowywane w wp_posts z post_type = ‘shop_order’ i polach meta w wp_postmeta.
• Przykład SQL do listowania zamówień zmodyfikowanych w określonym czasie (dostosuj daty):

  WYBIERZ ID, post_date, post_modified, post_status;
  

• Sprawdź metadane zamówienia pod kątem nietypowych pól lub notatek (wp_postmeta, wp_komentarze).

Jeśli znajdziesz potwierdzoną aktywność zgodną z ekstrakcją, postępuj zgodnie z powyższą listą kontrolną odpowiedzi na incydenty.

---

Często zadawane pytania

Q: Mój wtyczka jest niezbędna — czy mogę ją utrzymać aktywną i nadal być bezpiecznym?
A: Jeśli punkt końcowy jest wymagany do podstawowej funkcjonalności i nie ma łatki, wdroż regułę WAF, aby ograniczyć dostęp nieautoryzowany i ograniczyć trasę do zaufanych adresów IP, podczas gdy koordynujesz z dostawcą bezpieczną aktualizację. Rozważ wirtualne łatanie za pomocą zarządzanego WAF.

Q: Czy wyłączenie REST API globalnie łamie moją stronę?
A: Niektóre motywy i wtyczki polegają na REST API. Zamiast wyłączać go globalnie, usuń lub zabezpiecz konkretny podatny punkt końcowy. Użyj ukierunkowanego podejścia.

Q: Czy zmiana numerów zamówień lub identyfikatorów zatrzyma atakujących?
A: Nie sama w sobie. Atakujący często badają znane punkty końcowe i wzorce. Odpowiednia autoryzacja i kontrole uprawnień są solidnym rozwiązaniem.

---

Długoterminowe zalecenia

• Utrzymuj inwentarz wtyczek i monitoruj powiadomienia o bezpieczeństwie dla wtyczek, na których polegasz.
• Użyj zarządzanego WAF z możliwością wirtualnego łatania, aby uzyskać ochronę przed dostępnością poprawek dostawcy.
• Wdroż najmniejsze uprawnienia w kontach administratorów i integracjach.
• Zaplanuj regularne kopie zapasowe i testuj przywracanie.
• Przyjmij ciągłe monitorowanie i rejestrowanie aktywności REST API.
• Rozważ staranność dostawcy przy wyborze wtyczek: częstotliwość konserwacji, reakcja na CVE i recenzje.

---

Przykład z życia wzięty: jak zazwyczaj działa atakujący (na wysokim poziomie)

Atakujący może skanować Internet w poszukiwaniu witryn WordPress ujawniających /wp-json/ przestrzeń nazw, a następnie żądać znanych tras wtyczek, takich jak /riaxe/v1/zamówienia. Skryptują sekwencyjne żądania identyfikatorów zamówień i zbierają wszelkie odpowiedzi JSON, które zawierają PII lub dane zamówienia. Dzięki automatyzacji, może to skalować do tysięcy witryn w krótkim czasie.

Zatrzymanie tego na krawędzi (WAF, ograniczenie liczby żądań) jest bardzo skuteczne, ponieważ zapobiega masowej automatyzacji bez konieczności natychmiastowych zmian w kodzie na każdej stronie.

---

Co zalecamy, abyś zrobił następnie (lista działań podsumowujących)

1. Sprawdź, czy Twoja strona korzysta z Riaxe Product Customizer (<=2.4).
2. Zastosuj łatkę dostawcy, gdy tylko będzie dostępna.
3. Jeśli jeszcze nie ma łatki:
   • Wyłącz wtyczkę LUB
   • Usuń/ochroń podatny punkt końcowy REST (mu-plugin lub zasada serwera WWW/WAF).
4. Audytuj dzienniki dostępu i dane zamówień w poszukiwaniu oznak dostępu.
5. Rotuj klucze i sekrety, jeśli zostaną wykryte podejrzane działania.
6. Rozważ zarządzany WAF / wirtualne łatanie, aby natychmiast zatrzymać eksploatację.
7. Zachowaj kopie zapasowe i dokumentuj wszelkie incydenty w celu zgodności i przeglądu po incydencie.

---

Chroń swoją stronę za pomocą WP‑Firewall — Zacznij chronić teraz z darmowym planem

Zacznij natychmiast chronić swoją stronę z darmowym planem WP‑Firewall

W WP‑Firewall ułatwiamy właścicielom stron natychmiastową ochronę witryn WordPress. Nasz darmowy plan (Podstawowy) obejmuje zarządzaną ochronę zapory, WAF o wysokiej wydajności, nielimitowaną przepustowość, skaner złośliwego oprogramowania oraz automatyczne łagodzenie ryzyk OWASP Top 10. Te zabezpieczenia dokładnie zapobiegają atakom masowego wydobycia i ujawnieniu danych wrażliwych, podczas gdy planujesz długoterminowe poprawki.

Jeśli chcesz natychmiastowej, niskonakładowej ochrony z możliwością skalowania do bardziej zaawansowanych usług później, zacznij od darmowego planu:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Ulepszając do Standard lub Pro, odblokowujesz automatyczne usuwanie złośliwego oprogramowania, czarną/białą listę adresów IP, wirtualne łatanie podatności, miesięczne raporty bezpieczeństwa i dedykowane wsparcie — cenne, jeśli prowadzisz wiele witryn lub działasz w sklepie internetowym.

---

Podsumowanie

Wrażliwe luki w ujawnianiu danych, takie jak CVE-2026-3594, przypominają, że zachowanie wtyczek — szczególnie niestandardowych punktów końcowych — musi być audytowane i chronione. Jako właściciel strony masz jasną, wykonalną ścieżkę: łataj, gdy będzie dostępna, stosuj wirtualne łaty (WAF) i audytuj w poszukiwaniu oznak nadużyć. Jeśli potrzebujesz natychmiastowych środków ochronnych, zarządzany WAF z wirtualnym łataniem szybko zamyka okno narażenia.

Jeśli potrzebujesz pomocy w wykrywaniu, niestandardowych wirtualnych łatek dla swojej strony lub prowadzonej reakcji na incydent, nasz zespół ds. bezpieczeństwa w WP‑Firewall jest dostępny, aby pomóc. Zacznij od naszego darmowego planu ochrony, aby uzyskać natychmiastowe pokrycie WAF i skaner złośliwego oprogramowania, a następnie przejdź do usług zarządzanych, jeśli potrzebujesz głębszej naprawy i wsparcia w terenie.

Bądź bezpieczny i zabezpiecz swoje punkty końcowe API w rozsądny sposób.

— Zespół ds. bezpieczeństwa WP‑Firewall