| Nazwa wtyczki | Zaawansowane pola niestandardowe |
|---|---|
| Rodzaj podatności | Złamana kontrola dostępu |
| Numer CVE | CVE-2026-4812 |
| Pilność | Niski |
| Data publikacji CVE | 2026-04-15 |
| Adres URL źródła | CVE-2026-4812 |
Naruszenie kontroli dostępu w Advanced Custom Fields (ACF) — Co właściciele stron WordPress muszą zrobić teraz
Data: 15 kwietnia 2026
Dotknięta wtyczka: Advanced Custom Fields (ACF) — wersje <= 6.7.0
Poprawione w: 6.7.1
Powaga: Niski / CVSS 5.3 (Naruszenie kontroli dostępu)
CVE: CVE-2026-4812
Jako zespół ds. bezpieczeństwa WordPress, pracujący codziennie nad ochroną tysięcy stron, musimy być szczerzy: nawet problemy z kontrolą dostępu o “niskim” ciężarze mają znaczenie. Ten błąd ACF pozwala na nieautoryzowane żądania do pobierania danych pól powiązanych z dowolnymi identyfikatorami postów/stron za pomocą zapytania AJAX. To oznacza, że atakujący — bez logowania się — może być w stanie zbadać Twoją stronę i uzyskać informacje, które powinny być prywatne: treści robocze, prywatne pola postów lub inne wrażliwe metadane przechowywane przez pola ACF.
Jeśli używasz ACF na jakiejkolwiek stronie WordPress, przeczytaj tę kompleksową poradę. Wyjaśnimy dokładnie, co się dzieje, dlaczego to ma znaczenie, jak wykryć, czy zostałeś zbadany lub gorzej, oraz konkretne środki zaradcze, które możesz zastosować natychmiast — w tym zasady WAF i poprawki kodu — aby zablokować próby ataku, aż będziesz mógł zaktualizować do ACF 6.7.1.
Streszczenie wykonawcze (co każdy właściciel strony musi wiedzieć)
- Luka bezpieczeństwa dotyczy wersji Advanced Custom Fields (ACF) do i włącznie z 6.7.0.
- Jest to problem z naruszeniem kontroli dostępu w obsłudze zapytań AJAX: brak kontroli autoryzacji pozwala na nieautoryzowane żądania ujawniające pola dla dowolnych identyfikatorów postów/stron.
- Dostawca naprawił to w 6.7.1. Aktualizacja wtyczki jest zalecaną poprawką.
- Jeśli nie możesz zaktualizować natychmiast, wprowadź natychmiastowe środki zaradcze: zastosuj wirtualną łatkę za pomocą swojego WAF, ogranicz wrażliwe punkty końcowe AJAX na poziomie serwera lub zastosuj tymczasową kontrolę na poziomie kodu, aby zablokować nieautoryzowane zapytania.
- Przejrzyj logi w poszukiwaniu podejrzanej aktywności: żądania admin-ajax o dużym wolumenie lub powtarzające się zapytania, które enumerują identyfikatory postów, są kluczowymi wskaźnikami.
- Mimo że CVSS jest umiarkowane (5.3), narażenie może być znaczące (prywatne wersje robocze, PII, nieopublikowane treści). Traktuj to poważnie.
Dlaczego ta podatność ma znaczenie
Advanced Custom Fields jest szeroko stosowane do przechowywania zorganizowanej treści: fragmentów tekstu, wartości meta, prywatnych notatek, danych dostarczonych przez użytkowników i innych. Wiele stron używa pól ACF do obsługi treści, która nie jest przeznaczona do publicznego wglądu — notatek wewnętrznych, wersji roboczych lub pól używanych przez członkostwo lub prywatne przepływy treści.
Gdy nieautoryzowane żądanie HTTP może zapytać o obsługę pól AJAX ACF i uzyskać dane powiązane z dowolnymi identyfikatorami postów, natychmiastowe ryzyko to wyciek wrażliwych danych:
- Prywatna lub robocza treść postów może zostać ujawniona.
- Treści dostępne tylko dla członków lub metadane subskrypcyjne mogą być narażone.
- Wewnętrzne dane biznesowe przechowywane w niestandardowych polach (adresy, numery telefonów, notatki dotyczące etapu produktu) mogą zostać odzyskane.
- Atakujący mogą przeprowadzać rozpoznanie: mapować identyfikatory postów, typy treści i odkrywać nieopublikowane treści, które mogą być wykorzystane do późniejszej eksploatacji lub inżynierii społecznej.
Nawet jeśli nie ma bezpośrednich skutków przejęcia strony, samo naruszenie poufności stanowi realne ryzyko dla firm i wydawców.
Przegląd techniczny (na wysokim poziomie, nieeksploatacyjny)
- ACF rejestruje (lub wcześniej zarejestrowany) punkt końcowy AJAX, który akceptuje parametry zapytania pól, w tym parametr identyfikatora posta. Punkt końcowy ma na celu zwrócenie danych pól związanych z postem lub stroną.
- Z powodu braku kontroli autoryzacji (brak egzekwowania uprawnień/nonce/uwierzytelniania użytkownika), ten punkt końcowy akceptuje żądania od nieautoryzowanych użytkowników i zwraca wartości pól dla żądanego identyfikatora posta.
- Atakujący może wydawać powtarzające się żądania, iterując po identyfikatorach postów, aby zbierać pola i treści, aż znajdzie przydatne lub wrażliwe dane.
Ważny: Nie dostarczymy tutaj kodu dowodowego wykorzystania. Celem tego opisu jest poinformowanie właścicieli stron i administratorów, aby mogli chronić swoje strony i użytkowników.
Co zrobić teraz — priorytetowa lista kontrolna
- Natychmiast zaktualizuj ACF do wersji 6.7.1 (lub nowszej).
To jest opublikowana poprawka. Aktualizacja to najlepszy krok. - Jeśli nie możesz zaktualizować natychmiast, zastosuj wirtualne łatanie za pomocą WAF.
Zablokuj nieautoryzowane żądania do punktów końcowych ACF AJAX, dopasowując akcję AJAX lub parametry zapytania związane z zapytaniami pól. Zobacz sekcję “Zasady WAF i przykłady” poniżej w celu uzyskania wskazówek. - Wzmocnij dostęp do admin-ajax.php i innych punktów końcowych AJAX.
Jeśli Twoja strona nie potrzebuje anonimowego dostępu do ACF AJAX na froncie, ogranicz dostęp według IP, wymagaj uwierzytelnienia lub odrzucaj żądania z określonymi wzorcami ciągu zapytania. - Dodaj krótki kodowy zabezpieczenie jako tymczasowe łagodzenie.
Wstaw małe sprawdzenie, aby upewnić się, że tylko uwierzytelnieni użytkownicy mogą uzyskać dane pól ACF za pomocą AJAX. (Przykład kodu podany później.) - Monitoruj logi i wykrywaj wzorce rozpoznawcze.
Szukaj powtarzających się żądań do admin-ajax.php (lub punktów końcowych utworzonych przez ACF) z parametrami takimi jak action=acf* i post_id lub post. Powtarzające się enumeracje identyfikatorów postów to czerwony flag. - Jeśli podejrzewasz dostęp do danych lub ich wyciek, postępuj zgodnie z krokami odpowiedzi na incydent.
Zachowaj logi, rotuj sekrety w razie potrzeby, audytuj konta użytkowników i przywróć z czystej kopii zapasowej, jeśli wystąpiły modyfikacje.
Jak atakujący nadużywają tego błędu — realistyczne scenariusze
- Zbieranie treści: Atakujący enumeruje identyfikatory postów i zbiera nieopublikowane treści, które mogą zostać wycieknięte lub sprzedane.
- Rozpoznanie dla większych kampanii: Informacje odkryte tutaj pomagają w tworzeniu wiadomości spear-phishingowych skierowanych do autorów lub redaktorów stron.
- Ekspozycja PII: Jeśli niestandardowe pola zawierają dane osobowe (adresy, numery telefonów, rekordy e-mail), staje się to naruszeniem prywatności i może wywołać obowiązki związane z zgodnością.
- Inteligencja konkurencyjna: Szkice opisów produktów, notatki cenowe lub ogłoszenia objęte embargiem mogą zostać ujawnione.
- Wtórna eksploatacja: Dane znalezione poprzez ujawnienie pól mogą dać wskazówki do eskalacji uprawnień lub pomóc zidentyfikować nazwy użytkowników administratorów w celu ataków credential stuffing lub inżynierii społecznej.
Ponieważ można to zautomatyzować na dużą skalę, wiele stron może być badanych w ciągu kilku minut po opublikowaniu luki.
Wskaźniki kompromitacji / wskazówki dotyczące wykrywania
Obserwuj swoje logi serwera i aplikacji pod kątem następujących wzorców:
- Powtarzające się żądania do admin-ajax.php z tego samego adresu IP, szczególnie wywołania GET lub POST z ciągami zapytań zawierającymi:
- action=acf…
- action=acf/field_group… lub action=acf/load_field lub podobne akcje specyficzne dla ACF
- parametry nazwane post_id, post lub ID z różnymi wartościami numerycznymi
- Wysoka liczba odpowiedzi 200, które zawierają JSON z wartościami pól, nawet gdy żądanie jest nieautoryzowane.
- Żądania do admin-ajax.php z nietypowych user-agentów lub adresów IP znanych z skanowania.
- Nietypowe skoki ruchu do punktów końcowych AJAX poza normalnym zachowaniem strony (np. blog bez front-end AJAX nagle otrzymujący dużo ruchu admin-ajax).
- Nieudane próby logowania lub rejestracje nowych użytkowników w koordynacji z zapytaniami do pól (reconscape plus późniejsza eksploatacja).
Ustaw alerty dla:
- Więcej niż X żądań do admin-ajax.php w Y minut z jednego adresu IP.
- Jakakolwiek odpowiedź 200 z admin-ajax.php, która zwraca treść dla nieautoryzowanego żądania, gdy normalnie ten punkt końcowy powinien odrzucać anonimowe wywołania.
Krótkoterminowe łagodzenie kodu (tymczasowe, do momentu aktualizacji)
Jeśli nie możesz od razu zaktualizować, dodaj zabezpieczenie do swojego motywu lub mały mu-plugin, który blokuje nieautoryzowane żądania do akcji AJAX ACF. Umieść to w małym pluginie drop-in lub w swoim motywie funkcje.php (preferuj mu-plugin, aby zapewnić jego działanie nawet w przypadku zmiany motywów).
Przykład (koncepcyjny, bezpieczny do wdrożenia):
<?php
// Disable anonymous access to ACF AJAX actions (temporary mitigation)
// Save this as wp-content/mu-plugins/acf-anon-guard.php
add_action('admin_init', function() {
// Only run for front-end AJAX requests
if ( defined('DOING_AJAX') && DOING_AJAX ) {
// If user is not logged in and the request appears to be for ACF field AJAX
$action = isset($_REQUEST['action']) ? sanitize_text_field($_REQUEST['action']) : '';
$post_param = isset($_REQUEST['post_id']) ? intval($_REQUEST['post_id']) : null;
// Adjust these checks to match the specific ACF actions you see in logs
if ( !is_user_logged_in() && ( strpos($action, 'acf') !== false || $post_param ) ) {
// Return a generic 403 and stop further processing
status_header(403);
wp_die('Forbidden', 'Forbidden', array('response' => 403));
}
}
});
Uwagi:
- To jest tymczasowe rozwiązanie. Celowo popełnia błąd w kierunku blokowania potencjalnych ważnych anonimowych funkcji ACF na froncie, więc przetestuj na stagingu przed zastosowaniem na stronach produkcyjnych o dużym ruchu.
- Użyj wtyczki Must-Use (mu), aby trudno było przypadkowo ją dezaktywować.
- Gdy aktualizujesz ACF, usuń tę ochronę, jeśli blokuje ona legalne zachowanie, lub doprecyzuj ją, aby blokowała tylko nazwy akcji związane z luką.
Ochrony na poziomie serwera (przykłady Nginx / Apache)
Jeśli możesz kontrolować konfigurację serwera, możesz globalnie blokować podejrzane wzorce ciągu zapytania:
Nginx (przykład)
# Blokuj żądania do admin-ajax.php, które zawierają akcje związane z acf i post_id, gdy nie są uwierzytelnione
Apache mod_rewrite (przykład)
RewriteEngine On
Bądź ostrożny: te zasady są tępe. Przetestuj je na stagingu przed wdrożeniem, ponieważ niektóre legalne funkcje ACF na froncie (niektóre motywy/aplikacje używają publicznego ACF AJAX) mogą zostać uszkodzone. Jeśli masz konkretne nazwy akcji z logów, celuj w nie bardziej precyzyjnie.
Zasady WAF i wirtualne łatanie (zalecane, jeśli masz zarządzany WAF)
Jeśli używasz zapory aplikacji internetowej, wirtualne łatanie jest najszybszym sposobem na zablokowanie eksploatacji na wszystkich stronach. Typowe zasady WAF oparte na wzorcach, które zalecamy:
- Blokuj nieautoryzowane żądania do admin-ajax.php, gdzie:
- Ciąg zapytania zawiera wartości akcji, które zawierają “acf” lub znane podatne ciągi (np. acf/load_field, acf/field_group/get_fields).
- Ciąg zapytania zawiera post_id lub parametry post z wartościami numerycznymi, a żądanie jest GET lub POST bez uwierzytelnionych ciasteczek.
- Ogranicz liczbę żądań z adresów IP klientów, które wysyłają więcej niż N żądań do admin-ajax.php w ciągu M sekund.
- Podnoś alerty na odpowiedziach zwracających zawartość JSON, która wydaje się zawierać klucze/wartości pól ACF dla anonimowych żądań.
Przykładowa logika zasady WAF:
- JEŚLI request.path == “/wp-admin/admin-ajax.php” I request.method W (GET, POST) I request.query.action pasuje do /acf/i I NIE request.cookies zawiera ciasteczko uwierzytelniające TO blokuj (403) i powiadom.
Dobrze dostrojony WAF również:
- Pozwoli na uwierzytelnione żądania z ciasteczek sesyjnych (więc zalogowani edytorzy nie są blokowani).
- Powiadom administratorów witryny, gdy reguła zostanie wyzwolona, z przykładowym żądaniem i adres IP pochodzenia.
Jeśli już używasz ochrony na poziomie aplikacji, włącz regułę awaryjną, która celuje w punkty końcowe ACF, aż do aktualizacji.
Zapytania detekcyjne i poszukiwanie logów (praktyczne przykłady)
Użyj logów serwera lub SIEM, aby wyszukać:
- żądania admin-ajax.php:
grep "admin-ajax.php" access.log | grep -i acf
- Zapytania z parametrami akcji:
- wpisy access.log zawierające “action=acf” lub “action=acf/load_field” lub podobne.
- Wzorce enumeracji:
- Wiele żądań z tego samego adresu IP z sekwencyjnymi wartościami post_id (1,2,3,… lub 100,101,102,…).
- Zawartość odpowiedzi:
- Każda odpowiedź 200 na admin-ajax.php zwracająca ładunki JSON, które zawierają znane klucze pól ACF lub grupy pól (identyfikatory field_XXXX).
Uczyń te wyszukiwania częścią swojej rutyny, gdy nowa luka w wtyczce jest publiczna; atakujący często skanują szeroko po ujawnieniu.
Reakcja na incydent — jeśli uważasz, że twoja witryna została zbadana lub dane zostały odzyskane
- Natychmiast zachowaj logi. Nie nadpisuj ani nie obracaj, dopóki śledztwo nie zostanie zakończone.
- Zidentyfikuj ramy czasowe podejrzanych żądań i adresy IP pochodzenia.
- Sprawdź te adresy IP pod kątem innych podejrzanych zachowań (logowania, przesyłanie wtyczek, edytowanie plików).
- Jeśli wykryjesz ujawnienie danych wrażliwych:
- Powiadom swoje zespoły prawne / ochrony prywatności, jeśli dane osobowe mogły zostać ujawnione.
- Zmień klucze API, tokeny lub jakiekolwiek sekrety, które mogły zostać ujawnione.
- Skanuj witrynę pod kątem złośliwego oprogramowania i webshelli. Atakujący, który uzyska informacje, może próbować działań następczych.
- Przywróć z czystego zrzutu, jeśli znajdziesz modyfikacje, które nie możesz pewnie naprawić.
- Zmień hasła dla użytkowników administracyjnych i upewnij się, że wszelkie skompromitowane konta zostały usunięte i zbadane.
Długoterminowe wzmacnianie i najlepsze praktyki
- Utrzymuj wtyczki, motywy i rdzeń WordPressa na bieżąco. Kropka.
- Użyj zarządzanego WAF lub wdroż reguły blokowania dostosowane do punktów końcowych AJAX WordPressa.
- Ogranicz nieautoryzowaną ekspozycję punktów końcowych AJAX administracyjnych. Jeśli Twoja witryna nie potrzebuje publicznych punktów wejścia AJAX, ogranicz dostęp.
- Zmniejsz przyrost uprawnień: zminimalizuj liczbę administratorów i przeglądaj role użytkowników co miesiąc.
- Wdroż logowanie i powiadamianie o anomaliach w wzorcach ruchu do admin-ajax.php, punktów końcowych wp-json i ścieżek przesyłania plików.
- Twórz kopie zapasowe i przechowuj je poza siedzibą z wystarczającym czasem przechowywania, aby móc cofnąć się do czystego stanu, jeśli zajdzie taka potrzeba.
- Traktuj CVE jako informacje do działania. Nawet “niskie” problemy CVSS mogą prowadzić do znaczących wycieków w zależności od tego, jakie dane są przechowywane.
Jak my (WP-Firewall) chronimy Twoją witrynę przed takimi problemami
Jako zarządzany dostawca bezpieczeństwa WordPressa, naszym celem jest zamknięcie okna między ujawnieniem a ochroną. Oto, co robimy, aby bezpośrednio bronić witryn przed lukami, takimi jak złamane kontrolowanie dostępu ACF:
- Zarządzany WAF i wirtualne łatanie: Wprowadzamy ukierunkowane reguły, aby blokować próby ataków na znane podatne punkty końcowe, dzięki czemu Twoja witryna jest chroniona nawet przed aktualizacją.
- Powiadomienia do działania: Otrzymasz jasne, priorytetowe powiadomienia, gdy wykryjemy próby wykorzystania lub podejrzaną aktywność przeciwko punktom końcowym wtyczek, takim jak ACF.
- Skanowanie złośliwego oprogramowania i automatyczne łatanie: Skanujemy w poszukiwaniu wskaźników, że atakujący przeszedł od rozpoznania do utrzymania i usuwamy powszechne zagrożenia internetowe.
- Dostosowane rekomendacje: Dajemy krok po kroku wskazówki dotyczące naprawy, aby bezpiecznie zaktualizować wtyczkę i usunąć tymczasowe łatania po łataniu.
- Ograniczanie szybkości i wykrywanie anomalii: Ograniczamy podejrzane wzorce żądań, aby zapobiec szybkiemu automatycznemu enumerowaniu identyfikatorów postów.
Jeśli korzystasz z naszego zarządzanego WAF, możemy natychmiast wirtualnie załatać tę klasę luk we wszystkich chronionych witrynach, przerywając kampanie masowego skanowania i zmniejszając ryzyko podczas aktualizacji wtyczek.
Praktyczny przykład: jak mogłaby wyglądać dobra reguła WAF (koncepcyjna)
Poniżej znajduje się koncepcyjna reguła, którą możesz poprosić swojego administratora WAF o wdrożenie. Jest to celowo niezwiązane z żadnym dostawcą. Podziel się tym z kimkolwiek zarządza Twoim WAF lub hostem.
Intencja zasady: Zablokuj anonimowe żądania do admin-ajax.php, które wydają się być zapytaniami o pola ACF.
- Warunek A: REQUEST_URI równa się “/wp-admin/admin-ajax.php”
- Warunek B: QUERY_STRING zawiera “action=” i ta wartość pasuje do regex /acf/i LUB QUERY_STRING zawiera “post_id=[0-9]+”
- Warunek C: Nadchodzące żądanie NIE zawiera ważnego ciasteczka uwierzytelniającego WordPress (wordpress_logged_in_* lub podobne)
- Akcja: Zablokuj (403) i zarejestruj szczegóły (IP, znacznik czasu, user-agent, pełne zapytanie)
Pamiętaj: przetestuj każdą zasadę najpierw w trybie monitorowania/tylko logowanie, aby uniknąć blokowania legalnego ruchu.
Często zadawane pytania
P: Czy ta luka to pełne przejęcie witryny?
O: Nie, problemem jest uszkodzona kontrola dostępu do ujawnienia danych za pomocą zapytań AJAX o pola — nie przyznaje to bezpośrednio zdalnego wykonania kodu ani tworzenia administratorów. Ale ujawnienie danych może umożliwić inżynierię społeczną lub wtórne ataki, więc traktuj to poważnie.
P: Moja strona korzysta z ACF front-end AJAX. Czy tymczasowe blokady przerwą funkcjonalność?
O: Możliwe. Jeśli polegasz na anonimowym front-end ACF AJAX dla legalnej funkcjonalności (np. formularze front-end, które zwracają grupy pól), musisz przetestować zmiany na etapie testowym. Preferuj celowane blokowanie według konkretnych nazw akcji zamiast szerokich blokad admin-ajax.php.
P: Jak pilna jest ta poprawka?
O: Zaktualizuj ACF tak szybko, jak to możliwe. Jeśli nie możesz, wdroż ochronę WAF i ograniczenia na poziomie serwera już dziś. Napastnicy skanują automatycznie po ujawnieniu luk w zabezpieczeniach.
Chroń swoją stronę teraz za pomocą darmowej podstawy — WP-Firewall Basic (Darmowy)
Ochrona Twojej strony WordPress nie musi być kosztowna na początku. Jeśli chcesz natychmiastowej, zarządzanej ochrony przed takimi problemami — w tym zarządzanym zaporą, skanerem złośliwego oprogramowania i łagodzeniem ryzyk OWASP Top 10 — oferujemy darmowy plan podstawowy, który obejmuje podstawy.
Chroń swoją stronę natychmiast — zacznij od darmowego planu WP-Firewall
- Podstawowa ochrona: zarządzana zapora z wirtualnym łatawieniem, nielimitowana przepustowość, zapora aplikacji webowej (WAF), skaner złośliwego oprogramowania i automatyczne łagodzenie ryzyk OWASP Top 10.
- Idealne dla właścicieli stron, którzy chcą szybkiej, łatwej ochrony podczas aktualizacji wtyczek i wzmacniania konfiguracji.
- Zarejestruj się i włącz ochronę w kilka minut: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Jeśli później chcesz automatycznego usuwania złośliwego oprogramowania, listy dozwolonych/zabronionych adresów IP, miesięcznych raportów bezpieczeństwa, automatycznego wirtualnego łatawienia lub dedykowanego menedżera bezpieczeństwa, oferujemy również plany Standard i Pro, aby dostosować się do Twoich potrzeb.
Lista kontrolna — działania do wykonania dzisiaj
- Zaktualizuj ACF do wersji 6.7.1 lub nowszej.
- Jeśli nie możesz zaktualizować od razu, włącz regułę WAF, aby zablokować nieautoryzowane żądania ACF AJAX.
- Dodaj krótkoterminową mu-wtyczkę ochronną (jeśli jest to bezpieczne w twoim środowisku).
- Sprawdź logi serwera pod kątem skanów admin-ajax.php i wymień podejrzane adresy IP.
- Przeprowadź audyt pól niestandardowych: zidentyfikuj, gdzie przechowywane są wrażliwe dane w polach ACF i rozważ przeniesienie ich za silniejsze kontrole dostępu.
- Upewnij się, że masz aktualne kopie zapasowe i plan przywracania.
- Rozważ włączenie zarządzanego zapory ogniowej lub usługi zabezpieczeń, która oferuje wirtualne łatanie i aktywne monitorowanie.
Podsumowanie
Problemy z kontrolą dostępu, takie jak ten, przypominają: bezpieczeństwo to nie tylko zapobieganie wykonaniu kodu lub eskalacji uprawnień — chodzi również o ochronę poufności. Strony WordPress często gromadzą cenne lub wrażliwe dane strukturalne w miejscach, które wtyczki mają zarządzać. Gdy wtyczka nieumyślnie ujawnia te dane w nieautoryzowanych żądaniach, skutki mogą być realne.
Załatw wtyczkę, ale nie zatrzymuj się na tym. Połącz łatanie z obroną w głębokości: zasady serwera, wirtualne łaty WAF, logowanie i powiadomienia oraz rutynowe audyty treści i kont użytkowników. Jeśli potrzebujesz pomocy podczas okna aktualizacji lub chcesz skrócić czas między ujawnieniem a ochroną, nasz zespół może wdrożyć awaryjną ochronę WAF i pomóc ci zweryfikować, że twoja strona nie jest już narażona.
Bądź bezpieczny, a jeśli potrzebujesz pomocy, rozważ rozpoczęcie od darmowego planu WP-Firewall Basic, aby szybko włączyć zarządzaną ochronę dla swojej strony: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
— Zespół Bezpieczeństwa WP-Firewall
