| Nazwa wtyczki | @budibase/backend-core |
|---|---|
| Rodzaj podatności | Eskalacja uprawnień |
| Numer CVE | CVE-2026-46424 |
| Pilność | Średni |
| Data publikacji CVE | 2026-05-20 |
| Adres URL źródła | CVE-2026-46424 |
Pilne: Eskalacja uprawnień w @budibase/backend-core — Co właściciele stron WordPress powinni wiedzieć i zrobić teraz
Data: 19 maja 2026
Powaga: Średni (CVSS 4.2)
Dotyczy: @budibase/backend-core < 3.38.2 (CVE-2026-46424 / GHSA-6vp2-6r7m-2jvx)
Jeśli zarządzasz stronami WordPress, które integrują się z zewnętrznymi usługami backendowymi, aplikacjami headless lub niestandardowymi mikroserwisami (w tym narzędziami stworzonymi w Node.js lub Budibase), to ostrzeżenie jest dla Ciebie. Niedawno ujawniona luka w rdzeniu backendu Budibase może pozwolić użytkownikom, którym odebrano uprawnienia, na ich utrzymanie przez maksymalnie godzinę, ponieważ pamięć podręczna/stany nie są szybko unieważniane, gdy role są usuwane. Chociaż ta luka nie jest problemem rdzenia WordPress, jej praktyczne skutki mogą bezpośrednio wpłynąć na środowiska oparte na WordPress, które polegają na takich backendach do uwierzytelniania, autoryzacji lub przepływów treści.
Poniżej wyjaśnię lukę w prostych słowach, opiszę rzeczywiste ryzyka dla stron WordPress i środowisk hostingowych oraz przedstawię priorytetowy, praktyczny plan naprawy i łagodzenia, który możesz zastosować natychmiast — w tym konkretne kroki dotyczące zapory aplikacji internetowej (WAF) i operacyjne, aby zredukować narażenie podczas łatania.
TL;DR — Najważniejsze, na co musisz działać teraz
- Co się stało: błąd unieważnienia pamięci podręcznej w backendzie Budibase pozwala użytkownikom, którym odebrano role, na utrzymanie podwyższonych uprawnień przez maksymalnie 60 minut.
- Dlaczego strony WordPress powinny się tym przejmować: wiele stron integruje się z zewnętrznymi backendami (jednolity logowanie, formularze, headless API treści, przepływy automatyzacji). Jeśli te usługi są podatne, atakujący może zachować dostęp do uprzywilejowanych API, które wpływają na treść strony, dane użytkowników lub przepływy publikacji.
- Działania natychmiastowe:
- Zaktualizuj @budibase/backend-core do wersji 3.38.2 lub nowszej wszędzie tam, gdzie jest używane.
- Jeśli nie możesz zaktualizować natychmiast, zastosuj zasady WAF, zablokuj lub ogranicz dostęp do podatnych punktów końcowych, skróć czas życia tokenów i przymusowo unieważnij aktywne sesje, gdzie to możliwe.
- Monitoruj logi pod kątem podejrzanej aktywności na punktach końcowych API i zmian uprawnień.
- Zakładaj, że odebrane konta mogą pozostać funkcjonalne przez maksymalnie godzinę — traktuj je z podwyższoną podejrzliwością i weryfikuj wszystkie ostatnie operacje uprzywilejowane.
Tło: Czym jest luka i jak działa
Na wysokim poziomie problemem jest brak lub opóźniona ścieżka unieważnienia pamięci podręcznej w publicznym API odpowiedzialnym za usuwanie ról. Gdy rola użytkownika jest usuwana (na przykład, degradacja edytora do zwykłego współpracownika lub odebranie flagi administratora), backend aktualizuje autorytatywny stan roli, ale nie unieważnia natychmiast pamięci podręcznej uprawnień używanych przez publiczne API. Ponieważ stan autoryzacji w pamięci podręcznej może być zwracany, użytkownik, któremu odebrano uprawnienia, może nadal otrzymywać odpowiedzi, które wskazują na podwyższone uprawnienia, aż wygaśnie czas życia pamięci podręcznej — zgłoszono, że może to trwać do jednej godziny.
Kluczowe cechy techniczne:
- Wektor: Sieć (zdalnie, przez publiczne API)
- Złożoność: Średnia do wysokiej (zależy od dostępu do konta, które zostało odebrane)
- Wymagane uprawnienie do ataku: Niskie (atak może pochodzić z wcześniej ważnego konta)
- Wpływ: Eskalacja uprawnień — użytkownicy, którym odebrano uprawnienia, mogą nadal uzyskiwać dostęp lub wykonywać uprzywilejowane działania w czasie okna pamięci podręcznej
- Przyczyna: Brak unieważnienia pamięci podręcznej lub synchronicznego usunięcia pamięci podręcznej po zmianach ról
To jest błąd logiczny/spójności stanu, a nie klasyczna iniekcja kodu lub obejście uwierzytelniania, ale konsekwencje są takie same: użytkownik, który powinien mieć ograniczony dostęp, może nadal wykonywać działania o wysokich uprawnieniach.
Scenariusze z życia wzięte wpływające na instalacje WordPress
Chociaż sam WordPress może nie zawierać Budibase, wiele witryn WordPress integruje się z systemami zewnętrznymi w procesach produkcyjnych:
- Architektury headless CMS, w których WordPress jest narzędziem do tworzenia treści, a Budibase (lub inny headless backend) ułatwia automatyzację procesów lub publikację opartą na rolach.
- Jednolity system logowania (SSO) lub scentralizowane uwierzytelnianie, w którym zewnętrzny backend synchronizuje zmiany ról do WordPress lub do systemów bramowych.
- Procesy automatyzacji, które publikują treści z zewnętrznych backendów do WordPress (webhooki, wywołania REST API).
- Pulpity zarządzania witryną lub narzędzia wewnętrzne zbudowane z Budibase połączone z hostami WordPress, które wykonują administrację witryną lub publikację treści przy użyciu uprzywilejowanych kluczy API.
- Narzędzia dewelopera lub administratora do zarządzania witryną (przydzielanie użytkowników, masowe edytowanie ról), które polegają na dotkniętym backendzie.
Wektory ataku i konsekwencje:
- Niezadowolony pracownik lub skompromitowane konto nie-administracyjne, którego uprawnienia zostały później odebrane, mogłoby nadal wykonywać działania administracyjne (publikować posty, edytować treści, tworzyć użytkowników administracyjnych) aż do wygaśnięcia pamięci podręcznej.
- Automatyczne synchronizacje mogłyby przesyłać przestarzały stan uprzywilejowany z powrotem do WordPress, powodując nieprawidłowe eskalacje uprawnień wewnątrz witryny WordPress.
- Złośliwi aktorzy mogliby skryptować interakcje, aby maksymalizować okno uprzywilejowanej aktywności przed pełnym wejściem w życie odebrania uprawnień.
Biorąc pod uwagę te możliwości, administratorzy WordPress powinni traktować to jako wysokie ryzyko operacyjne dla punktów integracyjnych i procesów automatyzacji.
Wykrywanie: na co zwracać uwagę w dziennikach i telemetrii
Jeśli podejrzewasz narażenie lub chcesz działać proaktywnie, priorytetowo traktuj te kontrole:
- Dzienniki dostępu API
- Szukaj żądań z kont użytkowników, którym niedawno zmieniono role (znacznik czasu żądań po zmianie roli).
- Sprawdź punkty końcowe związane z działaniami administracyjnymi (tworzenie użytkowników, przypisywanie ról, publikacja/wycofywanie treści).
- WordPress REST API i dzienniki administracyjne
- Zidentyfikuj uprzywilejowane działania zainicjowane przez użytkowników, których role zostały cofnięte w ciągu ostatniej godziny.
- Sprawdź nietypowe czasy lub adresy IP, operacje masowe lub wzorce skryptowe (np. szybka sekwencja żądań DELETE/POST/PUT na poziomie administratora).
- Logi uwierzytelniania i tokenów
- Czy token wydany przed cofnięciem był akceptowany dla uprzywilejowanych wywołań po tym czasie?
- Sprawdź przepływy tokenów odświeżających: czy tokeny odświeżające były używane niewłaściwie do uzyskania nowych tokenów z przestarzałymi asercjami ról?
- Ślady audytu w systemach zewnętrznych
- W przypadku bezgłowych przepływów pracy sprawdź dziennik audytu zewnętrznego backendu pod kątem usunięcia ról i kolejnych uprzywilejowanych wywołań API.
Jeśli znajdziesz dowody na uprzywilejowane działania użytkowników, których role zostały cofnięte po znaku czasowym cofnięcia, traktuj to jako potwierdzoną eksploatację lub przynajmniej jako incydent operacyjny wymagający natychmiastowej naprawy.
Natychmiastowa naprawa (kolejność priorytetów)
- Zaktualizuj zależność
- Gdziekolwiek używany jest @budibase/backend-core, zaktualizuj do wersji 3.38.2 lub nowszej. To jedyna poprawka, która usuwa przyczynę problemu.
- Jeśli zarządzasz infrastrukturą jako kodem lub obrazami kontenerów, utwórz i wdroż zaktualizowane wersje, a następnie uruchom ponownie dotknięte usługi.
- Wymuś unieważnienie sesji/tokenów
- Cofnij aktywne sesje lub tokeny dla kont, których uprawnienia zostały zmienione.
- Rotuj klucze API używane przez automatyzację lub przepływy integracyjne, jeśli podejrzewasz, że były używane z przestarzałymi uprawnieniami.
- Skróć TTL pamięci podręcznej i okna weryfikacji ról
- Zmniejsz czas życia pamięci podręcznej związanej z stanem autoryzacji do minimalnej praktycznej wartości, aż będziesz mógł zastosować poprawkę.
- Gdzie to możliwe, skonfiguruj zmiany ról, aby wyzwalały natychmiastowe haki czyszczenia pamięci podręcznej.
- Zastosuj zasady WAF i sieciowe
- Użyj swojego WAF, aby tymczasowo zablokować lub ograniczyć dostęp do podatnych publicznych punktów końcowych API lub wymagać dodatkowych kontroli uwierzytelniania.
- Ogranicz szybkość lub dodaj surowszą walidację dla punktów końcowych, które wykonują wrażliwe działania lub zwracają informacje o rolach/uprawnieniach.
- Ręcznie zweryfikuj ostatnie zmiany z uprawnieniami.
- Przejrzyj wszelkie modyfikacje na poziomie administratora, opublikowane treści lub utworzone konta użytkowników w ciągu ostatnich 24–48 godzin, aby zapewnić ich ważność.
- Komunikuj się i eskaluj
- Powiadom wewnętrzne zespoły oraz wszelkich dostawców zewnętrznych, którzy polegają na Twoim wdrożeniu; przyjmij najgorszy możliwy scenariusz dla wszelkich zautomatyzowanych procesów, które przyznają wysokie uprawnienia.
Jeśli nie możesz zaktualizować natychmiast, priorytetowo traktuj kroki dotyczące WAF i unieważnienia sesji, aby zmniejszyć okno narażenia.
Mitigacje skoncentrowane na WAF, które możesz zastosować już teraz.
Jako dostawca zapory i WAF, oto praktyczne pomysły na zasady i mitigacje, które możesz szybko wdrożyć. To ogólne zalecenia — dostosuj je do swojego środowiska i ścieżek API.
- Wirtualne łatanie
- Utwórz regułę, aby przechwytywać żądania do punktów końcowych, które generują asercje ról lub uprawnień, i odrzucaj lub kwestionuj żądania, które wydają się używać przestarzałych tokenów lub wyglądają podejrzanie.
- Zablokuj nieautoryzowane lub niewystarczająco autoryzowane wywołania do punktów końcowych, które zmieniają role lub wykonują działania administracyjne, i wymagaj MFA/2FA lub silniejszej asercji dla takich operacji.
- Zablokuj lub wzmocnij publiczne API.
- Jeśli to możliwe, ogranicz dostęp do publicznego API do znanych wewnętrznych adresów IP lub zakresów IP. Jeśli Twoje przepływy pracy na to pozwalają, umieść API za prywatną siecią lub VPN, aż do naprawy.
- Wprowadź listę dozwolonych działań administracyjnych pochodzących z zaufanych źródeł lub kont serwisowych.
- Ograniczanie szybkości i wykrywanie anomalii
- Zastosuj surowe limity szybkości dla punktów końcowych zarządzania rolami i administracyjnych, aby utrudnić skryptowe wykorzystanie.
- Uruchom alerty przy nietypowych wzrostach wywołań API na poziomie administratora z jednego użytkownika lub adresu IP.
- Rozróżnianie odpowiedzi i maskowanie.
- Unikaj zwracania metadanych ról lub uprawnień w publicznych odpowiedziach, jeśli nie jest to konieczne. Zamaskuj lub usuń szczegółowe informacje o uprawnieniach, które mogą być buforowane przez klientów.
- Wymuszaj introspekcję tokenów.
- Gdzie to możliwe, niech WAF przeprowadza kontrole introspekcji tokenów w stosunku do Twojego dostawcy tożsamości, aby potwierdzić aktualne asercje ról przed zezwoleniem na działania z wysokimi uprawnieniami.
- Logowanie i haki alertów.
- Upewnij się, że logi WAF dla dotkniętych punktów końcowych są kierowane do SIEM i generują alerty o wysokim priorytecie dla wszelkich wywołań przez konta z ostatnimi zmianami uprawnień.
- Reguły denylisty w sytuacjach awaryjnych.
- Jeśli zidentyfikujesz konkretne skompromitowane konta lub podejrzane adresy IP, dodaj je do natychmiastowej listy zablokowanych na poziomie WAF w odpowiednich punktach końcowych.
Te działania WAF zapewniają warstwę obrony, podczas gdy naprawiasz i weryfikujesz poprawkę w backendzie.
Jak napastnicy mogą to wykorzystać — realistyczne przypadki użycia
Zrozumienie motywacji napastników pomaga w ograniczeniu:
- Nadużycie wewnętrzne: Pracownik pozbawiony praw administratora może wprowadzać zmiany przez godzinę — publikując treści, dodając użytkowników lub wykradając dane za pomocą wywołań API.
- Utrzymywanie i zmiana kierunku: Napastnicy mogą wykorzystać tymczasowy podwyższony dostęp do tworzenia użytkowników z tylnymi drzwiami, instalowania złośliwych wtyczek lub dodawania webhooków, które utrzymują się poza oknem pamięci podręcznej.
- Uzbrojenie łańcucha dostaw: Skompromitowane narzędzie automatyzacji trzeciej strony z uprzywilejowanym dostępem do API może być używane do wprowadzania złośliwej treści do wielu witryn WordPress lub środowisk hostingowych.
- Łączenie z innymi lukami: Nawet problemy o niskim ciężarze gdzie indziej mogą być eskalowane, jeśli napastnik już ma przedłużony uprzywilejowany dostęp przez przestarzałe pamięci ról.
Ponieważ okno może trwać do godziny, operatorzy muszą zakładać, że znaczne szkody są możliwe, jeśli zmiany uprawnień są rutynową odpowiedzią na podejrzane zachowanie.
Najlepsze praktyki operacyjne, aby zapobiec tej klasie problemów
Ta podatność zasadniczo dotyczy spójności stanu i granic zaufania. Strategia łagodzenia jest szersza niż pojedyncza poprawka — chodzi o odporność i bezpieczny projekt.
- Zasada najmniejszych uprawnień
- Minimalizuj uprawnienia przyznawane kontom serwisowym, tokenom automatyzacji i kontom administratorów. Używaj tokenów o ograniczonym zakresie z wąskimi możliwościami.
- Natychmiastowe haki unieważnienia sesji
- Gdy role się zmieniają, wyzwól unieważnienie sesji/tokenu we wszystkich magazynach sesji i klientach (unieważnij JWT, zmieniając klucze logowania lub utrzymując listy unieważnień).
- Krótkie TTL tokenów i polityki odświeżania
- Używaj tokenów dostępu o krótkim czasie życia i egzekwuj ścisłe kontrole tokenów odświeżających, zmniejszając okno czasowe dla przestarzałych autoryzacji.
- Synchronous invalidation for critical changes
- W przypadku zmian ról/uprawnień wdrażaj synchronizowane usuwanie pamięci podręcznej lub upewnij się, że zdarzenia zmian są natychmiast przesyłane do wszystkich pamięci podręcznych.
- Izolacja usług
- Utrzymuj wewnętrzne API administracyjne/back-office w sieciach prywatnych i ograniczaj publiczną ekspozycję.
- Testowanie bezpieczeństwa i skanowanie zależności
- Zintegruj analizę składu oprogramowania (SCA) w swoich potokach CI/CD, aby wcześnie wychwycić podatne wersje zależności.
- Przeprowadzaj regularne testy integracyjne, które symulują zmiany ról i weryfikują unieważnienie pamięci podręcznej.
- Scenariusze incydentów i automatyczne usuwanie
- Miej udokumentowany scenariusz dla incydentów związanych z cofnięciem uprawnień, który obejmuje wymuszone unieważnienie sesji, wprowadzanie reguł WAF i szybkie aktualizacje zależności.
Lista kontrolna reakcji na incydenty (krok po kroku)
- Najpierw poprawka: zaktualizuj @budibase/backend-core do 3.38.2+ we wszystkich środowiskach.
- Unieważnij sesje i rotuj klucze: unieważnij aktywne sesje i rotuj klucze API dla dotkniętych usług.
- Wdróż reguły WAF: wdrażaj wirtualne poprawki i blokady dla wrażliwych punktów końcowych.
- Audyt ostatnich działań z uprawnieniami: sporządź listę ostatnich działań administracyjnych przez niedawno cofniętych użytkowników.
- Cofnij nieautoryzowane zmiany: usuń złośliwych użytkowników, przywróć nieautoryzowane treści i przywróć rozsądne wartości konfiguracyjne.
- Wzmocnij dane uwierzytelniające: wymagaj zmiany haseł i rotuj tokeny dla dotkniętych kont.
- Powiadom interesariuszy: wewnętrzne operacje, dotkniętych klientów i wszelkie istotne integracje zewnętrzne.
- Przegląd po incydencie: zbierz dane telemetryczne, określ przyczynę źródłową (poza poprawką upstream) i dostosuj procesy, aby zapewnić szybsze unieważnienie pamięci podręcznej.
Jak zweryfikować, że jesteś chroniony po poprawce
- Potwierdź wersję usługi: zweryfikuj, że wdrożona usługa zgłasza wersję 3.38.2+.
- Przetestuj proces usuwania ról: przeprowadź usunięcie roli w środowisku testowym i natychmiast spróbuj wykonać działania z uprawnieniami z cofniętego konta — żądanie musi zostać odrzucone.
- Zweryfikuj unieważnienie sesji: po unieważnieniu roli upewnij się, że wcześniej wydane tokeny nie pozwalają już na wywołania z uprawnieniami.
- Monitoruj logi: przez okres 24–72 godzin po poprawce, obserwuj anomalne działania z uprawnieniami.
- Testy penetracyjne: przeprowadź skoncentrowany test symulujący cofnięte konto próbujące działań uprzywilejowanych, aby upewnić się, że twój stos end-to-end jest oczyszczony z przestarzałych uprawnień.
Długoterminowe zalecenia dla właścicieli stron WordPress
- Inwentaryzacja integracji: utrzymuj aktualną inwentaryzację usług stron trzecich i frameworków backendowych używanych w twoim stosie. Wiedz, gdzie używane są Budibase lub podobne usługi.
- Wzmocnij automatyzację: każde zautomatyzowane narzędzie do publikacji lub provisioningu powinno używać ściśle określonych kluczy i wewnętrznych sieci.
- Regularnie przeglądaj role i uprawnienia: zaplanuj audyty przypisania uprawnień i cofnij przestarzałe konta.
- Wdrażaj wielowarstwową obronę: łącz praktyki bezpiecznego kodowania z WAF, monitorowaniem i ochroną punktów końcowych.
- Edukuj zespoły: zespoły produktowe i redakcyjne muszą wiedzieć, że cofnięcia mogą nie być natychmiastowe we wszystkich systemach — koordynuj ręczną weryfikację w przypadku podejrzanych zdarzeń.
Przykładowy zestaw reguł WAF (koncepcyjny)
Poniżej znajdują się przykładowe pomysły na reguły, które możesz wdrożyć w swoim WAF. Są koncepcyjne; dostosuj je do swojego środowiska i punktów końcowych.
- Reguła 1 — Zablokuj żądania POST do /api/admin/* z publicznych sieci, z wyjątkiem dozwolonych adresów IP.
- Reguła 2 — Odrzuć żądania do /api/roles/unassign, które nie zawierają ważnych asercji pochodzenia lub nie przestrzegają polityki uwierzytelniania wymagającej świeżej flagi MFA.
- Reguła 3 — Ogranicz liczbę żądań do punktu końcowego admina do 10 żądań/min na użytkownika i uruchom alert przy przekroczeniu progu.
- Reguła 4 — Wymagaj introspekcji tokenów dla /api/publish i /api/user/create i odrzuć, jeśli token został wydany przed ostatnim zdarzeniem zmiany roli dla tego użytkownika.
- Reguła 5 — Kwarantanna żądań, które próbują tworzyć nowych użytkowników admina z adresów IP, które wcześniej nie wykonywały działań admina.
Wdrażaj logowanie dla każdej reguły odrzucającej, aby wspierać dochodzenie.
Często zadawane pytania
Q: Moja strona WordPress nie używa Budibase. Czy muszę się martwić?
A: Jeśli nie masz żadnej integracji z Budibase lub systemami, które polegają na dotkniętym backendzie, bezpośrednie ryzyko jest niskie. Jednak jeśli korzystasz z usług stron trzecich, automatyzacji lub narzędzi SaaS, które mogą zawierać podatne komponenty, powinieneś zweryfikować i zapytać dostawców. Ta klasa błędów to ryzyko łańcucha dostaw.
Q: Jak długo środki zaradcze za pomocą WAF mi pomogą?
A: Środki WAF mogą znacznie zmniejszyć narażenie i dać czas na łatkę, ale nie są trwałym substytutem naprawy przyczyny źródłowej. Wirtualne łatanie zmniejsza powierzchnię ataku, aż będziesz mógł zaktualizować podatne oprogramowanie.
Q: Czy powinienem rotować wszystkie klucze i tokeny?
A: Rotuj klucze używane przez uprzywilejowane integracje i wymuś unieważnienie tokenów dla kont, które zostały unieważnione lub skompromitowane. Priorytetowo traktuj klucze z uprawnieniami administracyjnymi.
Ostateczne przemyślenia z perspektywy bezpieczeństwa WordPressa
Ta luka w zabezpieczeniach jest ważnym przypomnieniem, że nowoczesne ekosystemy WordPressa rzadko są samodzielne. Integracje, automatyzacja i architektura bezgłowa poprawiają wydajność, ale zwiększają powierzchnię ataku. Traktuj swoje zewnętrzne zaplecza z taką samą starannością w zakresie bezpieczeństwa, jaką stosujesz do rdzenia WordPressa, motywów i wtyczek:
- Utrzymuj komponenty stron trzecich w aktualizacji.
- Używaj krótkich czasów życia tokenów i solidnych możliwości unieważnienia.
- Stosuj obronę w głębokości: łatanie, WAF, monitorowanie i gotowość na incydenty.
Jeśli zarządzasz witrynami dla klientów lub prowadzisz wiele środowisk, rozważ wdrożenie polityk, które wymagają automatycznego skanowania i aktualizacji zależności jako część swoich potoków CI/CD.
Jak WP‑Firewall może pomóc podczas łatania
Jeśli jesteś odpowiedzialny za bezpieczeństwo WordPressa i potrzebujesz natychmiastowej ochrony, odpowiednio skonfigurowany WAF może zapewnić wirtualne łatanie, blokować ryzykowne punkty końcowe, egzekwować listy dozwolone i zapobiegać próbom wykorzystania, aby dotrzeć do podatnych usług. Możemy pomóc Ci wdrożyć tymczasowe zasady ograniczające ekspozycję, monitorować próby i automatyzować odpowiedzi, podczas gdy Twoje zespoły inżynieryjne wdrażają poprawki upstream.
Tytuł: Zabezpiecz swoje witryny podczas łatania — uzyskaj natychmiastową ochronę WAF
Jeśli chcesz natychmiast aktywować podstawową ochronę, rozważ zapisanie się na plan WP‑Firewall Basic (darmowy). Obejmuje on zarządzany zaporę, nielimitowaną przepustowość, WAF, skaner złośliwego oprogramowania i łagodzenie ryzyk OWASP Top 10 — wszystko, czego potrzebujesz, aby szybko zmniejszyć ekspozycję podczas wdrażania poprawek upstream. Jeśli potrzebujesz większych możliwości, plany Standard i Pro dodają automatyczne usuwanie złośliwego oprogramowania, listy blokad IP, miesięczne raporty bezpieczeństwa, wirtualne łatanie i premium usługi zarządzane.
Zarejestruj się w planie WP‑Firewall Basic (Darmowy) tutaj
Jeśli potrzebujesz pomocy w audytowaniu swoich integracji, tworzeniu zasad WAF dla konkretnych punktów końcowych, których używasz, lub przeprowadzaniu ukierunkowanego wykrywania w całej infrastrukturze WordPressa, nasz zespół może pomóc. Incydenty bezpieczeństwa, takie jak ten, wymagają zarówno szybkich poprawek technicznych, jak i starannych kontroli operacyjnych — zastosuj powyższe kroki teraz, załatuj do 3.38.2+ tak szybko, jak to możliwe, i zweryfikuj, że zmiany ról są natychmiast honorowane we wszystkich zintegrowanych systemach.
