Nazwa wtyczki	WP Responsywny Popup + Optin
Rodzaj podatności	CSRF
Numer CVE	CVE-2026-4131
Pilność	Średni
Data publikacji CVE	2026-04-22
Adres URL źródła	CVE-2026-4131

Pilne: CSRF → Przechowywane XSS w “WP Responsywny Popup + Optin” (≤ 1.4) — Co właściciele stron muszą zrobić teraz

Autor: Zespół ds. bezpieczeństwa WP‑Firewall
Data: 2026-04-22
Tagi: WordPress, WAF, CSRF, XSS, bezpieczeństwo-wtyczek, reakcja-na-incydenty

Podsumowanie: Niedawno ujawniona luka (CVE-2026-4131) dotyczy wersji ≤ 1.4 wtyczki “WP Responsywny Popup + Optin”. Wada pozwala nieautoryzowanym atakującym na wywołanie Cross-Site Request Forgery (CSRF), co może prowadzić do przechowywanego Cross-Site Scripting (XSS) w bazie danych strony — ostatecznie umożliwiając trwałe wykonywanie JavaScript w kontekście administratora lub odwiedzającego. Niniejsze zalecenie wyjaśnia ryzyko, jak atakujący je wykorzystują oraz priorytetowy, praktyczny plan łagodzenia i odzyskiwania z perspektywy WP‑Firewall — twojej zapory aplikacji WordPress i zespołu bezpieczeństwa.

Spis treści

• Co się stało (krótko)
• Dlaczego to ma znaczenie
• Techniczne przyczyny i przegląd wykorzystania
• Kto jest narażony na ryzyko
• Natychmiastowe działania dla właścicieli stron (lista blokad)
• Średnioterminowe kroki naprawcze (deweloperzy i administratorzy)
• Jak sprawdzić, czy zostałeś skompromitowany
• Wzmocnienie: zasady WAF, ustawienia serwera i WordPressa
• Przykładowe poprawki i zalecane zmiany w kodzie
• Lista kontrolna reakcji na incydenty i odzyskiwanie
• Jak WP‑Firewall pomaga (zarządzane łagodzenie i darmowy plan)
• Dodatek: zapytania i polecenia dochodzeniowe

---

Co się stało (krótko)

Luka w wtyczce “WP Responsywny Popup + Optin” (wersje do i włącznie 1.4) została ujawniona 22 kwietnia 2026 roku i przypisana do CVE‑2026‑4131. Jest to słabość Cross‑Site Request Forgery (CSRF), która może być wykorzystana do wstrzykiwania przechowywanych ładunków Cross‑Site Scripting (XSS) do bazy danych WordPressa. Ponieważ przechowywane ładunki XSS mogą być wykonywane, gdy administratorzy lub odwiedzający ładują dotkniętą treść popup, atakujący może eskalować do pełnych scenariuszy przejęcia strony (w tym kradzieży sesji użytkownika, dowolnych działań jako zalogowani administratorzy lub dostarczania złośliwego oprogramowania do odwiedzających).

Dlaczego to ma znaczenie — rzeczywiste ryzyko dla twojej strony

• CSRF w połączeniu z przechowywanym XSS jest niebezpieczne. CSRF wprowadza treść na stronę (bez potrzeby autoryzacji), a przechowywane XSS sprawia, że ta treść działa w przeglądarce każdego uprzywilejowanego użytkownika, który ogląda popup. Jeśli administrator załadowuje zainfekowany popup, atakujący może przejąć tę sesję administratora i wykonać przejęcie konta lub zainstalować tylne drzwi.
• Luka jest łatwa do wywołania na dużą skalę. Atakujący mogą zautomatyzować żądania i szybko próbować zainfekować wiele stron.
• Wykorzystania często pojawiają się w masowych kampaniach. Strony WordPress korzystające z podatnych wtyczek są atrakcyjne, ponieważ często można je wykorzystać bez skomplikowanego celowania lub dużych wolumenów ruchu.

Techniczne przyczyny i przegląd wykorzystania (zwięzłe, ale wykonalne)

Podsumowanie przyczyny źródłowej

• Wtyczka udostępnia jeden lub więcej punktów końcowych (prawdopodobnie obsługiwanych przez AJAX w panelu administracyjnym lub na froncie), które akceptują dane używane do tworzenia lub aktualizacji treści popup.
• Te punkty końcowe nie weryfikują ważnego nonce WordPressa ani nie egzekwują odpowiednich kontroli uprawnień.
• Dane wejściowe są przechowywane bez odpowiedniej sanitizacji/escapingu dla kontekstów przechowywanych danych wyjściowych (np. tytuł, treść HTML dla popupów), co pozwala na utrzymywanie tagów skryptów lub obsług zdarzeń w polach bazy danych, które są później renderowane na stronach administracyjnych lub dla odwiedzających.

Łańcuch exploita (na wysokim poziomie)

1. Atakujący tworzy żądanie CSRF (GET lub POST) do podatnego punktu końcowego, które zawiera ładunek z treścią zawierającą ładunek JavaScript (np. lub atrybuty zdarzeń).
2. Podatny punkt końcowy nie weryfikuje nonce/uprawnień i przechowuje ładunek w bazie danych.
3. Gdy administrator lub użytkownik odwiedza stronę, która renderuje treść popup, przechowywany ładunek wykonuje się w ich przeglądarce (przechowywane XSS).
4. Ładunek może:
   • Kradzież ciasteczek administracyjnych / tokenów sesji lub wykonywanie działań za pomocą AJAX jako administrator.
   • Dodawanie nowych użytkowników administracyjnych, modyfikowanie wtyczek/motywów, przesyłanie backdoorów.
   • Przekierowywanie odwiedzających na strony phishingowe/malware.

Kto jest narażony na ryzyko

• Każda strona WordPress z zainstalowaną wtyczką “WP Responsive Popup + Optin” w wersjach ≤ 1.4.
• Strony, które pozwalają na nieautoryzowane żądania do punktów końcowych wtyczki (standardowe instalacje WP).
• Strony, na których administratorzy lub redaktorzy odwiedzają podgląd popup lub gdzie treść popup pojawia się na stronach administracyjnych lub na froncie.

Ważny: ostrzeżenie wskazuje “Nieautoryzowany” jako wymagane uprawnienie do rozpoczęcia ataku. Atak nadal wymaga interakcji użytkownika w tym sensie, że uprzywilejowany użytkownik musi zobaczyć przechowywany ładunek, aby przechowywane XSS mogło się wykonać, ale początkowa iniekcja może być wykonana przez każdego.

Natychmiastowe działania (co powinieneś zrobić teraz — w kolejności priorytetowej)

Jeśli zarządzasz stronami WordPress, podejmij te kroki natychmiast (w tej kolejności):

1. Identyfikacja dotkniętych miejsc
   • Przeszukaj swoje strony pod kątem nazwy katalogu wtyczki (wp-popup-optin lub slug wtyczki). Jeśli jest obecna i wersja ≤ 1.4, uznaj ją za podatną.
   • Jeśli używasz centralnego panelu zarządzania, filtruj według zainstalowanych wtyczek i wersji.
2. Jeśli łatka nie jest dostępna: wyłącz wtyczkę
   • Jeśli oficjalna poprawka nie jest jeszcze dostępna dla zainstalowanej wersji, natychmiast dezaktywuj wtyczkę. Dezaktywacja zakłóca funkcjonalność popupów, ale zapobiega dalszemu automatycznemu wykorzystaniu.
   • W CLI: wp wtyczka dezaktywuj wp-popup-optin
   • Z WP Admin: Wtyczki > Zainstalowane wtyczki > Dezaktywuj
3. Jeśli nie możesz dezaktywować natychmiast, zastosuj łagodzenie WAF
   • Wprowadź tymczasową regułę w swoim WAF, aby zablokować żądania do punktów końcowych wtyczki (akcje admin-ajax.php, specyficzne punkty końcowe AJAX wtyczki lub POST-y na stronie administracyjnej). Zobacz nasze zalecane reguły WAF poniżej.
4. Sprawdź konta administratorów i zresetuj dane uwierzytelniające
   • Sprawdź nowe lub nieznane konta administratorów. Usuń lub dezaktywuj je.
   • Zmień hasła dla istniejących administratorów i kont serwisowych.
   • Wymuś MFA dla kont administratorów.
5. Skanuj w poszukiwaniu przechowywanych artefaktów XSS
   • Przeszukaj bazę danych w poszukiwaniu podejrzanych skryptów lub ciągów zdarzeń w postach, postmeta, opcjach i tabelach wtyczek (zapytania SQL podane później).
6. Włącz monitorowanie i logowanie
   • Włącz szczegółowe logowanie żądań na krótki czas, aby uchwycić potencjalne próby wykorzystania (w miarę możliwości dołącz ciała POST).
   • Jeśli używasz scentralizowanego logowania, oznacz datę/godzinę działania i zachowaj logi do analizy kryminalistycznej.

Średnioterminowe działania naprawcze (deweloperzy i opiekunowie)

• Zaktualizuj wtyczkę, gdy zostanie wydana oficjalna poprawka. Jeśli oficjalna poprawka dostawcy stanie się dostępna, zweryfikuj ją przed ponownym włączeniem wtyczki.
• Jeśli wtyczka będzie nadal używana, poproś lub wdroż poprawki upstream:
  • Wymuś sprawdzenie uprawnień (current_user_can dla działań administratora).
  • Użyj check_admin_referer lub wp_verify_nonce dla wszystkich punktów końcowych zmieniających stan.
  • Oczyść dane wejściowe przed przechowaniem i escape na wyjściu:
    • Oczyść za pomocą odpowiednich funkcji WordPressa (sanitize_text_field, wp_kses_post) w zależności od dozwolonego HTML.
    • Przy wyjściu użyj esc_html, esc_attr lub wp_kses_post w zależności od kontekstu.
  • Dodaj nagłówki Polityki Bezpieczeństwa Treści (CSP), aby ograniczyć źródła wykonywania skryptów i złagodzić wpływ przyszłych przechowywanych XSS.
  • Wprowadź Politykę Bezpieczeństwa Treści z default-src ‘self’; script-src ‘self’ ‘nonce-{random}’; tam, gdzie to odpowiednie.

Jak sprawdzić, czy zostałeś skompromitowany — praktyczne kroki wykrywania

Przeszukaj bazę danych w poszukiwaniu oczywistych wstrzykniętych ładunków (przykładowe zapytania)

• Szukaj tagów , “onload=”, “onerror=”, “javascript:” lub podejrzanych tagów iframe przechowywanych w wspólnych tabelach treści.

Przykłady (uruchom na kopii stagingowej lub z dostępem tylko do odczytu DB):

-- Posty i strony:.

Przeszukaj system plików w poszukiwaniu webshelli i nieoczekiwanych plików

• Wspólne wskaźniki webshelli: base64_decode z eval, assert, system, shell_exec z danymi POST.
• Komendy (shell Linux):

  grep -R --include=*.php -n "base64_decode" /path/to/wordpress/wp-content/plugins/wp-popup-optin
      

Sprawdzanie kont i ról użytkowników

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Jeśli znajdziesz podejrzane fragmenty skryptów, nie usuwaj ich ślepo na produkcji — najpierw zrób zrzut bazy danych i zachowaj logi do pracy śledczej.

Wzmocnienie i zasady WAF — konkretne środki, które możesz zastosować teraz

Ponieważ exploit polega na nieautoryzowanym przechowywaniu HTML/JS, prawidłowo skonfigurowany WAF może zapewnić szybkie, skuteczne wirtualne łatki, aby zatrzymać eksploatację, aż będziesz mógł załatać lub usunąć wtyczkę.

Zalecane podejścia WAF (ogólne zasady, które działają z większością WAF)

1. Zablokuj żądania POST do punktów końcowych wtyczki
   • Zidentyfikuj punkty końcowe admina lub AJAX wtyczki (np. admin-ajax.php?action=wp_popup_optin_save lub specyficzny URL wtyczki). Zablokuj lub wyzwij (403/429) nieautoryzowane POSTy do tych punktów końcowych.
   • Jeśli nie możesz uzyskać dokładnych nazw akcji, zablokuj POSTy, które odnoszą się do podejrzanych ścieżek wtyczek lub ciągów zapytań.
2. Wymuś sprawdzanie nagłówków w działaniach administratora
   • Wymagaj ważnego nagłówka Referer lub Origin dla POST-ów do punktów końcowych wp-admin. Odrzuć żądania, które nie mają nagłówka Origin lub mają niedopasowany host.
   • Przykładowa logika: Jeśli POST do /wp-admin/admin-ajax.php i Origin/Referer nie pochodzi z twojej domeny → zablokuj.
3. Zablokuj przesyłanie zawierające podejrzany HTML
   • Zablokuj żądania, w których parametry zawierają powszechne wektory XSS: <script, onload=, onerror=, javascript:, <iframe, eval(, document.cookie.
   • Przykładowy wzór: jeśli treść POST-a pasuje do regex (?i)<script|onerror=|onload=|javascript:|<iframe to zablokuj.
4. Ogranicz liczbę powtarzających się prób
   • Zastosuj ograniczenie: ogranicz POST-y do punktów końcowych wtyczek na IP do 5/minutę lub podobnie.
5. Zablokuj żądania z podejrzanym typem zawartości lub brakującymi oczekiwanymi nagłówkami
   • Jeśli wtyczka oczekuje application/x-www-form-urlencoded lub multipart/form-data, ale nie JSON, zablokuj POST-y JSON do punktów końcowych.
6. Wirtualne łatanie (jeśli korzystasz z usługi zapory aplikacyjnej)
   • Dodaj konkretne zasady oparte na sygnaturach, które wykrywają punkty końcowe wtyczki w połączeniu z złośliwymi wzorcami ładunków (tagi skryptów, obsługiwacze zdarzeń). Wdróż zasadę na zarządzanych stronach.

Przykładowa zasada w stylu ModSecurity (dostosuj do składni swojego WAF)

To jest ilustracyjny wzór — dostosuj do swojego środowiska:

SecRule REQUEST_URI "@rx /wp-content/plugins/wp-popup-optin|wp-popup-optin" \"

Uwaga: jeśli korzystasz z zarządzanego WAF, takiego jak nasz, możemy centralnie wdrożyć te środki zaradcze (patrz późniejsza sekcja).

Przykładowe poprawki i zalecane zmiany w kodzie (dla programistów)

Jeśli masz zasoby deweloperskie i chcesz zastosować tymczasową poprawkę w kodzie wtyczki przed dostępnością łatki z góry, oto pragmatyczne zmiany:

1. Zweryfikuj uprawnienia i nonce w obsługiwaczach formularzy (PHP)

 // Przykład: na początku obsługiwacza zapisu

2. Sanitizacja: sanitizuj dane wejściowe przed zapisaniem

• Jeśli pole nie powinno zawierać HTML w ogóle:

  $clean_title = sanitize_text_field( wp_unslash( $_POST['popup_title'] ) );

• Jeśli dozwolony jest ograniczony HTML (np. linki i formatowanie):

  $allowed = wp_kses_allowed_html( 'post' );

3. Ucieczka wyjścia: podczas renderowania popupów, escape w zależności od kontekstu

• Dla atrybutów: echo esc_attr( $popup_title );
• Dla ciała HTML, gdzie dozwolony jest ograniczony HTML: echo wp_kses_post( $popup_content );

4. Unikaj wyświetlania nieufnych danych wejściowych w kontekście JS

Podczas osadzania treści wtyczki w skryptach inline, upewnij się, że zakodujesz w formacie JSON:

echo '';

Jeśli nie czujesz się komfortowo edytując pliki wtyczki, nie próbuj “naprawiać” na produkcji bez testowania w środowisku stagingowym. Edycje kodu mogą zepsuć funkcjonalność.

Reakcja na incydent: co zrobić, jeśli odkryjesz kompromitację

1. Wyłącz stronę lub włącz tryb konserwacji
   • Zapobiegaj dalszym logowaniom administratorów lub odwiedzającym napotykającym ładunek podczas badania.
2. Zrób zrzut ekranu środowiska
   • Utwórz kopie zapasowe plików i pełnej bazy danych — zachowaj znaczniki czasowe i logi.
3. Zachowaj dzienniki i dowody
   • Eksportuj logi dostępu do serwera WWW, logi PHP‑FPM i zrzuty bazy danych.
4. Zidentyfikuj zakres kompromitacji
   • Szukaj nowych użytkowników administratorów, zmodyfikowanych plików rdzenia/wtyczek/motywów, nieznanych zaplanowanych zadań (wp_cron) oraz podejrzanych plików w wp-content/uploads.
5. Usuń złośliwy kod i tylne drzwi
   • Ręczne czyszczenie powinno być ostrożne — najlepiej skorzystać z zespołu ds. bezpieczeństwa kryminalistycznego lub doświadczonego administratora.
6. Rotuj sekrety i poświadczenia
   • Zresetuj hasła administratora, klucze API, hasła do bazy danych i unieważnij sesje.
   • Cofnij wszelkie skompromitowane tokeny lub klucze osadzone na stronie lub w usługach zewnętrznych.
7. Odbuduj z zaufanych źródeł, gdzie to możliwe.
   • Jeśli pliki rdzenia/wtyczek/motywów zostały zmodyfikowane, zastąp je świeżymi kopiami z oficjalnych repozytoriów po weryfikacji.
8. Ponownie włącz zabezpieczenia i monitoruj
   • Po czyszczeniu ponownie włącz zasady WAF, skanowanie i monitoruj pod kątem reinfekcji.

Praktyczne zapytania dochodzeniowe SQL i systemu plików (do skopiowania)

-- Znajdź posty z potencjalnym XSS:

Jak WP‑Firewall pomaga (zarządzane łagodzenie i darmowy plan)

Rozumiemy, że nie każdy właściciel strony może natychmiast załatać lub wyłączyć wtyczki. WP‑Firewall zapewnia warstwowe zabezpieczenia zaprojektowane do natychmiastowej łagodzenia i długoterminowego bezpieczeństwa:

• Zarządzane wirtualne łatanie: Możemy wdrożyć zasady WAF, które blokują dokładne wzorce exploitów opisane powyżej, zatrzymując próby nadużycia punktów końcowych wtyczki i wektorów ładunków w czasie rzeczywistym.
• Skanowanie i usuwanie złośliwego oprogramowania: Wykrywa przechowywane elementy XSS i podejrzane pliki, z opcjonalnym automatycznym usuwaniem w płatnych planach.
• Monitorowanie aktywności i integralności plików: Powiadamia o nowych kontach administratorów, zmienionych plikach i modyfikacji wrażliwych danych.
• Wskazówki dotyczące wzmocnienia strony i wsparcie incydentowe: Eksperckie kroki naprawcze i wskazówki proceduralne w celu zmniejszenia wpływu i przyspieszenia odzyskiwania.

Wypróbuj WP‑Firewall za darmo — natychmiastowe zabezpieczenia, które możesz włączyć teraz.

Chroń swoją stronę od razu — nasz darmowy plan zapewnia podstawowe zabezpieczenia, aby zmniejszyć prawdopodobieństwo wykorzystania, podczas gdy łatasz lub usuwasz podatne wtyczki. Darmowy plan obejmuje zarządzany zaporę z sygnaturami WAF, nielimitowaną przepustowość, okresowe skanowanie złośliwego oprogramowania i łagodzenia ryzyk OWASP Top 10. Jeśli chcesz to wypróbować teraz, zarejestruj się tutaj:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Dlaczego to jest teraz przydatne:

• Szybko wdroż zasady WAF bez modyfikowania kodu wtyczki.
• Uruchom skanowanie złośliwego oprogramowania, aby znaleźć wszelkie przechowywane skrypty.
• Uzyskaj wskazówki od naszego zespołu dotyczące następnych kroków i wzmocnienia zabezpieczeń

(Zobacz ceny i funkcje pod podanym powyżej adresem URL.)

Wskazówki dla deweloperów: jak projektować wtyczki, aby uniknąć tej klasy luk w zabezpieczeniach

Autorzy wtyczek i deweloperzy powinni przyjąć te praktyki, aby zapobiec łańcuchom CSRF → przechowywanym XSS:

1. Zawsze używaj sprawdzeń uprawnień i nonce
   • Używaj current_user_can do sprawdzania uprawnień.
   • Używaj check_admin_referer lub wp_verify_nonce do weryfikacji zamiaru.
2. Waliduj i oczyszczaj dane wejściowe na wejściu, a nie tylko na wyjściu
   • Nigdy nie zakładaj, że dane wejściowe będą nieszkodliwe. Zdecyduj, co jest dozwolone i waliduj zgodnie z tą polityką.
3. Używaj escapingu na wyjściu w odpowiednim kontekście
   • Używaj esc_html dla kontekstów tekstów HTML, esc_attr dla atrybutów, esc_js dla skryptów JS i wp_kses dla bezpiecznego HTML.
4. Używaj przygotowanych zapytań lub wbudowanych funkcji WP do zapisu w DB
   • Unikaj ręcznego tworzenia ciągów SQL z nieufnych danych.
5. Minimalizuj miejsca, w których HTML wprowadzony przez administratora jest renderowany bez escapingu
   • Preferuj kontrolowane budownicze HTML zamiast surowej treści.
6. Uwzględnij testy bezpieczeństwa w CI
   • Zautomatyzuj skanowanie pod kątem niebezpiecznych wzorców i uwzględnij testy jednostkowe, które weryfikują nonce i sprawdzenia uprawnień.

Komunikacja dla właścicieli stron do ich zespołów

Jeśli zarządzasz stronami dla klientów lub swojej organizacji, komunikuj się jasno:

• Które strony są dotknięte i numery wersji
• Podjęte działania (wtyczka dezaktywowana, zastosowana zasada WAF)
• Następne kroki i oczekiwany czas przestoju
• Zachęć do zmiany haseł administratorów i egzekwowania MFA

Ostateczna lista kontrolna — krok po kroku

1. Zidentyfikuj dotknięte instalacje (wtyczka obecna i wersja ≤ 1.4).
2. Natychmiast dezaktywuj wtyczkę lub zastosuj zasady WAF.
3. Uruchom skanowanie bazy danych i systemu plików w poszukiwaniu zapisanych skryptów i tylni drzwi.
4. Sprawdź konta administratorów; zmień dane uwierzytelniające i włącz MFA.
5. Zachowaj logi i dowody, jeśli podejrzewasz kompromitację.
6. Zastąp skompromitowane pliki rdzenia/wtyczki/motywu z zaufanych źródeł.
7. Włącz ponownie wtyczkę tylko po weryfikacji poprawki dostawcy lub zastosowaniu i przetestowaniu lokalnej poprawki.
8. Zastosuj wzmocnienia: CSP, minimalne uprawnienia, WAF, monitorowanie, kopie zapasowe.

Dodatek — szybkie polecenia i skrypty referencyjne

• Dezaktywuj wtyczkę za pomocą WP‑CLI:
  wp plugin deactivate wp-popup-optin --allow-root
• Przeszukaj DB pod kątem tagów skryptów (MySQL):
  mysql -u root -p -D wordpress -e "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';"
• Znajdź podejrzane użycie PHP eval:
  grep -RIn --exclude-dir=wp-admin --exclude-dir=wp-includes "eval(" /var/www/html/wp-content
• Przykład WP‑CLI do wylistowania administratorów:
  wp user list --role=administrator --fields=ID,user_login,user_email

Zakończenie — bądź proaktywny i pragmatyczny

Ta luka przypomina, że wtyczki, które akceptują i przechowują HTML, stanowią trwały wektor ryzyka, gdy brakuje im podstawowych praktyk bezpieczeństwa WordPress (nonces, kontrole uprawnień, sanitizacja). Najszybszym sposobem na zmniejszenie narażenia jest zablokowanie eksploatacji za pomocą dobrze skonstruowanej reguły WAF, a następnie przeprowadzenie dokładnej inspekcji swojej witryny.

Jeśli potrzebujesz pomocy, inżynierowie bezpieczeństwa WP‑Firewall mogą Ci pomóc:

• Zidentyfikować podatne witryny w Twojej flocie,
• Wdrożyć wirtualne poprawki, które blokują próby eksploatacji,
• Skanować w poszukiwaniu przechowywanych artefaktów XSS i usunąć złośliwe wpisy,
• Poprowadzić Cię przez proces odzyskiwania i najlepsze praktyki, aby zapobiec powtórzeniu się.

Bądź bezpieczny, bądź pragmatyczny: wdroż krótkoterminowe łatanie, zweryfikuj i załatij, a następnie wzmocnij systemy, aby zmniejszyć wpływ następnego incydentu.

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

Zasoby i dalsza lektura

• ID CVE: CVE‑2026‑4131 (data ujawnienia: 22 kwietnia 2026)
• Zalecane funkcje WordPress do sanitizacji i ucieczki: sanitize_text_field, wp_kses_post, esc_html, esc_attr, wp_verify_nonce
• Komendy SQL i systemu plików zawarte w tym komunikacie (przejrzyj i dostosuj do swojego środowiska)