| Nazwa wtyczki | WpBookingly |
|---|---|
| Rodzaj podatności | Problemy z naruszeniem kontroli dostępu |
| Numer CVE | CVE-2026-27405 |
| Pilność | Niski |
| Data publikacji CVE | 2026-05-20 |
| Adres URL źródła | CVE-2026-27405 |
Naruszenie kontroli dostępu w WpBookingly (<=1.2.9) — Co właściciele stron WordPress powinni wiedzieć i zrobić teraz
Zespół bezpieczeństwa WP‑Firewall — 20 maja 2026
Niedawno ujawniona luka (CVE‑2026‑27405) dotyczy wtyczki WordPress WpBookingly (Service Booking Manager) w wersjach <= 1.2.9. Klasyfikowana jest jako problem z naruszeniem kontroli dostępu (OWASP A1) z wynikiem CVSS 6.5. Luka pozwala uwierzytelnionemu użytkownikowi z uprawnieniami na poziomie Autora na wywołanie funkcji o wyższych uprawnieniach, ponieważ brakuje odpowiednich kontroli autoryzacji lub nonce. Dostawca wtyczki wydał poprawioną wersję (1.3.0). Ten post wyjaśnia ryzyko, scenariusze rzeczywistego wykorzystania, opcje wykrywania i łagodzenia (w tym jak zapora aplikacji webowej może zmniejszyć ryzyko) oraz praktyczne kroki naprawcze i reagowania na incydenty, które powinieneś podjąć już dziś.
Uwaga: to ostrzeżenie jest napisane z perspektywy zespołu bezpieczeństwa WordPress i ma na celu prowadzenie właścicieli stron, hostów i deweloperów przez bezpieczne, praktyczne działania.
Streszczenie
- Dotknięta wtyczka: WpBookingly (Service Booking Manager)
- Wersje podatne: <= 1.2.9
- Poprawiona wersja: 1.3.0
- CVE: CVE‑2026‑27405
- Klasa wrażliwości: Złamana kontrola dostępu (OWASP A1)
- CVSS: 6.5
- Wymagane uprawnienia do wykorzystania: Autor (uwierzytelniony użytkownik)
- Wpływ: umiarkowany — atakujący z dostępem Autora mogą być w stanie wykonywać działania, do których nie powinni mieć dostępu, takie jak tworzenie, modyfikowanie lub usuwanie rezerwacji, lub wywoływanie funkcji administracyjnych udostępnionych przez wtyczkę.
- Natychmiastowe działanie: zaktualizuj do 1.3.0 lub nowszej. Jeśli nie możesz zaktualizować natychmiast, zastosuj opisane poniżej środki łagodzące.
Czym jest “Naruszenie kontroli dostępu” i dlaczego ma znaczenie
Naruszenie kontroli dostępu występuje, gdy kod nieprawidłowo egzekwuje, kto ma prawo wykonać dane działanie. W wtyczkach WordPress często objawia się to jako:
- Brak kontroli możliwości (np. nieużywanie current_user_can())
- Brak lub niewłaściwie wdrożone kontrole nonce
- Punkty końcowe (admin‑ajax lub admin‑post) lub trasy REST udostępnione rolom, którym nie powinno być to dozwolone
- Niejasna lub zbyt liberalna logika, która zakłada, że uwierzytelnienie równa się autoryzacji
Konsekwencja: uwierzytelnieni użytkownicy z niższymi uprawnieniami mogą wywoływać funkcje przeznaczone dla administratorów lub menedżerów wtyczek, co prowadzi do manipulacji danymi, zmian konfiguracji, a nawet trwałego kompromitowania strony, jeśli połączone z innymi lukami.
W przypadku WpBookingly luka pozwala użytkownikowi na poziomie Autora na wywołanie uprzywilejowanych działań, ponieważ wtyczka pominęła niezbędne kontrole autoryzacji dla niektórych działań i żądań.
Jak atakujący może wykorzystać tę lukę (na wysokim poziomie)
Ta luka nie jest zdalnym, nieautoryzowanym RCE — wymaga, aby atakujący już miał konto Autora na stronie WordPress. To obniża próg w niektórych środowiskach, ponieważ:
- Wiele stron pozwala na rejestrację użytkowników, która domyślnie przyznaje dostęp Autora/Współautora, lub
- Atakujący może kupić lub ukraść konto autora, lub
- Osoba z wewnątrz może nadużyć swojego dostępu jako autor
Gdy atakujący uzyska dostęp jako autor, może:
- Wysyłać specjalnie przygotowane żądania (POST/GET) do punktów końcowych wtyczki (np. admin‑ajax.php lub admin‑post.php), które wtyczka udostępnia bez wystarczających kontroli uprawnień/nonce.
- Wywoływać akcje, które nie są przeznaczone dla autorów: tworzyć rezerwacje, modyfikować ustawienia, wstrzykiwać treści lub wywoływać przepływy pracy wtyczki, które współdziałają z innymi komponentami.
- Połączyć naruszenie kontroli dostępu z inną wadą (np. niewystarczająca walidacja danych wejściowych), aby zwiększyć wpływ — na przykład wymusić wpisy w bazie danych lub tworzyć obiekty, które prowadzą do dalszego wykonania kodu.
Chociaż podatność jest oznaczona jako “niska/średnia” priorytetowo, w przypadku masowego wykorzystania lub ataków wieloetapowych może umożliwić atakującym wykonywanie zakłócających działań na wielu stronach.
Kto powinien się tym przejmować
- Właściciele stron korzystający z wtyczki WpBookingly (Menadżer Rezerwacji Usług) na dowolnej stronie — szczególnie na stronach społecznościowych, w katalogach lub blogach wieloautorskich.
- Strony, które pozwalają na rejestrację użytkowników, gdzie nowi użytkownicy uzyskują role autora/współautora.
- Dostawcy hostingu, którzy zarządzają stronami WordPress w imieniu klientów.
- Agencje i deweloperzy, którzy instalują lub dostosowują WpBookingly.
Jeśli hostujesz stronę, która korzysta z tej wtyczki, zaplanuj natychmiastową aktualizację lub zastosowanie poniższych środków zaradczych.
Natychmiastowe działania (krok po kroku)
Te kroki są priorytetowe pod względem szybkości i bezpieczeństwa. Zacznij od góry i kontynuuj w dół listy.
- Inwentaryzacja i weryfikacja
– Zidentyfikuj wszystkie strony WordPress, które używają WpBookingly. Sprawdź wersje wtyczek.
– Jeśli używasz centralnego narzędzia do zarządzania, uruchom zapytanie o nazwę wtyczki lub sprawdź swoją inwentaryzację wtyczek. - Aktualizacja wtyczki
– Natychmiast zaktualizuj WpBookingly do wersji 1.3.0 lub nowszej na wszystkich stronach produkcyjnych. Dostawca potwierdził poprawkę w 1.3.0.
– Przetestuj aktualizację w środowisku testowym przed zastosowaniem na złożonych stronach z dostosowaniami. - Jeśli nie możesz zaktualizować od razu, tymczasowo zmniejsz ryzyko:
– Wyłącz wtyczkę (preferowane), aż będziesz mógł zaktualizować.
– Jeśli wyłączenie powoduje przerwanie krytycznej funkcjonalności i nie jest możliwe, zastosuj poniższe środki zaradcze. - Przejrzyj role użytkowników
– Audytuj użytkowników z uprawnieniami Autora lub wyższymi. Usuń lub obniż poziom wszelkich kont, które są nieużywane, podejrzane lub niepotrzebne.
– Wymuszaj silne hasła i włącz dwuskładnikowe uwierzytelnianie dla kont z uprawnieniami. - Monitoruj logi pod kątem podejrzanego zachowania
– Szukaj nieoczekiwanych żądań POST/GET do punktów końcowych admin ajax, nietypowego tworzenia/modyfikacji rezerwacji oraz zmian w ustawieniach wtyczek. - Powiadom interesariuszy.
– Jeśli Twoja strona jest zarządzana dla klienta, poinformuj go i udokumentuj podjęte działania.
Zalecane tymczasowe środki zaradcze (jeśli nie możesz zaktualizować od razu)
Jeśli aktualizacja nie jest możliwa od razu, zastosuj jeden lub więcej z tych środków zaradczych, aby zmniejszyć narażenie:
- Ogranicz dostęp do punktów końcowych wtyczki
– Zablokuj bezpośredni dostęp do plików PHP wtyczek lub punktów końcowych AJAX, które powinny być używane tylko przez administratorów. Przykładowe metody:
– Użyj .htaccess lub konfiguracji serwera WWW, aby odmówić dostępu do ścieżek pod /wp-content/plugins/wpbookingly/ dla użytkowników niebędących administratorami.
– Skonfiguruj stronę, aby zwracała 403 dla określonych akcji admin-ajax od użytkowników nieautoryzowanych lub niebędących administratorami (uważaj, aby nie przerwać legalnej funkcjonalności). - Zastosuj wzmocnienie ról
– Tymczasowo usuń możliwości roli Autora, których nie potrzebujesz (np. wyłącz przesyłanie plików dla Autorów lub ogranicz niestandardowe możliwości używane przez wtyczkę).
– Tymczasowo zawieś rejestracje użytkowników, jeśli Twoja strona pozwala na otwarte rejestracje. - Użyj WAF/wirtualnego łatania
– Jeśli obsługujesz zaporę aplikacji internetowej (WAF) lub masz zarządzaną usługę zapory, dodaj zasady blokujące podejrzane działania lub wymagające obecności ważnych nonce'ów/możliwości dla punktów końcowych wtyczki. Na przykład: zablokuj żądania POST do admin-ajax.php, gdzie action=wpbookingly_*, chyba że żądanie pochodzi z adresów IP administratorów lub zawiera ważny nagłówek nonce (dopasowanie wzorca).
– Ogranicz dostęp do punktów wejścia dla administratorów, aby spowolnić zautomatyzowane ataki. - Wyłącz funkcje wtyczki
– Niektóre wtyczki oferują ustawienia do przełączania funkcjonalności; jeśli WpBookingly ma opcję wyłączenia publicznych punktów końcowych rezerwacji lub funkcji AJAX, wyłącz je podczas łatania. - Minimalizuj uprawnienia
– Jeśli autorzy nie muszą publikować od razu, tymczasowo zmień ich rolę na Współpracownika (nie mogą publikować).
To są środki doraźne — aktualizacja do poprawionej wersji wtyczki pozostaje jedynym kompletnym rozwiązaniem.
Wykrywanie: Na co zwracać uwagę w logach i bazie danych
Po ujawnieniu powinieneś przeskanować logi i bazę danych w poszukiwaniu wskaźników nadużyć:
- Logi serwera WWW
– Żądania POST do /wp-admin/admin‑ajax.php lub /wp‑admin/admin‑post.php z podejrzanymi wartościami parametru zapytania action odnoszącymi się do wtyczki.
– Niespodziewani refererzy lub User‑Agenty związane z narzędziami automatycznymi.
– Wysoka częstotliwość podobnych żądań z tych samych adresów IP. - Logi WordPressa / Logi audytowe
– Nowe rezerwacje utworzone z dziwnymi metadanymi.
– Zmiany w ustawieniach związanych z wtyczką pochodzące z kont autorów.
– Tworzenie nowych użytkowników administratora lub zmiany w uprawnieniach użytkowników. - Baza danych
– Nowe lub zmodyfikowane wiersze w tabelach wtyczki (tabela rezerwacji, tabela ustawień) pokazujące dziwne znaczniki czasu, powtarzające się wpisy lub źle sformatowane ładunki.
– Szukaj wstrzykniętego HTML/JS w notatkach rezerwacji lub polach. - System plików
– Niespodziewane nowe pliki w wp‑content (rzadkie dla tej podatności, ale zawsze sprawdzaj).
– Zmiany w plikach wtyczki zmodyfikowane poza oczekiwanymi oknami aktualizacji.
Jeśli znajdziesz podejrzaną aktywność, postępuj zgodnie z wytycznymi dotyczącymi reakcji na incydenty w tym poście.
Podręcznik reakcji na incydenty
Jeśli uważasz, że strona została wykorzystana, wykonaj te kroki:
- Izoluj i zachowaj
– Włącz tryb konserwacji lub tymczasowo odłącz stronę od internetu, jeśli to możliwe.
– Wykonaj pełne kopie zapasowe (pliki + DB) do analizy kryminalistycznej przed wprowadzeniem zmian. - Triage
– Zidentyfikuj zakres: które konta, jakie dane i jaka funkcjonalność zostały dotknięte.
– Sprawdź logi, aby określić harmonogram i działania napastnika. - Oczyść i napraw
– Zaktualizuj podatną wtyczkę do wersji 1.3.0 (i wszelkie inne przestarzałe oprogramowanie).
– Usuń wszelkie złośliwe pliki lub tylne drzwi. Jeśli nie jesteś pewien, przywróć z czystej kopii zapasowej sprzed kompromitacji.
– Przejrzyj i cofnij nieautoryzowane zmiany w konfiguracji.
– Zmień wszystkie hasła administracyjne i hostingowe oraz unieważnij wszystkie aktywne sesje (WordPress ma wtyczki do zarządzania sesjami; rozważ wymuszenie resetowania haseł). - Ucz się i wzmacniaj
– Audytuj użytkowników i usuń niepotrzebne uprawnienia.
– Wprowadź uwierzytelnianie dwuskładnikowe.
– Zabezpiecz uprawnienia do plików i katalogów oraz wyłącz edytory wtyczek/tematów w wp‑config.
– Wdróż lub dostosuj zasady WAF, aby wykrywać i blokować wykorzystane zachowanie. - Powiadom i zgłoś
– Jeśli wrażliwe dane użytkowników zostały ujawnione, stosuj się do zasad powiadamiania prawnego i regulacyjnego w swojej jurysdykcji.
– Poinformuj dotkniętych klientów lub użytkowników o dokładnych zaleceniach. - Monitorowanie po incydencie
– Monitoruj oznaki reinfekcji przez co najmniej 30 dni: powtarzające się POST-y, nieznane zaplanowane zadania (cron) lub nowych użytkowników administracyjnych.
Jeśli nie czujesz się pewnie wykonując te kroki, skontaktuj się z wykwalifikowanym specjalistą ds. bezpieczeństwa WordPress lub swoim hostem.
Wskazówki dla deweloperów: jak naprawić i unikać tej luki w swoich wtyczkach
Jeśli jesteś deweloperem wtyczek lub integratorem strony, który dostosowuje WpBookingly, stosuj się do tych najlepszych praktyk, aby zapobiec złamaniu kontroli dostępu:
- Użyj odpowiednich kontroli uprawnień
– Używaj interfejsów API możliwości WordPress: current_user_can(‘manage_options’) lub odpowiednia możliwość dla danej akcji.
– Nie zakładaj, że uwierzytelnienie implikuje autoryzację. - Wprowadź kontrole nonce
– Dla przesyłania formularzy i akcji AJAX używaj check_admin_referer() lub wp_verify_nonce() (punkty końcowe REST powinny zawierać permission_callback, który weryfikuje możliwości).
– Nonce nie są podstawową kontrolą bezpieczeństwa, ale zapewniają przydatną ochronę przed CSRF i autentyczność żądań. - Zabezpiecz trasy REST.
– Podczas rejestrowania tras REST (register_rest_route) zawsze podawaj permission_callback, który zwraca true tylko wtedy, gdy current_user_can(…) jest spełnione dla danej akcji. - Sprawdź i zdezynfekuj dane wejściowe
– Używaj sanitize_text_field(), esc_attr(), intval() itp. oraz przygotowuj zapytania SQL za pomocą $wpdb->prepare() lub używaj WP_Query w sposób bezpieczny. - Zasada najmniejszych uprawnień
– Przypisz minimalne uprawnienia. Unikaj przyznawania uprawnień administratora operacjom wtyczek, które ich nie potrzebują, i odwrotnie. - Rejestruj wrażliwe działania
– Audytuj logi dla wrażliwych operacji (zmiany w rezerwacjach, ustawieniach lub rolach użytkowników). To pomaga w wykrywaniu i dochodzeniach kryminalnych. - Testuj kontrolę dostępu
– Dodaj automatyczne testy, które próbują tych samych działań co role o niższych uprawnieniach, aby zweryfikować egzekwowanie uprawnień.
Jeśli utrzymujesz forkowane lub dostosowane wersje WpBookingly, upewnij się, że zintegrowałeś poprawkę dostawcy lub wdrożyłeś powyższe poprawki.
Jak zapora WordPress (WAF) może pomóc — i czego nie może zastąpić
Prawidłowo skonfigurowana WAF to cenny poziom, który zmniejsza narażenie na luki, takie jak złamana kontrola dostępu. Oto jak pomaga i jakie ma ograniczenia:
Co WAF może zrobić:
- Blokuj lub ograniczaj liczbę złośliwych lub podejrzanych żądań HTTP kierowanych do punktów końcowych wtyczek (np. nienormalna aktywność admin-ajax).
- Zastosuj wirtualne poprawki (bloki oparte na regułach), które zapobiegają znanym wzorcom exploitów podczas aktualizacji.
- Wykrywaj anormalne wzorce żądań z kompromitowanych kont użytkowników lub botów.
- Zapobiegaj masowym próbom eksploatacji na dużą skalę, blokując wspólne wskaźniki (User-Agent, cechy ładunku, powtarzające się działania).
Czego WAF nie może zrobić:
- Napraw podstawową lukę w kodzie wtyczki — jedynym prawdziwym rozwiązaniem jest zastosowanie poprawki dostawcy.
- Zastąp odpowiednie kontrole autoryzacji w kodzie. Wtyczka musi nadal egzekwować uprawnienia/nonces.
- Niech będzie substytutem dla bezpiecznego rozwoju, terminowych aktualizacji i zarządzania kontami o minimalnych uprawnieniach.
Podczas zarządzania witrynami produkcyjnymi stosuj podejście warstwowe: utrzymuj oprogramowanie w aktualności, egzekwuj silne kontrole użytkowników i używaj WAF jako ochrony i monitorowania pośredniego.
Praktyczne sugestie dotyczące konfiguracji WAF/serwera
Poniżej znajdują się bezpieczne, ogólne sugestie dotyczące konfiguracji, które możesz wdrożyć na swoim WAF lub serwerze WWW podczas stosowania poprawek. Bądź ostrożny przy stosowaniu reguł, aby nie złamać funkcji witryny — zawsze testuj w środowisku staging.
- Blokuj podejrzane wzorce admin-ajax
– Odrzuć żądania POST do admin-ajax.php, gdzie akcja odpowiada znanym nazwom akcji wtyczek, chyba że żądanie pochodzi z dozwolonego zakresu IP lub zawiera oczekiwane nagłówki (uwaga: tylko jako środek tymczasowy i po przetestowaniu). - Ogranicz liczbę żądań do punktów końcowych administratora
– Ograniczaj żądania do /wp‑admin/, /wp‑login.php i admin‑ajax.php z jednego adresu IP, aby zapobiec automatycznemu nadużywaniu. - Wymuszaj wzorce referrer/nonce
– Jeśli wtyczka używa standardowego parametru nonce (np. _wpnonce), blokuj żądania, które próbują wywołać akcje administracyjne bez parametru _wpnonce dla wrażliwych działań. - Zablokuj dostęp do plików wtyczki
– Użyj reguł serwera WWW, aby zwracać 403 dla prób bezpośredniego dostępu do plików PHP w katalogu wtyczki z front‑endu. - Monitorowanie i ostrzeganie
– Skonfiguruj powiadomienia o nagłych wzrostach w POSTach admin‑ajax, powtarzających się próbach przesyłania z tego samego adresu IP lub żądaniach z znanymi złośliwymi ładunkami.
Jeśli prowadzisz zarządzane środowisko hostingowe, skoordynuj z hostem wdrożenie tymczasowych reguł WAF na stronach klientów.
Bezpieczne sposoby na sprawdzenie, czy byłeś celem
Nie próbuj wykorzystać luki w swojej witrynie. Zamiast tego wykonaj bezpieczne kontrole:
- Sprawdzenie wersji wtyczki
– Potwierdź zainstalowaną wersję wtyczki w ekranie WP admin > Wtyczki lub przez sprawdzenie wp‑content/plugins/wpbookingly/wpbookingly.php (wersja nagłówka). - Przeszukaj logi (tylko do odczytu)
– Szukaj żądań opisanych w sekcji wykrywania.
– Eksportuj i analizuj logi pod kątem podejrzanej aktywności. - Audyt aktywności użytkowników
– Sprawdź, kto wykonał działania administracyjne i czy konto Autora złożyło żądania, których normalnie nie powinno. - Użyj narzędzi skanera bezpieczeństwa (tylko do odczytu)
– Uruchom renomowane skanery złośliwego oprogramowania i wtyczek (tylko do odczytu), aby wykryć podejrzane zachowanie lub wskaźniki kompromitacji.
Jeśli znajdziesz oznaki wykorzystania, postępuj zgodnie z krokami reakcji na incydent opisany wcześniej w tym poście.
Lista kontrolna wzmacniania (szybkie odniesienie)
- Zaktualizuj WpBookingly do wersji 1.3.0 lub nowszej.
- Audytuj użytkowników z uprawnieniami Autora lub wyższymi.
- Wyłącz lub ogranicz otwartą rejestrację użytkowników.
- Włącz uwierzytelnianie dwuskładnikowe dla uprzywilejowanych kont.
- Przejrzyj wtyczki i usuń nieużywane.
- Wdróż i dostosuj zasady WAF, aby zablokować podejrzane użycie punktów końcowych administratora.
- Wykonaj kopię zapasową plików witryny + DB przed aktualizacjami.
- Przejrzyj logi pod kątem podejrzanej aktywności admin‑ajax lub admin‑post.
- Zmień hasła administratora i hostingu, jeśli podejrzewasz wykorzystanie.
- Wyłącz edytor plików w wp-config.php (
define('DISALLOW_FILE_EDIT', true);).
Jeśli jesteś hostem lub agencją: zalecaj te kroki operacyjne
- Zarządzanie łatkami: Utrzymuj rytm łatania dla wtyczek/tematów i priorytetuj aktualizacje zabezpieczeń z procesem testowania i szybkiego wdrażania.
- Powiadomienia o lukach: Subskrybuj wiarygodne źródła ujawniania zabezpieczeń i niezwłocznie informuj klientów, gdy pojawią się problemy o dużym wpływie.
- Oferuj zarządzane usługi łatania lub wirtualnego łatania, aby klienci, którzy nie mogą szybko aktualizować, mogli być chronieni.
- Zapewnij pomoc w odpowiedzi na incydenty lub jasne ścieżki eskalacji dla klientów.
Ostateczne uwagi: perspektywa ryzyka i priorytetyzacja
Ta luka jest ważna, ponieważ pozwala na nadużycie funkcjonalności przez uwierzytelnionych użytkowników z uprawnieniami autora — rola powszechnie obecna na wielu stronach WordPress. Chociaż nie jest to natychmiastowe zdalne RCE o niskiej złożoności, luki w kontroli dostępu są często wykorzystywane jako punkt obrotu w większych łańcuchach ataków. Priorytetuj łatanie i stosuj opisane w tym poście warstwowe środki zaradcze.
Jeśli Twoja witryna korzysta z wtyczki WpBookingly, uczynienie aktualizacji do wersji 1.3.0 (lub nowszej) swoim najwyższym priorytetem. Nawet jeśli nie masz autorów na stronie, przejrzyj możliwości użytkowników i ekspozycję wtyczek.
Chroń swoją witrynę za pomocą WP‑Firewall — zacznij od planu darmowego
Zabezpiecz swoje strony WordPress za pomocą łatwej, zarządzanej warstwy ochrony, podczas gdy wdrażasz poprawki kodu i przeprowadzasz głębsze wzmocnienia.
Wypróbuj plan WP‑Firewall Basic Free — Podstawowa Ochrona dla WordPress
Chroń swoją witrynę teraz za pomocą planu WP‑Firewall Basic (Darmowego). Obejmuje on podstawową zarządzaną ochronę zapory, nielimitowaną przepustowość, zaporę aplikacji internetowych (WAF), zautomatyzowany skaner złośliwego oprogramowania oraz środki zaradcze dla ryzyk OWASP Top 10 — wszystko, czego potrzebujesz, aby zredukować ekspozycję podczas aktualizacji wtyczek i zaostrzania konfiguracji. Jeśli później chcesz dodatkowej automatyzacji, plany Standard i Pro dodają automatyczne usuwanie złośliwego oprogramowania, czarną/białą listę IP, miesięczne raporty bezpieczeństwa i wirtualne łatanie luk. Zarejestruj się i zacznij od razu na: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Dodatek: Bezpieczne fragmenty kodu i przykłady (odniesienie dla deweloperów)
Poniżej znajdują się bezpieczne, ilustracyjne przykłady, jak przeprowadzać kontrole autoryzacji dla wywołań AJAX i REST w WordPress. To przykłady dla deweloperów, aby zapewnić odpowiednie kontrole.
Przykład: zabezpieczony handler AJAX dla administratora (pseudo‑przykład)
add_action( 'wp_ajax_wpbookingly_admin_action', 'wpbookingly_admin_action_handler' );
function wpbookingly_admin_action_handler() {
// Sprawdź nonce dla tej akcji; kończy z -1 w przypadku niepowodzenia;
check_admin_referer( 'wpbookingly_admin_action', '_wpnonce_wpbookingly' );.
Streszczenie
// Sprawdzenie uprawnień: zezwól tylko użytkownikom, którzy mogą zarządzać_opcje lub mają określoną zdolność.
if ( ! current_user_can( 'manage_options' ) ) { https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Bądź bezpieczny i łataj niezwłocznie.
