| Nazwa wtyczki | WPQuads |
|---|---|
| Rodzaj podatności | Atak typu cross-site scripting (XSS) |
| Numer CVE | CVE-2026-2595 |
| Pilność | Niski |
| Data publikacji CVE | 2026-03-28 |
| Adres URL źródła | CVE-2026-2595 |
Quads Ads Manager (WPQuads) Przechowywane XSS (CVE-2026-2595) — Co to oznacza, jak mogą to wykorzystać atakujący i co dokładnie powinieneś zrobić teraz
28 marca 2026 roku opublikowano podatność na przechowywane Cross-Site Scripting (XSS) wpływającą na wtyczkę Quads Ads Manager (WPQuads) dla wersji <= 2.0.98.1 (CVE-2026-2595). Problem pozwala uwierzytelnionemu użytkownikowi z rolą Współtwórcy na zapisanie stworzonych ładunków w parametrach metadanych reklamy, które są później renderowane i wykonywane w uprzywilejowanych kontekstach. Dostawca wydał łatkę w wersji 2.0.99.
Jeśli Twoja strona korzysta z tej wtyczki i pozwala współtwórcom, autorom lub innym użytkownikom niebędącym administratorami na edytowanie reklam lub metadanych, musisz działać natychmiast. Ten artykuł przeprowadzi Cię przez:
- Jasne, techniczne wyjaśnienie problemu i dlaczego jest niebezpieczny.
- Prawdopodobne scenariusze ataków i rzeczywisty wpływ.
- Praktyczne techniki wykrywania (bezpieczne, nieinwazyjne kontrole, które możesz przeprowadzić).
- Procedury naprawy i czyszczenia krok po kroku.
- Jak wzmocnić swoją stronę i ograniczyć podobne problemy w przyszłości.
- Jak zarządzany WAF + skaner złośliwego oprogramowania (WP‑Firewall) może pomóc podczas łatania.
Piszę to jako praktyk bezpieczeństwa WordPress z doświadczeniem w reagowaniu na incydenty XSS. Zachowam szczegóły techniczne w sposób praktyczny i uniknę niepotrzebnej spekulacji. Postępuj zgodnie z poniższymi krokami — traktuj aktualizację do 2.0.99 jako najwyższy priorytet.
Szybkie podsumowanie (najważniejsze)
- Podatność: Przechowywane Cross-Site Scripting (XSS) w Quads Ads Manager (WPQuads).
- Wpływające wersje: <= 2.0.98.1
- Łatane w: 2.0.99
- CVE: CVE-2026-2595
- Wymagane uprawnienia do wstrzyknięcia: Współtwórca (uwierzytelniony, nie-administrator).
- Wykorzystanie: Przechowywany ładunek w metadanych reklamy — wykonywany później, gdy jest renderowany dla użytkowników (w tym administratorów).
- Natychmiastowe działanie: Zaktualizuj wtyczkę do 2.0.99 lub nowszej. Jeśli nie możesz zaktualizować natychmiast, zastosuj wirtualne łatanie / łagodzenia WAF i ogranicz dostęp na poziomie współtwórcy.
Czym jest przechowywane XSS i dlaczego ta podatność ma znaczenie
Cross-Site Scripting (XSS) to praktyka wstrzykiwania skryptów po stronie klienta do stron internetowych, które są następnie wykonywane przez przeglądarki innych użytkowników. Przechowywane XSS występuje, gdy złośliwy ładunek jest zapisany na serwerze (baza danych, opcje, postmeta itp.) i serwowany innym użytkownikom później.
Ta konkretna podatność to wektor XSS przechowywany w polach metadanych reklam. Użytkownicy z rolą współautora (nie-admin WordPress) mogą tworzyć lub edytować reklamy i zapisywać przygotowane wartości w parametrach metadanych, które są później wyświetlane bez odpowiedniego escapingu lub sanitizacji. Ponieważ ładunek jest przechowywany, może być wykonywany wielokrotnie przeciwko każdemu użytkownikowi, który ładuje dotkniętą stronę — w tym redaktorom, administratorom lub odwiedzającym stronę.
Dlaczego to problem:
- Konta współautorów są powszechnie używane w procesach redakcyjnych. Napastnicy często celują w te konta o niższych uprawnieniach, ponieważ są łatwiejsze do zdobycia (słabe hasła, powtórzone dane logowania, inżynieria społeczna).
- Udana przechowywana XSS może być użyta do:
- Kradzieży ciasteczek sesyjnych administratora (chyba że ciasteczka są HttpOnly i odpowiednio chronione).
- Wykonywania działań w imieniu administratorów (tworzenie użytkowników administratora, zmiana ustawień) za pomocą interakcji podobnych do CSRF.
- Wstrzykiwania złośliwej reklamy, przekierowywania ruchu lub hostowania pobrań drive-by.
- Utrzymywania tylnej furtki w wtyczkach, motywach lub przesyłkach, oszukując administratorów, aby wykonywali działania.
- Przechowywana natura podatności umożliwia automatyzację i masowe wykorzystanie.
Chociaż CVSS opublikowane w komunikacie jest umiarkowane, rzeczywisty wpływ na świat zależy w dużej mierze od tego, czy napastnicy mogą zwabić lub oszukać użytkowników na poziomie administratora, aby wyświetlili skompromitowany interfejs lub strony front-end, na których działa ładunek.
Typowy przebieg ataku (jak napastnik mógłby to wykorzystać)
- Napastnik kompromituje lub tworzy konto współautora na stronie WordPress (inżynieria społeczna, słabe tworzenie kont, powtórzone dane logowania, konta z rynku).
- Wykorzystując możliwości współautora, napastnik edytuje wpisy reklamowe lub tworzy nową reklamę i umieszcza złośliwy skrypt w polu metadanych reklamy, które jest przechowywane w bazie danych.
- Gdy redaktor lub administrator wyświetla interfejs, w którym te metadane są renderowane (podgląd reklamy, strona administracyjna wtyczki lub publiczna strona, jeśli reklama jest wyświetlana na froncie), wstrzyknięty skrypt wykonuje się w przeglądarce uprzywilejowanego użytkownika.
- Skrypt może kraść ciasteczka, uzyskiwać nonce REST API, wywoływać punkty końcowe administratora, używając sesji tego użytkownika, lub pobierać zdalne ładunki — prowadząc do przejęcia konta administratora lub trwałego kompromitowania strony.
- Stamtąd napastnik może zasadzić tylne furtki, modyfikować treści lub wdrażać złośliwe oprogramowanie na całej stronie.
Ponieważ wymagane uprawnienie to Współautor (nie Administrator), wiele stron z redakcyjnymi współautorami jest narażonych. Dlatego tej kwestii nie należy ignorować.
Kto jest narażony na ryzyko?
- Strony korzystające z Quads Ads Manager / wtyczki WPQuads w wersjach <= 2.0.98.1
- Strony, które pozwalają na konta współautorów lub autorów z możliwością edytowania treści reklam lub metadanych.
- Blogi z wieloma autorami, strony informacyjne, agencje zarządzające treściami klientów, strony członkowskie z wkładami treści.
- Strony, na których uprzywilejowani użytkownicy (redaktorzy, administratorzy) przeglądają lub podglądają treści stworzone przez współtwórców bez dodatkowej inspekcji.
- Każda instalacja WordPressa, która nie ma ochrony WAF, Content-Security-Policy lub innych środków zaradczych.
Natychmiastowe kroki (kolejność ma znaczenie)
- Zaktualizuj teraz: Zaktualizuj Quads Ads Manager do wersji 2.0.99 lub nowszej.
- Zaktualizuj przez panel administracyjny WordPressa → Wtyczki → Aktualizuj, lub użyj swojego procesu wdrażania.
- Jeśli używasz WP-CLI:
wp wtyczka aktualizacja quick-adsense-reloaded
- Jeśli nie możesz zaktualizować natychmiast:
- Tymczasowo zablokuj dostęp współtwórców do edytowania wpisów reklamowych.
- Wyłącz wtyczkę (jeśli to możliwe), aż będziesz mógł ją zaktualizować.
- Umieść zaporę aplikacyjną / wirtualną łatkę przed stroną, aby zablokować ładunki eksploatacyjne.
- Przejrzyj konta współpracowników:
- Przeprowadź audyt kont współtwórców pod kątem podejrzanych adresów e-mail, ostatnich logowań lub nietypowej aktywności.
- Wymuś resetowanie haseł dla współtwórców, jeśli podejrzewasz nadużycia konta.
- Skanuj w poszukiwaniu wstrzykniętych skryptów (patrz Wykrywanie poniżej).
- Wzmocnij ustawienia sesji i ciasteczek: Upewnij się, że ciasteczka używają flag HttpOnly i Secure; skróć czas życia ciasteczek, jeśli podejrzewasz kompromitację.
- Włącz rejestrowanie i monitorowanie.: Zwiększ rejestrowanie na stronach administracyjnych; monitoruj nowych użytkowników administracyjnych lub zmiany w wtyczkach/motwach.
Aktualizacja wtyczki to najważniejszy krok. Wszystko inne jest ważne dla wykrywania i ograniczania.
Wykrywanie: jak bezpiecznie znaleźć wskaźniki kompromitacji
Przed podjęciem jakichkolwiek destrukcyjnych działań naprawczych, wykonaj kopię zapasową swojej strony i bazy danych. Następnie przystąp do ukierunkowanych kontroli wykrywania.
Przeszukaj bazę danych pod kątem tagów skryptów lub podejrzanych wzorców JS w typowych obszarach:
- Przeszukaj treść postów, postmeta, opcje i tabele specyficzne dla wtyczek.
- Przykłady zapytań WP‑CLI (uruchom po wykonaniu kopii zapasowej):
Przeszukaj postmeta pod kątem tagów skryptów:
wp db query "SELECT meta_id,post_id,meta_key,meta_value FROM wp_postmeta WHERE meta_value LIKE '%<script%';"Przeszukaj posty pod kątem skryptów inline:
wp db query "SELECT ID,post_title,post_content FROM wp_posts WHERE post_content LIKE '%<script%';"Przeszukaj tabelę opcji:
wp db query "SELECT option_id,option_name,option_value FROM wp_options WHERE option_value LIKE '%<script%';"Przeszukaj typowe atrybuty ładunków XSS:
wp db query "SELECT meta_id,meta_key,meta_value FROM wp_postmeta WHERE meta_value LIKE '%onerror=%' OR meta_value LIKE '%onload=%' OR meta_value LIKE '%javascript:%';"Jeśli masz dostęp do powłoki, możesz również przeszukać wyeksportowany zrzut bazy danych:
grep -i --line-number '<script' database-dump.sql
Ważny: Nie wykonuj operacji wyszukiwania/zastępowania na swojej żywej bazie danych przed wykonaniem zweryfikowanej kopii zapasowej. Niektóre usunięcia mogą uszkodzić zserializowane dane.
Szukaj ostatnich edycji na stronach administracyjnych wtyczki lub wpisach reklamowych. Jeśli twoja wtyczka przechowuje reklamy jako posty lub niestandardowe typy postów, sprawdź historię rewizji i identyfikatory użytkowników pod kątem podejrzanych współtwórców.
Sprawdź również logi pod kątem:
- Nietypowych logowań z kont współtwórców.
- Żądań do punktów końcowych edycji reklam z tych samych adresów IP.
- Nagłych wprowadzeń nowych skryptów w treści.
Jeśli zidentyfikujesz podejrzane wartości meta, skopiuj je do bezpiecznego środowiska offline do analizy — nie otwieraj ich w przeglądarce na maszynie administracyjnej.
Naprawa i czyszczenie (krok po kroku)
- Najpierw wykonaj kopię zapasową
Wykonaj pełną kopię zapasową witryny (pliki + baza danych) przed wprowadzeniem zmian. - Zaktualizuj wtyczkę do 2.0.99
Natychmiast zastosuj poprawkę dostawcy za pośrednictwem panelu administracyjnego lub swojego systemu wdrożeniowego. Potwierdź wersję wtyczki później. - Ograniczenie
- Jeśli nie możesz zaktualizować natychmiast, wyłącz wtyczkę lub tymczasowo ogranicz możliwości edytowania dla współpracowników w przypadku wpisów reklamowych.
- Dodaj regułę WAF na punktach końcowych związanych z reklamami, aby zablokować ładunki żądań zawierające tagi skryptów lub atrybuty obsługi zdarzeń (patrz sekcja WP‑Firewall poniżej).
- Zidentyfikuj i usuń przechowywane ładunki
- Użyj zapytań tylko do odczytu (jak pokazano w Wykryciu), aby znaleźć wpisy z
<script>lub podejrzane atrybuty. - Dla każdego podejrzanego wpisu:
- Eksportuj dane i analizuj offline.
- Jeśli jest wyraźnie złośliwy, usuń lub oczyść meta_value.
- Jeśli nie jesteś pewien, przenieś wpis do bezpiecznej tabeli przechowawczej (aby zachować ślad audytu) i zastąp meta_value oczyszczonym miejscem.
- Użyj zapytań tylko do odczytu (jak pokazano w Wykryciu), aby znaleźć wpisy z
- Rotuj dane uwierzytelniające i nonces
- Wymuś resetowanie haseł dla wszystkich kont administratorów, redaktorów i współpracowników.
- Unieważnij wszystkie nonces REST API, wymuszając wylogowania, jeśli podejrzewasz kradzież sesji.
- Jeśli podejrzewasz, że atakujący uzyskał dostęp przez konto, usuń podejrzanych użytkowników administratorów i przeglądaj dzienniki audytu.
- Skanuj w poszukiwaniu tylnej furtki i trwałości
- Uruchom skanowanie złośliwego oprogramowania w poszukiwaniu podejrzanych plików lub wstrzyknięć kodu PHP.
- Przeszukaj katalogi przesyłania, motywów i wtyczek w poszukiwaniu niedawno zmodyfikowanych plików lub plików zawierających
base64_decode,ocena,gzinflate,preg_replacez /e itd. - Usuń wszelkie nieautoryzowane pliki i przywróć zmodyfikowane pliki rdzenia/wtyczek/motywów z znanych dobrych kopii zapasowych lub świeżych kopii.
- Ponownie przeprowadź audyt witryny po oczyszczeniu
- Zweryfikuj, czy wszystkie instancje wtyczki są zaktualizowane.
- Potwierdź, że nie ma pozostałych wstrzykniętych skryptów w interfejsie front-end lub admin UI.
- Monitoruj dzienniki pod kątem nietypowego zachowania przez następne 7–14 dni.
Poprawki, które powinni zastosować deweloperzy (dla autorów / utrzymujących wtyczki)
Jeśli utrzymujesz niestandardowe wtyczki lub motywy, które interagują z metadanymi reklam, zastosuj następujące praktyki bezpiecznego kodowania:
- Waliduj i oczyszczaj wszystkie dane wejściowe przy zapisie:
- Dla pól tekstowych: użyj
dezynfekuj_pole_tekstowe(). - Dla HTML, które musi być dozwolone: użyj
wp_kses()z wyraźną białą listą dozwolonych tagów/atrybutów (nigdy nie pozwalaj na tagi skryptów).
- Dla pól tekstowych: użyj
- Escapuj wszystkie dane wyjściowe w kontekście renderowania:
esc_html()dla tekstu ciała HTML.esc_attr()dla atrybutów.wp_kses_post()jeśli pozwalasz na HTML w stylu postów, ale nadal chcesz bezpiecznego podzbioru WordPressa.
- Używaj kontroli uprawnień i nonce dla wszystkich operacji zapisu:
bieżący_użytkownik_może( 'edit_posts' )nie jest wystarczające dla uprzywilejowanych działań; użyj wymaganej ścisłej zdolności.- Weryfikacja
wp_verify_nonce()przed zapisaniem.
- Przechowuj surowy, zaufany HTML tylko wtedy, gdy jest to absolutnie konieczne i tylko dla użytkowników na poziomie administratora z
'nieprzetworzony_html'unfiltered_html. - Podczas zapisywania zserializowanych tablic w bazie danych upewnij się, że wszelkie manipulacje używają
maybe_unserializeImaybe_serializei zachowują integralność danych.
Przykład oczyszczania przy zapisie:
<?php
Przykład escapowania przy wyjściu:
echo '<div class="ad-title">' . esc_html( $ad_title ) . '</div>';'<div class="ad-code">' . wp_kses( $ad_code, $allowed ) . '</div>';
Kontrole zapobiegawcze i wzmacnianie (obrona w głębokości)
- Zasada najmniejszych uprawnień
- Ogranicz, które role mogą tworzyć/edytować wpisy reklamowe. Współpracownicy rzadko potrzebują zarządzać reklamami.
- Używaj niestandardowych uprawnień, jeśli wtyczka je obsługuje (np.,
zarządzaj_reklamami) i przypisuj je rozsądnie.
- Wyłącz unfiltered_html dla niższych ról
- Tylko administratorzy powinni mieć dostęp do
Ogranicz uprawnienia użytkowników: obniż lub usuń możliwości z niezaufanych kont i przeglądaj role zunfiltered_html. - Użyj wtyczek do zarządzania rolami lub filtru uprawnień, aby upewnić się, że współpracownicy nie mogą publikować surowego HTML.
- Tylko administratorzy powinni mieć dostęp do
- Polityka bezpieczeństwa treści (CSP)
- Zastosuj nagłówek CSP na całej stronie, aby zablokować skrypty inline i niebezpieczne wzorce eval, gdzie to możliwe.
- Przykład bardzo surowej polityki (może wymagać dostosowania dla legalnych skryptów inline):
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.example.com; object-src 'none'; base-uri 'self'; - CSP nie zatrzyma przechowywanego XSS we wszystkich przypadkach (ponieważ skrypty inline mogą być dozwolone), ale prawidłowo wdrożone CSP może znacznie podnieść poprzeczkę.
- Ciasteczka HttpOnly i Secure
- Upewnij się, że ciasteczka uwierzytelniające mają ustawione flagi HttpOnly i Secure. To zapobiega odczytywaniu ciasteczek przez JavaScript w wielu przypadkach.
- Uwierzytelnianie dwuskładnikowe (2FA)
- Wymagaj 2FA dla redaktorów i administratorów, aby zmniejszyć wpływ kradzieży danych uwierzytelniających.
- WAF / Wirtualne łatanie.
- Użyj odpowiednio dostosowanej zapory aplikacji webowej, aby zablokować oczywiste wzorce XSS, aż będziesz miał czas na poprawki i czyszczenie.
- Monitorowanie i powiadamianie
- Ustaw alerty dla nowych użytkowników administratorów, zmian plików oraz modyfikacji wtyczek/tematów.
- Zachowaj dzienniki audytowe przez co najmniej 90 dni w celu badania incydentów.
- Wdroż procedury testowe w etapach
- Testuj aktualizacje wtyczek najpierw w środowiskach stagingowych i miej plan awaryjny aktualizacji.
Jak zarządzana WAF + skaner złośliwego oprogramowania chroni Cię podczas łatania
Jeśli nie możesz natychmiast zaktualizować każdej dotkniętej strony (na przykład dziesiątek stron klientów lub zarządzanych instalacji multisite), zarządzana zapora aplikacji webowej (WAF) może zapewnić tymczasowe, skuteczne łagodzenie:
- WAF może blokować ładunki zawierające skrypty inline, podejrzane obsługiwacze zdarzeń (onerror, onload) lub próby wstrzyknięcia JavaScript do punktów końcowych metadanych reklam.
- Zasady wirtualnego łatania mogą być szybko wdrażane, aby zablokować wzorce eksploatacji specyficzne dla tego komunikatu, bez zmiany jakiegokolwiek kodu na Twojej stronie.
- Skanery złośliwego oprogramowania pomagają wykrywać przechowywane ładunki w bazie danych i plikach, co pozwala na priorytetyzację i czyszczenie dotkniętych wpisów.
- Zaawansowane oferty zarządzane łączą blokowanie WAF z pomocą w usuwaniu i skanowaniem w celu wykrycia trwałości.
Uwaga: WAF-y nie są substytutem aktualizacji podatnych wtyczek. Są warstwą łagodzącą, która zmniejsza ryzyko eksploatacji podczas łatania i czyszczenia.
Lista kontrolna bezpiecznej reakcji na incydenty (zwięzła)
- Zrób kopię zapasową witryny (pliki + DB).
- Zaktualizuj wtyczkę do 2.0.99.
- Jeśli aktualizacja jest opóźniona, wyłącz wtyczkę lub ogranicz dostęp do edytowania dla współpracowników.
- Przeprowadź skanowanie bazy danych w poszukiwaniu tagów skryptów i podejrzanych atrybutów.
- Usuń lub oczyść złośliwe wartości meta (przetestuj w środowisku testowym).
- Wymuś resetowanie haseł i przeglądaj konta użytkowników.
- Skanuj w poszukiwaniu webshelli i nieautoryzowanych plików; usuń i przywróć czyste wersje.
- Zmień wszelkie klucze API lub zewnętrzne dane uwierzytelniające, jeśli zostały ujawnione.
- Wzmocnij bezpieczeństwo strony (CSP, ciasteczka HttpOnly, 2FA).
- Monitoruj logi i ustaw powiadomienia.
Przykład: polecenia WP‑CLI, aby ułatwić szybką pracę (bezpieczne użycie)
- Zaktualizuj wszystkie wtyczki do najnowszej wersji (zalecane po przetestowaniu):
wp plugin update --all
- Zaktualizuj konkretną wtyczkę (bezpieczne, jeśli slug wtyczki jest poprawny):
wp wtyczka aktualizacja quick-adsense-reloaded
- Wyszukaj tagi skryptów w tabeli postów:
wp db query "SELECT ID,post_title FROM wp_posts WHERE post_content LIKE '%<script%';"
- Zrzutuj podejrzane wiersze meta do pliku do przeglądu offline:
wp db query "SELECT * FROM wp_postmeta WHERE meta_value LIKE '% suspect-meta.csv
Zawsze testuj aktualizacje bazy danych w środowisku testowym i przechowuj kopie zapasowe.
Po incydencie: długoterminowe zmiany operacyjne
- Wprowadź surowsze przepływy pracy dla współpracowników: wymagaj od redaktorów zatwierdzenia treści reklamowej i oczyszczenia źródeł reklam przed publikacją.
- Skoncentruj zarządzanie reklamami: ogranicz edytowanie reklam do małej grupy zaufanych użytkowników i używaj szablonów zamiast swobodnego wprowadzania kodu reklamowego.
- Okresowe zautomatyzowane skanowania: zaplanuj kontrole integralności bazy danych i plików, aby wcześnie wykrywać próby wstrzyknięcia.
- Edukacja i proces: szkolenie współtwórców treści na temat ryzyka osadzania skryptów i wymaganie, aby używane były tylko zatwierdzone fragmenty reklamowe.
Natychmiastowa, bezkosztowa ochrona dla Twojej witryny
Natychmiastowa, bezkosztowa ochrona dla Twojej witryny
Jeśli chcesz szybkiej, zawsze aktywnej warstwy ochronnej podczas aktualizacji i czyszczenia, rozważ zapisanie się na darmowy plan WP‑Firewall. Poziom podstawowy (darmowy) obejmuje zarządzany zaporę, nieograniczoną przepustowość, WAF na poziomie aplikacji, skaner złośliwego oprogramowania oraz łagodzenie ryzyk OWASP Top 10 — wszystko, co potrzebne, aby zredukować ryzyko ataków takich jak to przechowywane XSS podczas wdrażania poprawek. Rozpocznij tutaj: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Jeśli potrzebujesz automatycznego usuwania złośliwego oprogramowania, czarnej/białej listy adresów IP, miesięcznych raportów i wirtualnych poprawek, nasze płatne plany są dostępne — ale darmowy plan zapewnia Ci niezbędną ochronę od razu.
Ostateczne uwagi — priorytetyzacja i harmonogram
- Najwyższy priorytet: natychmiast zaktualizować wtyczkę do 2.0.99 na każdej dotkniętej witrynie.
- Drugorzędny: wyszukiwanie przechowywanych ładunków, bezpieczne ich usunięcie i rotacja poświadczeń.
- Tercjarny: wdrożenie obrony w głębokości (CSP, 2FA, wzmocnienie ról, zasady WAF).
Przechowywane XSS jest częstym wektorem w ekosystemach WordPress, ponieważ treść i metadane są podstawowymi funkcjami. Różnica między drobnym incydentem a przejęciem witryny często polega na tym, jak szybko przeprowadzane są łatanie, wykrywanie i ograniczanie.
Jeśli chcesz szybkiej listy kontrolnej lub podręcznika naprawczego, który możesz wdrożyć, utrzymujemy szablony i skrypty do czyszczenia i wykrywania, które są bezpieczne do wykonania (po wykonaniu kopii zapasowej). Jeśli wolisz, darmowy plan WP‑Firewall (link powyżej) zapewnia Ci natychmiastową zarządzaną ochronę WAF i skanowanie podczas łatania i czyszczenia.
Bądź bezpieczny i traktuj treści pochodzące od współtwórców, które zawierają HTML, z dodatkową uwagą. Jeśli potrzebujesz pomocy w triage'u zainfekowanej witryny lub zastosowaniu wirtualnej poprawki podczas aktualizacji, nasz zespół może pomóc w odpowiedzi na incydenty i analizie.
