Nazwa wtyczki	UsersWP
Rodzaj podatności	Atak typu cross-site scripting (XSS)
Numer CVE	CVE-2026-5742
Pilność	Średni
Data publikacji CVE	2026-04-13
Adres URL źródła	CVE-2026-5742

Pilne: UżytkownicyWP Przechowywane XSS (CVE-2026-5742) — Co właściciele stron WordPress muszą teraz zrobić

Autor: Zespół ds. bezpieczeństwa WP‑Firewall
Data: 2026-04-13
Tagi: WordPress, Bezpieczeństwo, Luka, WAF, UżytkownicyWP, XSS

Streszczenie: Została ujawniona luka w przechowywanym Cross‑Site Scripting (XSS) wpływająca na UżytkownikówWP (<= 1.2.60) (CVE-2026-5742). Uwierzytelnieni użytkownicy z uprawnieniami Subskrybenta mogą wstrzykiwać ładunki do pola linku odznaki, które mogą być później renderowane i wykonywane w kontekście innych użytkowników (w tym administratorów), gdy przeglądają określone elementy interfejsu użytkownika. Zaktualizuj do 1.2.61 natychmiast lub zastosuj wirtualne łatanie + kroki łagodzące poniżej.

Spis treści

• Co się stało (krótko)
• Dlaczego to ma znaczenie dla właścicieli stron WordPress
• Przegląd techniczny luki (powierzchnia ataku i wpływ)
• Kto jest narażony na ryzyko
• Natychmiastowe działania (lista kontrolna krok po kroku)
• Reakcja na incydent i sprzątanie
• Jak WAF (taki jak WP‑Firewall) pomaga — praktyczne łagodzenia
• Rekomendacje dotyczące wzmocnienia (kontrole zapobiegawcze)
• Monitorowanie, wykrywanie i długoterminowe poprawy postawy
• Bezpłatna opcja ochrony od WP‑Firewall — zacznij tutaj

---

Wstęp

W dniu 13 kwietnia 2026 roku ujawniono lukę w przechowywanym Cross‑Site Scripting (XSS) wpływającą na wtyczkę UsersWP (wersje <= 1.2.60) i przypisano jej CVE‑2026‑5742. Wada pozwala uwierzytelnionemu Subskrybentowi na przesyłanie stworzonych znaczników wewnątrz linku odznaki użytkownika, który jest później renderowany bez ucieczki dla innych użytkowników. Ponieważ ładunek może być przechowywany, staje się to trwałym ryzykiem: złośliwy wpis przetrwa ładowania strony i może wpływać na administratorów i redaktorów witryny, którzy przeglądają dotknięty interfejs użytkownika.

Rozumiemy, że wiele stron polega na UsersWP do profili użytkowników i odznak na froncie. Jako praktycy bezpieczeństwa WordPress, naszym priorytetem jest dostarczenie jasnych, praktycznych kroków — natychmiastowych i długoterminowych — aby zredukować narażenie i bezpiecznie się odbudować, jeśli zostaniesz dotknięty.

Co się stało (krótko)

• Wrażliwy komponent: Wtyczka UsersWP (wersje <= 1.2.60).
• Typ podatności: Przechowywane Cross‑Site Scripting (XSS).
• Wektor ataku: Uwierzytelniony użytkownik (Subskrybent) może wstrzyknąć stworzony ciąg linku odznaki, który jest później renderowany i wykonywany w przeglądarkach innych użytkowników.
• Wpływ: Wykonanie dowolnego JavaScript w kontekście ofiar (kradzież sesji, eskalacje uprawnień poprzez działania administratora, trwałe tylne drzwi, przekierowanie/wstrzykiwanie złośliwej treści).
• Dostępność łaty: Naprawione w UsersWP 1.2.61. Jeśli możesz zaktualizować, zrób to natychmiast.

Dlaczego to ma znaczenie dla właścicieli stron WordPress

• Przechowywane XSS jest szczególnie niebezpieczne: złośliwa treść pozostaje w twojej bazie danych i będzie serwowana każdemu, kto przegląda zainfekowany interfejs użytkownika.
• Wiele stron eksponuje profile i wyświetlanie odznak na stronach przeglądanych przez innych użytkowników i administratorów witryn, zwiększając szansę, że uprzywilejowany użytkownik nieświadomie uruchomi ładunek.
• Napastnicy mogą połączyć to z inżynierią społeczną (np. stworzony profil, który kusi administratorów do kliknięcia), aby przejąć konta lub przeprowadzać działania administracyjne.
• Wiele kampanii kompromitacyjnych polega na skompromitowanych kontach o niższych uprawnieniach jako punkcie wyjścia. Jeśli Twoja strona pozwala na rejestrację subskrybentów (lub edycję profilu w trybie samoobsługowym), musisz traktować to jako poważne ryzyko.

Przegląd techniczny (jak działa exploit — na wysokim poziomie)

Luka bezpieczeństwa powstaje, ponieważ pole linku odznaki (lub podobne pole profilu) akceptuje dane wejściowe od użytkownika, które są zapisywane w bazie danych i później wyświetlane w HTML bez odpowiedniej sanitizacji/escapingu. Złośliwy subskrybent może:

1. Dodać lub edytować wartość swojego linku odznaki, aby zawierała ładunek (na przykład, używając URI javascript:, osadzonego lub atrybutów obsługi zdarzeń w dozwolonym elemencie, lub innego złośliwego JavaScriptu).
2. Wtyczka przechowuje zawartość w bazie danych (przechowywane XSS).
3. Gdy inny użytkownik — być może administrator — przegląda stronę, na której wyświetlana jest odznaka, strona wyświetla tę przechowywaną zawartość na stronie bez odpowiedniego escapingu.
4. Przeglądarka ofiary wykonuje JavaScript z uprawnieniami tej strony (ciasteczka, dostęp do DOM, możliwość CSRF w zależności od kontekstu).
5. Napastnik uzyskuje tokeny sesji, wyzwala działania administratora, wstrzykuje złośliwy interfejs użytkownika lub utrzymuje tylne drzwi.

Dlaczego “uwierzytelniony subskrybent” ma znaczenie:

• Wiele stron pozwala na otwartą rejestrację i domyślnie przypisuje rolę subskrybenta. To sprawia, że eksploatacja jest dostępna dla zdalnych aktorów, którzy po prostu rejestrują konto.
• Ponieważ exploit wymaga interakcji użytkownika (uprzywilejowany użytkownik przeglądający zawartość), napastnicy często stosują inżynierię społeczną (np. pochlebne treści odznak) w celu zwiększenia szansy na to, że uprzywilejowani użytkownicy to zobaczą.

Potencjalne skutki udanej eksploatacji

• Kradzież ciasteczek uwierzytelniających lub tokenów, prowadząca do przejęcia konta administratora.
• Ciche modyfikacje treści strony, przekierowania do stron phishingowych lub złośliwego oprogramowania.
• Wstrzykiwanie dodatkowych złośliwych skryptów (reklamy, koparki kryptowalut).
• Tworzenie tylnych drzwi lub użytkowników administratora w celu utrzymania trwałości.
• Ekstrakcja danych (listy użytkowników, adresy e-mail).
• Utrata zaufania klientów, kary od wyszukiwarek i możliwe straty finansowe.

Kto jest narażony na ryzyko

• Strony używające UsersWP <= 1.2.60.
• Strony, które pozwalają na rejestrację użytkowników lub pozwalają subskrybentom edytować pola profilu wyświetlane innym użytkownikom.
• Strony, na których administratorzy lub redaktorzy przeglądają profile użytkowników lub listy odznak bez dodatkowej sanitizacji.
• Strony bez zapory aplikacji internetowej (WAF) lub z WAF, które nie obejmują wirtualnego łatania tego problemu.

Natychmiastowe działania (co zrobić teraz — priorytetowa lista kontrolna)

1. Zaktualizuj UsersWP do wersji 1.2.61 (lub nowszej)
   • To jest najskuteczniejsza metoda naprawy. Jeśli możesz zaktualizować natychmiast, zrób to.
   • Zawsze testuj aktualizacje wtyczek w środowisku testowym, jeśli to możliwe, przed wdrożeniem na produkcję.
2. Jeśli nie możesz zaktualizować natychmiast — zastosuj te pilne środki zaradcze
   • Tymczasowo wyłącz wtyczkę UsersWP (jeśli to możliwe).
   • Ogranicz dostęp do stron profilu/odznak do ról, które są zaufane (np. przekształć strony w widoki prywatne).
   • Tymczasowo zablokuj rejestracje użytkowników lub wymagaj zatwierdzenia administratora dla nowych kont.
   • Zastosuj zasady WAF (wirtualne łatanie), aby zablokować podejrzane dane wejściowe (przykłady poniżej).
   • Wymagaj, aby uprzywilejowani użytkownicy (administratorzy) przeglądali strony profili tylko z zabezpieczonego stanowiska roboczego administratora i unikali klikania w linki dostarczone przez użytkowników.
3. Skanuj i audytuj w poszukiwaniu złośliwych wpisów
   • Zapytaj bazę danych o pola linków odznak i podobne metadane użytkowników, które mogą zawierać podejrzane ciągi (przykłady poniżej).
   • Szukaj URI “javascript:”, tagów , atrybutów obsługi zdarzeń (onerror, onclick), URI data: z HTML w base64 lub długich zafałszowanych ciągów.
   • Zresetuj wszelkie uwierzytelnianie oparte na tokenach (klucze API), jeśli znajdziesz wskaźniki kompromitacji.
4. Zmień hasła administratorów i włącz MFA
   • Wymuś reset hasła dla wszystkich administratorów (i dla wszelkich użytkowników o wysokich uprawnieniach, którzy przeglądali podejrzane treści).
   • Wprowadź uwierzytelnianie wieloskładnikowe (MFA) dla wszystkich kont na poziomie administratora/redaktora.
5. Wykonaj kopię zapasową i zrzut
   • Utwórz offline kopię zapasową swojej strony (pliki + DB) przed wprowadzeniem jakichkolwiek zmian porządkowych.

Zapytania do bazy danych i wskazówki (dla administratorów strony)

Poniżej znajdują się przykładowe zapytania, które pomogą Ci szybko znaleźć podejrzane wartości przechowywane. Dostosuj prefiksy tabel, jeśli Twoja strona używa niestandardowego prefiksu.

Znajdź wpisy usermeta, które mogą zawierać linki do odznak:

WYBIERZ user_id, meta_key, meta_value;

Szukaj oczywistych ładunków JavaScript:

SELECT user_id, meta_key, meta_value;

Przeszukaj wp_posts lub niestandardowe tabele, jeśli dane renderowania odznak są przechowywane gdzie indziej:

SELECT ID, post_title, post_content;

Notatka: Te zapytania pomagają znaleźć oczywiste przypadki; napastnicy mogą zafałszować ładunki. Jeśli znajdziesz coś podejrzanego, zachowaj dowody i przystąp do czyszczenia i ograniczenia.

Reakcja na incydent i sprzątanie

Jeśli wykryjesz kompromitację lub podejrzewasz eksploatację, postępuj zgodnie z metodycznym procesem reagowania na incydenty:

1. Izolować
   • Tymczasowo wyłącz stronę, aby zapobiec dalszemu wykonaniu podczas badania.
   • Zablokuj adresy IP napastnika (ale pamiętaj, że napastnicy mogą używać rotujących adresów IP).
2. Zachowaj dowody
   • Eksportuj logi (serwera WWW, WAF, logi wtyczek) i migawki bazy danych do analizy.
   • Nie nadpisuj logów, dopóki śledztwo nie zostanie zakończone.
3. Usuń złośliwe wpisy
   • Albo usuń podejrzane wpisy meta_value, albo je oczyść (zastąp bezpiecznymi adresami URL).
   • Jeśli wiele wpisów jest dotkniętych, rozważ użycie skryptu zbiorczego do oczyszczenia lub usunięcia pól.
4. Zmień skompromitowane dane uwierzytelniające
   • Zresetuj hasła i unieważnij aktywne sesje (WordPress zapewnia zarządzanie sesjami).
   • Rotuj wszelkie ujawnione klucze API.
5. Zainstaluj ponownie pliki rdzenia/wtyczek/motywów
   • Zastąp rdzeń WordPressa, wtyczki i motywy świeżo pobranymi kopiami, aby upewnić się, że nie ma żadnych tylnych drzwi.
   • Sprawdź nieznane pliki w wp-content/uploads i innych katalogach, które można zapisywać.
6. Przywróć z czystej kopii zapasowej (jeśli to konieczne)
   • Jeśli nie możesz pewnie usunąć złośliwych artefaktów, przywróć z kopii zapasowej sprzed kompromitacji, a następnie zastosuj poprawki i wzmocnienia przed ponownym połączeniem.

Jak WAF (WP‑Firewall) pomaga — praktyczne środki zaradcze, które możesz zastosować teraz

Jeśli nie możesz natychmiast zaktualizować wtyczki, prawidłowo skonfigurowany zapora aplikacji internetowej (WAF) zapewnia szybkie, skuteczne wirtualne poprawki, podczas gdy planujesz pełne usunięcie. W WP‑Firewall publikujemy zasady łagodzenia, które blokują powszechne wzorce wykorzystania przechowywanego XSS, nie czekając na aktualizację wtyczki na każdej dotkniętej stronie.

Typowe możliwości łagodzenia WAF do zastosowania:

• Blokuj żądania POST/PUT, które próbują ustawić pola linków odznak zawierające:
  • javascript: URI
  • dane: URI zawierające text/html lub base64
  • tagi lub zakodowane odpowiedniki
  • Atrybuty obsługi zdarzeń, takie jak onerror=, onclick=, onmouseover=
• Blokuj żądania, w których dane wejściowe użytkownika zawierają podejrzane kodowanie lub złośliwy JS (długie ciągi base64 lub zagnieżdżone kodowanie).
• Oczyść wychodzący HTML, usuwając niebezpieczne atrybuty lub wymuszając walidację hrefów w stosunku do bezpiecznych schematów (http, https, mailto, jeśli to konieczne).
• Ograniczaj liczbę żądań z nowych lub anonimowych kont, aby utrudnić masowe wykorzystanie.
• Blokuj żądania z znanymi wzorcami wykorzystania lub podpisami ładunków.

Przykład (na wysokim poziomie) podejścia do reguł WAF

• Reguła A: Odrzuć żądania, w których parametr linku odznaki pasuje do regex dla niebezpiecznych schematów (niezależnie od wielkości liter):
  • Odrzuć, jeśli parametr zawiera “javascript:” lub “data:text/html” lub “<script”.
• Reguła B: Kwarantanna treści, jeśli meta_value zawiera “on[a-z]{2,12}=” (obsługiwane zdarzenia).
• Reguła C: Usuń tagi HTML z renderowania linku odznaki po stronie serwera, jeśli linki odznak nie potrzebują HTML.

(Celowo przedstawiamy te zasady jako zasady na wysokim poziomie. Klienci WP‑Firewall otrzymują wstępnie przetestowane zasady stosowane automatycznie przez pulpit nawigacyjny, aby uniknąć fałszywych pozytywów i zapewnić bezpieczne blokowanie.)

Uwaga na fałszywe pozytywy i dostosowywanie:

• Zawsze testuj zasady najpierw na stronach testowych.
• Skonfiguruj listy dozwolone dla zaufanych integracji, jeśli rzeczywiście muszą dostarczać złożony HTML.
• Użyj trybu tylko do logowania przez krótki czas, aby zweryfikować pokrycie zasad przed wymuszeniem odmowy.

Wzmocnienie na poziomie kodu (wytyczne dla programistów)

Jeśli utrzymujesz lub rozwijasz niestandardowy kod, który integruje się z UsersWP lub wyświetla linki do odznak użytkowników, natychmiast przyjmij te najlepsze praktyki:

• Waliduj i oczyszczaj dane wejściowe podczas zapisywania:
  • Dla pól URL używaj dezynfekcja_pola_tekstowego + esc_url_raw, i wymuszaj ograniczenia schematu.
  • Przykład:

  <?php

• Escapuj wyjście podczas renderowania:
  • Zawsze używaj funkcji escapujących odpowiednich do kontekstu:
    • Dla wartości atrybutów: esc_attr()
    • Dla atrybutów URL: esc_url()
    • Dla ogólnego HTML: wp_kses() z wyraźnie dozwoloną listą
  • Przykład:

  <?php

• Unikaj wyświetlania HTML dostarczonego przez użytkownika bez filtracji. Jeśli zezwalasz na jakiś HTML, użyj wp_kses() z rygorystyczną białą listą.
• Kontrole zdolności:
  • Ogranicz, kto może edytować niektóre pola: nie każda rola musi ustawiać treść HTML.
  • Przykład: zezwól tylko redaktorom+ na ustawianie bogatej treści, pozostaw podstawowe pola dla subskrybentów.

Rekomendacje dotyczące wzmocnienia (kontrole zapobiegawcze)

Poza środkami awaryjnymi i zasadami WAF, przyjmij te sprawdzone kontrole, aby zmniejszyć przyszłe ryzyko:

1. Zasada najmniejszych uprawnień
   • Ogranicz, co mogą robić konta subskrybentów. Nie dawaj im pól, które renderują HTML dla innych.
2. Kontrole rejestracji
   • Użyj weryfikacji e-mailowej lub zatwierdzenia przez administratora dla nowych rejestracji użytkowników.
   • Dodaj CAPTCHA do formularzy rejestracyjnych, aby zredukować automatyczne rejestracje.
3. Automatyczne aktualizacje
   • Gdzie to możliwe, włącz automatyczne aktualizacje wtyczek dla wtyczek krytycznych dla bezpieczeństwa. W przypadku stron o kluczowym znaczeniu przetestuj najpierw na etapie testowym, ale priorytetowo traktuj szybkie łatanie, gdy pojawi się luka o wysokim ryzyku.
4. Utrzymuj regularną strategię tworzenia kopii zapasowych.
   • Utrzymuj co najmniej jedną kopię zapasową poza siedzibą i przetestowany plan przywracania (zaleca się codzienne kopie zapasowe bazy danych, cotygodniowe pełne kopie zapasowe plików dla wielu stron).
5. Uwierzytelnianie dwuskładnikowe i silne hasła.
   • Wymuszaj MFA dla wszystkich kont administratorów/edytorów i zachęcaj do silnych polityk haseł w całej witrynie.
6. Ogranicz publiczne renderowanie treści z nieufnych danych wejściowych użytkowników.
   • Unikaj ujawniania surowych danych wejściowych użytkowników w kontekstach, które są wykonywane przez przeglądarki (skrypty, wewnętrzne obsługi zdarzeń lub niebezpieczne odpowiedniki innerHTML).
7. Przeglądy kodu zabezpieczeń
   • Regularnie przeglądaj motywy i wtyczki pod kątem niebezpiecznych wzorców wyjściowych i brakujących ucieczek.

Wykrywanie i monitorowanie

• Monitoruj logi serwera WWW i WAF pod kątem żądań zawierających “javascript:” lub nietypowe zakodowane ładunki.
• Śledź edycje profili użytkowników w logach audytowych; oznaczaj posty/edycje, które zawierają podejrzane ciągi.
• Wdrażaj monitorowanie integralności plików, aby wykrywać nieoczekiwane zmiany plików w wp-content (uploads, themes, plugins).
• Monitoruj skoki nieudanych logowań i nietypową aktywność administratorów.

Długoterminowa postawa: ludzie, proces, technologia.

• Ludzie: przeszkol swoich menedżerów witryn i administratorów, aby rozpoznawali inżynierię społeczną i podejrzane profile.
• Proces: utrzymuj listę kontrolną reagowania na incydenty i wyznacz właściciela incydentu dla każdej witryny.
• Technologia: łącz automatyczne łatanie, wirtualne łatanie WAF i regularne skanowanie, aby skrócić czas na złagodzenie.

Praktyczne przykłady: Na co zwracać uwagę w interfejsie administracyjnym

• Dziwne lub nietypowo sformatowane teksty odznak lub linki w profilach użytkowników.
• Profile z atrakcyjnym sformułowaniem mającym na celu przyciągnięcie kliknięć (np. “Kliknij moją odznakę, aby zobaczyć niespodziankę”, gdzie odznaki są pokazywane pracownikom).
• Użytkownicy utworzeni niedawno z niewielką inną aktywnością, ale z zmianami w profilach, które zawierają długie zakodowane ciągi.

Jeśli znajdziesz podejrzane treści, wyłącz je (dezaktywuj pole lub ukryj widget) i wykonaj powyższe kroki czyszczenia.

Lista kontrolna odzyskiwania (jedna strona)

• Zaktualizuj UsersWP do wersji 1.2.61 (lub nowszej)
• Tymczasowo wyłącz rejestracje użytkowników (jeśli to konieczne)
• Zrób kopię zapasową strony (pliki + DB)
• Audytuj metadane użytkowników i usuń podejrzane wpisy odznak
• Zresetuj hasła administratorów; wymuś MFA
• Skanuj stronę w poszukiwaniu złośliwego oprogramowania/tylnych drzwi; usuń wszelkie nieznane pliki
• Przejrzyj logi WAF i blokady zapory ogniowej w poszukiwaniu prób wykorzystania
• Ponownie włącz kontrolowany dostęp i monitoruj nietypową aktywność

Chroń swoją stronę już teraz — wypróbuj darmowy plan WP‑Firewall

Jeśli potrzebujesz natychmiastowej, praktycznej warstwy ochrony podczas łatania i czyszczenia, WP‑Firewall oferuje darmowy zarządzany plan zapory ogniowej, który obejmuje podstawowe zabezpieczenia, takie jak zarządzany WAF, nielimitowany transfer danych, skanowanie złośliwego oprogramowania i łagodzenie ryzyk OWASP Top 10. Został zaprojektowany, aby szybko zapewnić Ci ochronę przy minimalnej konfiguracji.

• Podstawowy (bezpłatny): Zarządzana zapora, nielimitowana przepustowość, WAF, skaner złośliwego oprogramowania, łagodzenie ryzyk OWASP Top 10.
• Standard ($50/rok): dodaje automatyczne usuwanie złośliwego oprogramowania oraz ograniczone czarne/białe listy IP.
• Pro ($299/rok): Dodaje miesięczne raportowanie bezpieczeństwa, automatyczne wirtualne łatanie podatności oraz wsparcie premium i usługi zarządzane.

Rozpocznij teraz z darmowym planem i pozwól nam zastosować zasady ochrony, podczas gdy łatasz i prowadzisz dochodzenie: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Stosujemy wcześniej przetestowane wirtualne łaty dla znanych podatności o wysokim ryzyku, aby Twoi administratorzy i redaktorzy nie byli narażeni podczas aktualizacji.)

Dlaczego wirtualne łatanie ma znaczenie

• Wirtualne łatanie za pomocą WAF to szybka tymczasowa obrona, która zapobiega próbom wykorzystania dotarcia do podatnych ścieżek kodu.
• Nie jest to zastępstwo dla stosowania poprawek dostawcy, ale daje czas na przetestowanie i zastosowanie odpowiednich poprawek bez narażania odwiedzających stronę lub administratorów na ryzyko.
• Dobry WAF może izolować próby wykorzystania, rejestrować szczegóły dla Twojej reakcji na incydenty i blokować najczęściej używane ładunki przez atakujących do przechowywanego XSS.

Ostatnie słowo od zespołu bezpieczeństwa WP‑Firewall

Przechowywane luki XSS mają duży wpływ, ponieważ utrzymują się i mogą wpływać na uprzywilejowanych użytkowników witryny. Natychmiastowy krok jest prosty: zaktualizuj UsersWP do poprawionej wersji (1.2.61 lub nowszej). Jeśli nie możesz tego zrobić od razu — zastosuj wirtualne łatanie, zablokuj rejestrację użytkowników, jeśli to odpowiednie, przeszukaj wskaźniki i zmień dane uwierzytelniające administratora.

Jeśli obsługujesz wiele witryn lub zarządzasz witrynami dla klientów, potraktuj to ujawnienie jako przypomnienie o wdrożeniu automatycznych zabezpieczeń: zarządzana ochrona WAF, automatyzacja aktualizacji tam, gdzie to bezpieczne, oraz powtarzalny plan reakcji na incydenty. Jeśli potrzebujesz pomocy w ocenie swojego narażenia, zastosowaniu wirtualnych łatek lub oczyszczeniu dotkniętej witryny, nasz zespół jest dostępny, aby Cię wspierać.

Dodatek: szybkie zasoby i kontrole

• Łata (UsersWP) do 1.2.61 — najwyższy priorytet.
• Szybkie kontrole DB: wyszukaj meta_value zawierające “javascript:” lub “<script”.
• Zalecane ucieczki wyjściowe: esc_url(), esc_attr(), esc_html(), wp_kses() z rygorystyczną białą listą.
• Wzorce awaryjnego WAF (koncepcyjne): odrzucaj “javascript:” URI, usuwaj tagi , zabraniaj obsług zdarzeń inline w polach linków odznak.

Jeśli chcesz drugiej pary oczu na swojej witrynie lub chcesz wdrożyć automatyczne wirtualne łatanie w ciągu kilku minut, rozważ darmowy plan WP‑Firewall (link powyżej) — zapewnia on niezbędne, zarządzane zabezpieczenia, dzięki którym możesz priorytetowo traktować łatanie i oczyszczanie bez narażania administratorów lub odwiedzających na niepotrzebne ryzyko.

Bądź bezpieczny,
Zespół ds. bezpieczeństwa WP‑Firewall