Nazwa wtyczki	Integracja WP Google Maps
Rodzaj podatności	Atak typu cross-site scripting (XSS)
Numer CVE	CVE-2026-7464
Pilność	Średni
Data publikacji CVE	2026-05-12
Adres URL źródła	CVE-2026-7464

Odbity XSS w wtyczce “Integracja WP Google Maps” (<= 1.2) — Co każdy właściciel strony WordPress powinien wiedzieć

Data: 12 maja 2026
Wrażliwość: Odbite skrypty międzystronowe (XSS)
Dotknięta wtyczka: Integracja WP Google Maps (wersje <= 1.2)
CVE: CVE-2026-7464
Powaga: Średni — CVSS 7.1
Wymagane uprawnienia: Nieautoryzowany (wykorzystanie wymaga interakcji użytkownika)

Jako praktyk bezpieczeństwa WordPress, pracujący z WP‑Firewall, chcę przeprowadzić Cię przez rzeczywiste ryzyko, jakie stwarza ten problem odbitego XSS, jak napastnicy go nadużywają, jak wykryć, czy Twoja strona jest dotknięta, oraz praktyczne kroki łagodzenia i odzyskiwania, które możesz podjąć natychmiast — nawet jeśli oficjalna łatka wtyczki nie jest jeszcze dostępna.

To nie jest akademickie: luki w odbitym XSS są często wykorzystywane w kampaniach na dużą skalę. Nawet strony o niskim ruchu są atrakcyjne dla zautomatyzowanych napastników, ponieważ udane ładunki mogą zbierać pliki cookie, kraść sesje administratorów, wykonywać niechciane przekierowania lub prowadzić użytkowników do stron phishingowych i dystrybucji złośliwego oprogramowania.

---

Streszczenie wykonawcze (szybkie punkty do działania)

• Czym to jest: Luka w odbitym XSS występuje w wersjach wtyczki Integracja WP Google Maps ≤ 1.2. Napastnik może stworzyć link zawierający złośliwy ładunek, który, gdy zostanie kliknięty przez ofiarę (nawet nieautoryzowaną), uruchomi dostarczony przez napastnika JavaScript w przeglądarce ofiary.
• Uderzenie: Kradzież plików cookie sesji (jeśli nie są chronione), przejęcie konta, nieautoryzowane działania w kontekście ofiary, phishing, pobieranie złośliwego oprogramowania, lub inne ataki po stronie klienta.
• Natychmiastowe kroki (jeśli wtyczka jest zainstalowana):
  1. Jeśli dostępna jest oficjalna łatka wtyczki — zaktualizuj natychmiast.
  2. Jeśli łatka nie jest dostępna — wyłącz lub usuń wtyczkę, aż zostanie wydana łatka.
  3. Zastosuj zasady WAF, aby zablokować próby wykorzystania i oczyścić ruch.
  4. Wdróż CSP, ustaw pliki cookie jako HttpOnly i Secure, oraz przeglądaj logi w poszukiwaniu podejrzanych żądań.
  5. Skanuj stronę w poszukiwaniu wstrzykniętej treści i tylnej furtki; zmień hasła i klucze, jeśli to konieczne.
• Długoterminowo: Wzmocnienie, aktualizacje bezpiecznego kodowania dla autora wtyczki (oczyszczanie/escapowanie) oraz proces ujawniania luk.

---

Przegląd techniczny — co oznacza “odbity XSS” w tym kontekście?

Odbity XSS występuje, gdy aplikacja pobiera dane z żądania HTTP (parametr URL, pole formularza, nagłówek HTTP itp.) i włącza je w odpowiedzi HTML bez wystarczającego oczyszczania lub kodowania. Odpowiedź odzwierciedla dane napastnika z powrotem do przeglądarki użytkownika, gdzie złośliwy skrypt wykonuje się w kontekście strony.

Dla tej konkretnej luki (CVE‑2026‑7464):

• Wtyczka akceptuje dane wejściowe za pomocą parametru HTTP (lub innych elementów żądania) i odzwierciedla te dane z powrotem na stronie lub w odpowiedzi bez odpowiedniego eskapowania lub obsługi kontekstu HTML/JS.
• Luka może być wyzwalana bez wcześniejszej autoryzacji (atakujący tworzy link i przekonuje kogoś do kliknięcia), chociaż udane wykorzystanie wymaga, aby ofiara podjęła działanie (np. kliknięcie złośliwego linku lub odwiedzenie złośliwej strony).
• Ponieważ jest to odzwierciedlone (nie przechowywane), atakujący musi dostarczyć link do ofiary (np. inżynieria społeczna, phishing, wstrzykiwanie komentarzy na zewnętrznej stronie lub indeksowanie złośliwie stworzonych URL przez wyszukiwarki).

---

Typowe cele i scenariusze atakujących

Atakujący wykorzystują odzwierciedlone XSS do osiągnięcia kilku celów:

• Kradzież sesji: Jeśli ciasteczka nie są chronione przez HttpOnly lub jeśli jakiekolwiek tokeny są obecne w dostępnym JavaScript, skrypt może je odczytać i wyeksportować do atakującego.
• Eskalacja uprawnień za pomocą działań UI: Skrypt działający jako użytkownik może wykonywać działania, które użytkownik może wykonać (tworzenie postów, zmiana ustawień, wysyłanie wiadomości), w zależności od roli użytkownika i tokenów.
• Pobieranie drive-by / dystrybucja złośliwego oprogramowania: Przekierowywanie użytkowników do złośliwych domen lub wstrzykiwanie złośliwych skryptów, które ładują dodatkowe zasoby.
• Phishing: Prezentowanie fałszywego nakładki logowania administratora w celu kradzieży danych uwierzytelniających od administratorów strony.
• Rozpoznanie i pivot: Używane jako część szerszych kampanii w celu identyfikacji cennych celów lub propagacji dodatkowych ładunków.

Realistyczny przebieg ataku:
1. Atakujący tworzy URL zawierający ładunek skierowany na podatny parametr.
2. Atakujący wysyła URL do ofiar (e-mail, media społecznościowe, komentarze lub wyniki wyszukiwania).
3. Ofiara klika; strona odzwierciedla złośliwą treść, a przeglądarka ofiary ją wykonuje.
4. Złośliwy skrypt wykonuje działanie (kradzież ciasteczek, przekierowanie, przesyłanie formularza) i wysyła dane do atakującego.

---

Jak sprawdzić, czy twoja strona jest dotknięta

1. Zidentyfikuj, czy wtyczka jest zainstalowana:
   • W WP admin: Wtyczki → Zainstalowane wtyczki → szukaj “WP Google Maps Integration”.
   • Poprzez system plików: wp-content/plugins/wp-google-maps-integration (lub podobna nazwa katalogu).
2. Sprawdź wersję wtyczki:
   • W liście wtyczek WP admin lub w nagłówku głównego pliku PHP wtyczki (sprawdź wersję).
   • Jeśli wersja jest ≤ 1.2, traktuj stronę jako podatną, dopóki nie zostanie to zweryfikowane inaczej.
3. Szukaj dowodów prób wykorzystania w logach:
   • Logi dostępu serwera WWW (Apache/Nginx): żądania z ciągami zapytań zawierającymi <script>, JavaScript:, lub intensywne kodowanie URL, takie jak script.
   • Logi WordPressa lub logi wtyczek zabezpieczających: wiele nietypowych żądań GET do stron obsługiwanych przez wtyczkę.
4. Przeszukaj stronę w poszukiwaniu wstrzykniętego kodu:
   • Skanuj publiczne strony i strony administracyjne w poszukiwaniu nieoczekiwanych skryptów inline lub iframe'ów.
   • Użyj skanera złośliwego oprogramowania, aby znaleźć podejrzane pliki lub zmodyfikowane pliki rdzenia/wtyczek.
5. Użyj bezpiecznego testu manualnego (tylko jeśli wiesz jak i na kopii nieprodukcyjnej): zażądaj URL z zakodowanymi znacznikami i zobacz surową odpowiedź, aby sprawdzić, czy twój ładunek jest odzwierciedlany bez ucieczki. Jeśli nie jesteś pewien, nie testuj na produkcji — przeprowadź kontrolę w środowisku stagingowym.

Notatka: Unikaj publicznego udostępniania ciągów wykorzystania lub testowania na stronach, których nie posiadasz. Jeśli musisz zweryfikować, zrób to w sklonowanym lokalnym/środowisku stagingowym.

---

Natychmiastowe działania, które możesz zastosować (krok po kroku)

Jeśli masz stronę działającą na dotkniętej wersji i nie ma jeszcze dostępnej oficjalnej poprawki wtyczki, podejmij te działania w kolejności:

1. Kopia zapasowa
   Wykonaj pełną kopię zapasową strony (baza danych + pliki) przed wprowadzeniem zmian. To zachowuje stan do analizy kryminalistycznej.
2. Wyłącz lub usuń wtyczkę
   Najprostszy i najbezpieczniejszy natychmiastowy krok: dezaktywuj wtyczkę w panelu lub zmień nazwę jej folderu wtyczki za pomocą SFTP (wp-content/plugins/wp-google-maps-integration → dodaj .disabled). Usunięcie wtyczki eliminuje powierzchnię ataku.
3. Jeśli nie możesz dezaktywować wtyczki (wymóg zależności lub biznesowy), zastosuj tymczasowe zasady WAF
   • Zablokuj żądania, które zawierają typowe znaczniki XSS w ciągach zapytań dla stron obsługiwanych przez wtyczkę.
   • Zablokuj podejrzane wzorce żądań, np.: znaczniki skryptów, onmouseover, javascript:, data:, eval(,
   • Restrykcyjny CSP może zapobiec wykonaniu skryptów inline, nawet jeśli odzwierciedlona zawartość zawiera znaczniki skryptów. Na przykład:
     Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-'; object-src 'none'
   • CSP może być skomplikowane — najpierw przetestuj w trybie tylko raportowania, aby uniknąć przerwania legalnej funkcjonalności.
4. Monitoruj i skanuj
   Włącz skanowanie złośliwego oprogramowania i kontrole integralności. Przeszukaj logi w poszukiwaniu żądań z złośliwymi ładunkami i wszelkich dowodów na eksfiltrację danych. Sprawdź konta użytkowników i ostatnie działania administratorów.
5. Obracanie sekretów
   Jeśli podejrzewasz, że konto administratora mogło zostać skompromitowane, zmień hasła i klucze aplikacji (klucze API używane przez wtyczki, klucze API Google Maps, jeśli zostały ujawnione itp.).
6. Powiadom interesariuszy.
   Poinformuj administratorów, dostawców hostingu lub zarządzane zespoły bezpieczeństwa o ryzyku i podjętych działaniach.

---

Przykłady reguł WAF (wzorce do zablokowania)

Poniżej znajdują się przykłady reguł defensywnych, które możesz dostosować do swojego środowiska. Są celowo konserwatywne i powinny być testowane przed wdrożeniem produkcyjnym.

Wzorzec ModSecurity (ogólny) — blokuj oczywiste tagi skryptów w ciągach zapytań:

SecRule ARGS|ARGS_NAMES|REQUEST_URI|REQUEST_HEADERS "@rx (?i)(|<)\s*script" \n "id:100001,phase:2,deny,log,auditlog,msg:'Reflected XSS block - script tag in request',severity:2"

Zablokuj JavaScript: I dane: URIs w polach dostarczonych przez użytkownika:

SecRule REQUEST_URI|ARGS|ARGS_NAMES "@rx (?i)(javascript:|data:|vbscript:)" \n    "id:100002,phase:2,deny,log,msg:'Blokowanie podejrzanego schematu URI w argumentach'"

Blokowanie oparte na lokalizacji Nginx (proste):

if ($query_string ~* "(|<)\s*script") {
 return 403;
}

Ważny: Dostosuj i ogranicz takie reguły do punktów końcowych wtyczek lub stron, które wtyczka obsługuje, aby zredukować fałszywe alarmy i uniknąć przerwania legalnej funkcjonalności. Wdróż w stagingu i monitoruj logi.

---

Ciągi wykrywania i wskaźniki logów

Szukaj tych oznak w logach dostępu i analizach:

• Ciągi zapytań lub dane POST, które zawierają:
  • <script>, </script>, JavaScript:, onerror=, ładowanie=, oceniać(
  • Zakodowane formy: script, script, imgsrc=xonerror=
• Żądania do punktów końcowych wtyczek zawierające długie ładunki base64 lub URL‑zakodowane.
• Wzrost błędów 4xx lub 5xx dla stron zarządzanych przez wtyczkę (może wskazywać na sondowanie).
• Nieoczekiwane logowania administratorów po kliknięciu w podejrzane linki (wskazuje na kompromitację).
• Wyjściowe połączenia sieciowe do nieznanych domen z serwera (sygnalizacja eksfiltracji).

Ustaw alerty dla powtarzających się żądań pasujących do wzorców o wysokim poziomie pewności, aby działać szybciej.

---

Wytyczne dotyczące bezpiecznego kodowania dla deweloperów wtyczek (jak poprawnie naprawić).

Jeśli jesteś autorem wtyczki lub pracujesz z nimi, trwałe rozwiązanie wymaga odpowiedniego oczyszczania i kodowania danych wejściowych. Kluczowe zasady:

1. Oczyszczaj dane wejściowe wcześnie i waliduj typy.
   Dla wszelkich danych wejściowych, które muszą być liczbą, użyj intval() lub rzutuj na (int). Dla ciągów znaków, dodaj do białej listy akceptowalne wartości lub użyj odpowiednich filtrów.
2. Użyj ucieczki wyjścia zgodnie z kontekstem
   • Kontekst HTML: użyj esc_html() dla zwykłego tekstu drukowanego w HTML.
   • Kontekst atrybutów: użyj esc_attr() dla wartości wewnątrz atrybutów.
   • Kontekst JavaScript: użyj esc_js() dla wartości drukowanych w blokach skryptów lub JSON osadzonym w skryptach.
   • Kontekst URL: użyj esc_url_raw() Lub esc_url() przy umieszczaniu w href/src.
3. Unikaj wyświetlania surowych danych żądania
   Nigdy nie echo $_GET/$_POST/$_ŻĄDANIE bezpośrednio bez oczyszczania i ucieczki.
4. Używać pole_nonce_wp i kontrole możliwości
   Dla każdej akcji, która modyfikuje dane, wymagaj nonce i sprawdzaj możliwości użytkownika.
5. Używać wp_kses() dla kontrolowanego HTML
   Jeśli musisz zezwolić na ograniczony HTML, użyj wp_kses() z dozwoloną listą tagów zamiast zezwalać na dowolny HTML.
6. Przykładowy wzór naprawy (PHP):

<?php

7. Przy przekazywaniu wartości do JavaScript:

<?php

8. Unikaj odruchowego wyłączania sanitizacji dla wygody. Odpowiednie escape'owanie w kontekście to właściwe rozwiązanie.

---

Podręcznik reakcji na incydenty w przypadku podejrzenia wykorzystania

Jeśli podejrzewasz udany atak, wykonaj następujące kroki:

1. Izolować
   Tymczasowo wyłącz wtyczkę i wszelkie publiczne strony, które mogą być wykorzystywane. Jeśli masz dostęp do środowiska stagingowego, odtwórz problem tam.
2. Triage i zbieranie dowodów
   Zachowaj logi (serwera WWW, debug WordPressa, logi wtyczek), kopie zapasowe i ostatnie zmiany plików. Zapisz znaczniki czasowe i dotknięte konta użytkowników.
3. Ograniczenie
   Usuń złośliwe ładunki (brudne pliki, niepożądane pliki PHP). Zmień hasła administratora, klucze API i wszelkie tokeny, które mogły zostać skompromitowane. Unieważnij sesje użytkowników, jeśli podejrzewasz przejęcie sesji.
4. Eradykacja
   Zastąp zainfekowane pliki czystymi kopiami lub przywróć z czystej kopii zapasowej. Ponownie zainstaluj wtyczki/tematy z zaufanych źródeł. Nie przywracaj kopii zapasowych, które mogą już zawierać tylne drzwi.
5. Powrót do zdrowia
   Uważnie monitoruj stronę pod kątem reinfekcji. Ponownie zastosuj środki wzmacniające (WAF, CSP, surowe flagi cookie).
6. Działania po incydencie
   Przeprowadź pełny przegląd forensyczny, aby zrozumieć wektory ataku i ich wpływ. Zainstaluj poprawki w systemach i upewnij się, że wtyczka jest zaktualizowana, gdy dostępna jest bezpieczna wersja. Powiadom dotkniętych użytkowników, jeśli wrażliwe dane mogły zostać ujawnione, zgodnie z obowiązującymi przepisami i politykami.

---

Praktyczne zalecenia — priorytetowa lista kontrolna

Wysoki priorytet (zrób natychmiast)

• Jeśli poprawka jest dostępna, natychmiast zaktualizuj wtyczkę.
• Jeśli poprawka nie jest dostępna, dezaktywuj lub usuń wtyczkę.
• Zastosuj zasady WAF / blokowanie na krawędzi, aby złagodzić próby wykorzystania.
• Wykonaj kopię zapasową witryny i zachowaj logi.
• Skanuj w poszukiwaniu wskaźników kompromitacji.

Średni priorytet (w ciągu 24–72 godzin)

• Wdrażaj lub zaostrzaj politykę bezpieczeństwa treści.
• Ustaw ciasteczka na Secure i HttpOnly oraz skonfiguruj SameSite.
• Zmień krytyczne hasła i klucze API.
• Przejrzyj konta administratorów i użytkowników pod kątem podejrzanej aktywności.

Długi okres (ciągły)

• Monitoruj ruch i logi WAF w poszukiwaniu anomalii.
• Wzmocnij inne wtyczki — sprawdź podobne problemy z refleksją.
• Zachęcaj twórców wtyczek do przyjmowania bezpiecznych praktyk kodowania.
• Używaj środowisk stagingowych do walidacji aktualizacji wtyczek przed wdrożeniem na produkcję.

---

Dlaczego WAF (Web Application Firewall) ma tutaj znaczenie

Prawidłowo skonfigurowany WAF zapewnia niezbędną warstwę obrony przed lukami, które zostały odkryte, ale jeszcze nie załatane w górę. Dla refleksyjnego XSS:

• WAF może blokować żądania zawierające klasyczne wzorce XSS i znane kodowania exploitów.
• Zasady WAF mogą być skierowane na konkretne punkty końcowe wtyczek, aby zmniejszyć liczbę fałszywych alarmów.
• Wirtualne łatanie (tymczasowe zasady blokujące próby wykorzystania) zyskuje czas, aż oficjalna łatka będzie dostępna.
• W połączeniu z ograniczaniem szybkości i wykrywaniem botów, WAF zmniejsza możliwość zautomatyzowanego masowego wykorzystania.

Notatka: WAF-y nie są zastępstwem dla bezpiecznego kodowania. Są kontrolą kompensacyjną — cenną, gdy opracowywana i wdrażana jest trwała poprawka kodu.

---

Przykładowy bezpieczny zestaw reguł ModSecurity (dostosuj przed produkcją)

Blokuj powszechne wektory XSS w ciągach zapytań (dostosuj, aby zmniejszyć liczbę fałszywych alarmów):

SecRule REQUEST_URI|REQUEST_COOKIES|ARGS "@rx (?i)(|<)\s*(script|img|svg|iframe|object|embed|on\w+\s*=|javascript:|eval\()" \n "id:100100,phase:2,deny,log,status:403,msg:'Generic XSS mitigation - blocked potential reflected XSS attempt'"

Używaj list dozwolonych tam, gdzie to możliwe: sprawdzaj tylko ARGS_QUERY dla stron, które udostępnia wtyczka:

SecRule REQUEST_URI "@beginsWith /?page=wp-google-maps" \n    "id:100110,phase:1,pass,nolog,ctl:ruleEngine=On"

Jeszcze raz: to są przykłady ilustrujące podejście. Testuj dokładnie.

---

Często zadawane pytania

P: Wtyczka jest krytyczna dla mojej strony — czy mogę ją bezpiecznie utrzymać aktywną?
O: Jeśli nie możesz usunąć wtyczki, zastosuj surowe środki zaradcze: izoluj strony, które jej używają, za pomocą uwierzytelniania lub ograniczeń IP, użyj wirtualnych poprawek WAF skierowanych na punkty końcowe wtyczki, wzmocnij ciasteczka i wdrażaj CSP w trybie tylko raportowania, aby zidentyfikować możliwe awarie. Traktuj to jako tymczasowe, dopóki nie zostanie zainstalowana oficjalna bezpieczna wersja.

P: Czy odzwierciedlone XSS jest tak samo niebezpieczne jak XSS przechowywane?
O: Oba są niebezpieczne, ale XSS przechowywane często ma szerszy zasięg, ponieważ ładunek utrzymuje się i może wpływać na wielu użytkowników bez konieczności dostarczania linków przez atakującego. Odzwierciedlone XSS wymaga, aby atakujący oszukał ofiarę, aby kliknęła w spreparowany URL, ale nadal jest bardzo skuteczne w ukierunkowanych i masowych kampaniach phishingowych.

P: Czy usunięcie wtyczki zepsuje moją stronę?
O: Możliwe, jeśli twój motyw lub inna funkcjonalność na tym polega. Przed usunięciem sprawdź, czy możesz wyłączyć tylko funkcje mapy lub zastąpić funkcjonalność map bezpieczniejszą alternatywą. Zawsze wykonuj kopię zapasową przed wprowadzeniem zmian.

---

Zgłaszanie problemu i odpowiedzialne ujawnienie

Jeśli odkryjesz lukę, postępuj zgodnie z tymi najlepszymi praktykami:

• Zbierz powtarzalne kroki i minimalny przypadek testowy w środowisku nieprodukcyjnym.
• Skontaktuj się z autorem/konserwatorem wtyczki prywatnie i podaj szczegóły potrzebne do naprawy.
• Jeśli konserwator wtyczki nie odpowiada, rozważ powiadomienie platformy, na której wtyczka jest hostowana, i przestrzegaj ustalonych przez społeczność bezpieczeństwa terminów odpowiedzialnego ujawnienia.

Odpowiedzialne ujawnienie pomaga zapewnić, że dostawcy mogą bezpiecznie naprawić problemy, a użytkownicy są chronieni przy minimalnych szkodach ubocznych.

---

Ostateczne myśli: nie czekaj na katastrofę

Luki w odzwierciedlonym XSS, takie jak CVE‑2026‑7464 w integracji WP Google Maps, przypominają, jak jedna wtyczka może wprowadzić znaczące ryzyko. Najlepsza obrona łączy szybkie wykrywanie, natychmiastowe łagodzenie i długoterminowe poprawki:

• Wiedz, jakie wtyczki są zainstalowane i prowadź inwentaryzację.
• Utrzymuj kopie zapasowe i plan reakcji na incydenty.
• Używaj warstwowych zabezpieczeń: bezpieczne kodowanie, WAF, CSP, wzmocnienie ciasteczek, monitorowanie.
• Zastosuj wirtualne poprawki, gdy poprawka kodu nie jest jeszcze dostępna.

Jeśli chcesz szybko wdrożyć środki zaradcze na wielu stronach, zarządzany zapora z ukierunkowanymi zasadami może zmniejszyć okno narażenia, podczas gdy deweloperzy przygotowują bezpieczną poprawkę.

---

Uzyskaj natychmiastową ochronę z WP‑Firewall (plan darmowy) — Zabezpiecz swoją stronę WordPress teraz

Jeśli szukasz niskofrikcyjnego sposobu na ochronę swojej strony podczas sortowania aktualizacji wtyczek lub czekania na poprawki, rozważ plan podstawowy WP‑Firewall (darmowy). Oferuje on podstawowe zabezpieczenia, które odpowiadają dokładnie na klasę podatności opisanych powyżej:

• Zarządzany firewall z wirtualnym łatającym dla nowo ujawnionych podatności.
• Nielimitowana przepustowość, zasady WAF dostosowane do kontekstów WordPress.
• Skanowanie złośliwego oprogramowania w celu wykrycia niespodziewanych wstrzykniętych skryptów lub tylnej furtki.
• Łagodzenie ryzyka skierowane na 10 największych zagrożeń OWASP, w tym XSS, wstrzyknięcia i inne.

Nasz plan podstawowy (darmowy) pozwala natychmiast zablokować powszechne wzorce eksploatacji i zmniejszyć ryzyko podczas przeprowadzania głębszej naprawy. Zbadaj darmowy plan i szybko uzyskaj ochronę: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Późniejsze uaktualnienie dodaje automatyczne usuwanie, zarządzanie dozwolonymi/zakazanymi adresami IP, zaplanowane raporty bezpieczeństwa i wirtualne łatanie na dużą skalę — ale darmowy poziom to mocny pierwszy krok, jeśli potrzebujesz natychmiastowej, zarządzanej ochrony.

---

Zasoby i następne kroki.

• Sprawdź swój inwentarz wtyczek i potwierdź, czy “WP Google Maps Integration” jest obecny oraz jaka jest jego zainstalowana wersja.
• Wykonaj kopię zapasową swojej strony i, jeśli to konieczne, dezaktywuj wtyczkę, jeśli nie ma dostępnej poprawki.
• Zastosuj zasady WAF i CSP, aby zmniejszyć szansę na eksploatację.
• Przeprowadź pełne skanowanie złośliwego oprogramowania i integralności na swojej stronie.
• Jeśli zarządzasz wieloma stronami lub preferujesz rozwiązanie zarządzane, rozważ integrację zarządzanego WAF i usługi monitorowania, aby wdrożyć wirtualne poprawki i ciągłą ochronę.

Jeśli potrzebujesz pomocy w dostosowywaniu zasad, reagowaniu na incydenty lub walidacji poprawek, nasz zespół ds. bezpieczeństwa jest dostępny, aby doradzić w bezpiecznym wdrażaniu łagodzeń bez łamania funkcjonalności strony.

Bądź bezpieczny i utrzymuj swoje instalacje WordPress zaktualizowane i monitorowane.