| Nazwa wtyczki | Motyw MetaMax |
|---|---|
| Rodzaj podatności | Lokalne włączenie plików |
| Numer CVE | CVE-2026-32500 |
| Pilność | Wysoki |
| Data publikacji CVE | 2026-03-22 |
| Adres URL źródła | CVE-2026-32500 |
Lokalna inkluzja plików w motywie MetaMax (<=1.1.4): Co właściciele stron WordPress muszą zrobić teraz
Autor: Zespół ds. bezpieczeństwa WP‑Firewall
Data: 2026-03-22
Streszczenie: Wysokosekwencyjna luka w lokalnej inkluzji plików (LFI) wpływająca na motyw WordPress MetaMax (wersje <= 1.1.4) została ujawniona i naprawiona w wersji 1.1.5. Luka jest nieautoryzowana i może być używana do odczytu lokalnych plików na dotkniętym serwerze (CVSS ~8.1). Ten post wyjaśnia, czym jest LFI, dlaczego jest ważne, jak napastnicy zazwyczaj to wykorzystują, na jakie wskaźniki zwracać uwagę oraz praktyczną, priorytetową listę kontrolną naprawy — w tym, jak WP‑Firewall chroni strony, nawet gdy aktualizacje nie mogą być zastosowane natychmiast.
TL;DR (dla właścicieli stron, którzy potrzebują krótkiej wersji)
- Klasa luki: Lokalna inkluzja plików (LFI).
- Dotknięte oprogramowanie: Motyw WordPress MetaMax, wersje <= 1.1.4.
- Ryzyko: Wysokie (nieautoryzowany dostęp, ujawnienie lokalnych plików zawierających dane uwierzytelniające, konfigurację lub inne wrażliwe dane).
- Naprawione w: MetaMax 1.1.5 — zaktualizuj natychmiast.
- Jeśli nie możesz zaktualizować natychmiast: wprowadź regułę zapory aplikacji internetowej (WAF), aby zablokować próby wykorzystania przejścia ścieżki i podejrzanych parametrów włączenia; wyłącz podatny motyw lub usuń go, aż zostanie poprawiony; ogranicz bezpośredni dostęp do plików motywu.
- Jeśli podejrzewasz kompromitację: izoluj stronę, zmień dane uwierzytelniające (użytkownik DB, sole WordPress, panel sterowania hostingu), przeskanuj i oczyść pliki, przywróć z czystej kopii zapasowej.
Czym jest lokalna inkluzja plików (LFI), w prostych słowach?
Lokalna inkluzja plików (LFI) to luka, w której aplikacja — w tym przypadku motyw WordPress — akceptuje ścieżkę lub nazwę pliku od napastnika, a następnie włącza lub odczytuje ten plik z serwera. Jeśli aplikacja nie zweryfikuje i nie ograniczy poprawnie tego, co może być włączone, napastnik może zmusić ją do odczytu dowolnych plików w systemie plików (na przykład, /etc/passwd Lub wp-config.php). Te pliki często zawierają sekrety (dane uwierzytelniające bazy danych, klucze API), które pozwalają napastnikowi na eskalację i pełną kontrolę nad stroną.
LFI różni się od zdalnej inkluzji plików (RFI) — która polega na ładowaniu treści z zdalnej strony — ale obie są niebezpieczne. LFI może prowadzić do naruszeń danych, obejścia uwierzytelniania, a nawet zdalnego wykonania kodu, gdy jest połączona z innymi słabościami (np. zanieczyszczenie logów).
Dlaczego ta luka LFI w MetaMax jest szczególnie pilna
- Nieuwierzytelniony: Wykorzystanie nie wymaga zalogowanego konta. Oznacza to, że każdy w internecie może próbować wykorzystać tę lukę.
- Pliki o wysokim wpływie są osiągalne: Pliki takie jak
wp-config.phpzazwyczaj znajdują się na tym samym serwerze i zawierają dane uwierzytelniające bazy danych i sole. Odczytanie ich może prowadzić do pełnej kompromitacji strony. - Zautomatyzowane skanowanie i masowe wykorzystanie: Badacze bezpieczeństwa często publikują szczegóły dotyczące takich luk, a atakujący używają zautomatyzowanych skanerów i zestawów exploitów, aby celować w tysiące stron w ciągu godzin lub dni.
- Łatka dostępna: Autor motywu wydał poprawioną wersję (1.1.5). Szybka aktualizacja łagodzi przyczynę — ale nie każdy może natychmiast zastosować aktualizacje (dostosowane motywy, złożoność stagingu, zarządzane środowiska).
Przegląd techniczny (nieeksploatacyjny)
- Typ luki: Lokalna Inkluzja Plików (LFI).
- Wersje dotknięte: MetaMax <= 1.1.4.
- Wektor ataku: Żądanie sieciowe, które manipuluje parametrem motywu / ścieżką dołączania (nieautoryzowane).
- Wpływ: Ujawnienie lokalnych plików; potencjalne wycieki danych uwierzytelniających; eskalacja po wykorzystaniu do zdalnego wykonania kodu w niektórych konfiguracjach.
- Łatka: MetaMax 1.1.5 zawiera odpowiednią walidację wejścia i/lub usunięcie niebezpiecznej logiki dołączania.
Nie opublikuję tutaj kodu exploita ani dokładnych nazw parametrów. Publiczne udostępnianie takich szczegółów bez starannych kontroli może przyspieszyć aktywne wykorzystanie. Jeśli jesteś administratorem strony korzystającej z MetaMax, traktuj to jako pilne i postępuj zgodnie z poniższymi krokami naprawczymi.
Wskaźniki prób wykorzystania lub kompromitacji
Monitoruj logi i zachowanie strony w poszukiwaniu następujących oznak:
- Nieoczekiwane żądania HTTP zawierające podejrzane sekwencje przechodzenia przez ścieżki, takie jak
../lub zakodowane warianty (%2e%2e%2f). - Żądania, które zawierają odniesienia do plików motywów, plików konfiguracyjnych lub innych lokalnych ścieżek plików w ciągach zapytań lub ciałach żądań.
- Duża liczba odpowiedzi 404/403 w krótkim okresie (skanery badające).
- Nowe lub zmodyfikowane pliki w instalacji WordPress, które nie zostały przez Ciebie wdrożone (szczególnie w
wp-content/przesyłanielub katalogach motywów/wtyczek). - Nowi użytkownicy administracyjni, zmienione uprawnienia lub nieoczekiwane zmiany w bazie danych.
- Połączenia wychodzące lub procesy uruchamiane przez PHP, które nie zostały przez Ciebie zainicjowane.
- Nieoczekiwane dane uwierzytelniające pojawiające się w logowaniach lub alertach od Twojego hosta wskazujących na nieudane lub podejrzane logowania.
Jeśli zobaczysz którykolwiek z tych objawów, traktuj to jako potencjalnie poważne i postępuj zgodnie z poniższymi krokami reagowania na incydenty.
Lista kontrolna natychmiastowej naprawy (priorytetowa)
- Zaktualizuj motyw MetaMax do wersji 1.1.5 (lub nowszej)
– To jest rozwiązanie dla przyczyny źródłowej. Natychmiast zaktualizuj motyw na wszystkich stronach, które go używają. Po aktualizacji przetestuj krytyczną funkcjonalność w środowisku testowym, gdy to możliwe. - Jeśli nie możesz zaktualizować natychmiast: wyłącz motyw MetaMax
– Przełącz się na znany dobry motyw domyślny (np. domyślny motyw WordPress) lub motyw testowy, aż będziesz mógł zastosować poprawkę. - Wprowadź WAF / wirtualną poprawkę
– Zarządzany WAF może blokować próby wykorzystania, które szukają wzorców LFI (przechodzenie ścieżek, żądania proszące o dołączenie /wp-config.php itp.). Wirtualne łatanie jest niezbędne, gdy natychmiastowe aktualizacje nie są możliwe. - Wzmocnij serwer WWW i uprawnienia do plików
– Upewnij sięwp-config.phpi inne wrażliwe pliki nie są dostępne do odczytu dla wszystkich. Użyj kontroli bezpieczeństwa na poziomie hosta, aby ograniczyć bezpośredni odczyt plików, gdzie to możliwe. - Wyłącz wykonywanie PHP w katalogach, które można zapisywać
– Na przykład, wyłącz wykonywanie PHP wwp-content/przesyłanieza pomocą .htaccess lub konfiguracji serwera WWW. - Zmień wrażliwe dane uwierzytelniające, jeśli kompromitacja jest prawdopodobna
– Hasło użytkownika bazy danych, sole WordPress (wwp-config.php), dane uwierzytelniające FTP/SFTP, klucze API. - Skanuj w poszukiwaniu złośliwego oprogramowania i oznak kompromitacji
– Przeprowadź kompleksowe skanowanie złośliwego oprogramowania w poszukiwaniu tylnej furtki, powłok internetowych i zmodyfikowanych plików. - Jeśli doszło do kompromitacji: przywróć z zweryfikowanej czystej kopii zapasowej
– Preferuj kopię zapasową sprzed podejrzewanej kompromitacji. Upewnij się, że luka jest załatana przed ponownym uruchomieniem strony. - Powiadom interesariuszy i postępuj zgodnie z planem reagowania na incydenty
– Dostawca hostingu, klienci i odpowiednie wewnętrzne zespoły powinny być poinformowane, jeśli dane mogły zostać potencjalnie ujawnione.
Praktyczne środki zaradcze WAF i wskazówki dotyczące wirtualnych poprawek (bezpieczne przykłady)
WAF może być używany do blokowania wzorców, które wykorzystują atakujący do eksploatacji LFI, bez konieczności ujawniania szczegółów eksploitu. Poniżej znajdują się strategie obronne i przykładowe pseudo-reguły (nie ciągi eksploitu). Użyj ich jako wskazówek do konfigurowania reguł w swoim zaporze lub wtyczce zabezpieczającej:
- Blokuj podejrzane sekwencje przejść:
– Odrzuć żądania zawierające sekwencje takie jak"../"oraz odpowiedniki zakodowane w URL, gdy pojawiają się w parametrach, które motyw używa do dołączania szablonów. - Blokuj próby żądania wewnętrznych plików konfiguracyjnych:
– Odrzuć każde żądanie, które próbuje uzyskać dostęp do znanych wrażliwych nazw plików (na przykład,wp-config.php,.env) przez parametry lub ciągi zapytań. - Ogranicz dozwolone ścieżki dołączania (podejście białej listy):
– Zezwól tylko na ładowanie znanych katalogów szablonów lub częściowych przez jakikolwiek parametr podobny do dołączenia. Wszelkie żądania spoza tych katalogów powinny być blokowane. - Ogranicz szybkość i blokuj automatyczne skanowanie:
– Wprowadź limity szybkości dla żądań kierowanych do punktów końcowych motywu; dodaj tymczasowe blokowanie IP dla podejrzanego zachowania. - Blokuj podejrzane rozszerzenia/znaki:
– Odrzuć parametry dołączania zawierające bajty NULL, średniki lub metaznaki powłoki. - Blokowanie geograficzne/reputacyjne:
– Jeśli to odpowiednie, tymczasowo ogranicz ruch z źródeł o złej reputacji, szczególnie gdy obserwujesz próby eksploatacji.
Przykład pseudo-reguły (koncepcyjnej):
JEŚLI request_parameter_contains("../") LUB
request_parameter_contains("") LUB
request_parameter_contains("wp-config.php") LUB
request_parameter_contains(".env")
WTEDY zablokuj żądanie I zarejestruj zdarzenie
Notatka: Nie wprowadzaj zbyt szerokich reguł, które łamią legalną funkcjonalność. Testuj reguły w trybie monitorowania/alertów przed włączeniem blokowania.
Klienci WP‑Firewall otrzymują dostosowane reguły wirtualnych poprawek, które odpowiadają wrażliwemu zachowaniu motywu, bez polegania na właścicielu strony w tworzeniu reguł. Jeśli korzystasz z zarządzanej zapory, poproś swojego dostawcę o zestaw reguł specyficznych dla LFI natychmiast po wydaniu poprawki.
Kroki wzmacniające poza WAF
Podejście warstwowe zmniejsza zależność od jednego kontrolera. Po zastosowaniu zasady WAF i zaktualizowaniu motywu, przyjmij te środki wzmacniające:
- Uprawnienia pliku
– Upewnij się, że pliki nie są zapisywalne dla wszystkich. Typowe zalecenia: pliki 644, katalogi 755.wp-config.phpmogą być ustawione na 600 lub 640 w zależności od twojego hosta. - Usuń nieużywane motywy i wtyczki
– Nieaktywne motywy i wtyczki mogą być powierzchnią ataku. Usuń wszystko, czego nie używasz aktywnie. - Wyłącz edytor motywów i wtyczek
– Zapobiega dowolnym edycjom PHP przez panel administracyjny WordPressa:
– Dodajdefine('DISALLOW_FILE_EDIT', true);Dowp-config.php - Ogranicz dostęp do wp-admin i wrażliwych punktów końcowych
– Użyj list dozwolonych adresów IP (gdzie to możliwe), uwierzytelniania dwuskładnikowego i silnych haseł administratora. - Wyłączenie wykonywania PHP podczas wysyłania plików
– Dodaj regułę .htaccess lub konfigurację Nginx, aby zapobiec wykonywaniu plików PHP w/wp-content/przesyłanie. - Chroń wp-config.php
– Przenieśwp-config.phpjeden katalog powyżej webroot, jeśli twój host na to pozwala; użyj reguł serwera WWW, aby odmówić dostępu bezpośredniego. - Monitoruj integralność
– Monitorowanie integralności plików (FIM) informuje o zmianach w krytycznych plikach i katalogach. - Utrzymuj rdzeń, motywy i wtyczki w aktualności
– Regularne zarządzanie łatkami jest jednym z najskuteczniejszych kontrolerów.
Jeśli twoja strona jest już skompromitowana — przewodnik po reagowaniu na incydenty
- Wyłącz stronę (lub ogranicz dostęp)
– Jeśli kompromitacja jest aktywna, wprowadź stronę w tryb konserwacji i zablokuj dostęp publiczny tam, gdzie to możliwe, aby zatrzymać dalsze szkody. - Zbieraj dowody
– Zachowaj logi (serwer WWW, PHP, baza danych), znaczniki czasu i kopie podejrzanych plików. To jest cenne dla analizy kryminalistycznej. - Zidentyfikuj punkt wejścia
– Sprawdź próby LFI w logach, przyjrzyj się ostatnim przesyłanym plikom, zmodyfikowanym plikom i nieautoryzowanym kontom użytkowników. - Rotacja danych uwierzytelniających
– Zmień hasła do bazy danych, sól WordPress wwp-config.php, oraz hasła FTP/SFTP lub panelu sterowania. Zakładaj, że wszelkie przechowywane dane uwierzytelniające mogą być skompromitowane. - Usuń tylne drzwi
– Wymagana jest ręczna czyszczenie i uruchomienie skanera złośliwego oprogramowania. Bądź świadomy, że niektóre tylne drzwi mogą być sprytne; usunięcie może wymagać doświadczonych rąk. - Przywróć z czystej kopii zapasowej
– Jeśli to możliwe, przywróć z kopii zapasowej wykonanej przed kompromitacją. Upewnij się, że podatny motyw jest zaktualizowany przed ponownym wdrożeniem. - Walidacja po czyszczeniu
– Ponownie zeskanuj, przeglądaj logi i monitoruj ponowne pojawienie się wskaźników kompromitacji przez kilka tygodni. - Zgłoś i ucz się
– Powiadom interesariuszy, udokumentuj, co się stało, i dostosuj procedury, aby zapobiec powtórzeniu (cykl łatania, poprawa kontroli dostępu).
Jeśli nie masz doświadczonych responderów incydentów w zespole, rozważ współpracę z wiarygodnym dostawcą zabezpieczeń WordPress lub swoim dostawcą hostingu, aby przeprowadzić głębsze dochodzenie i czyszczenie.
Jak skuteczny zarządzany WAF (taki jak WP‑Firewall) pomaga podczas ujawnienia LFI
Gdy ujawniana jest taka podatność, właściciele witryn mają trzy natychmiastowe potrzeby:
- Zatrzymaj próby eksploatacji uderzające w działające witryny (wirtualne łatanie).
- Załatw przyczynę źródłową (zastosuj aktualizację motywu).
- Wykryj i odpowiedz na wszelkie aktywne kompromitacje.
Zarządzany WAF może zaspokoić pierwszą potrzebę, wdrażając ukierunkowane zasady, które blokują próby eksploatacji dla podatnych wzorców — bez konieczności wprowadzania zmian w kodzie. To daje czas na aktualizację lub ocenę niestandardowych zależności. Ponadto skuteczne rozwiązanie zabezpieczeń skoncentrowane na WordPress powinno:
- Zapewnić zasady oparte na sygnaturach i zachowaniach specyficzne dla wzorców WordPress, aby zminimalizować fałszywe alarmy.
- Oferować automatyczne zestawy zasad dla znanych podatności, aby skrócić czas ochrony.
- Rejestrować i powiadamiać o zablokowanych próbach eksploatacji, abyś mógł zobaczyć, kto próbował i jak często.
- Łączyć wirtualne łatanie z skanowaniem złośliwego oprogramowania, aby wykryć pliki, które mogły zostać odczytane lub zmodyfikowane.
- Zapewnić krok po kroku wskazówki i dokumentację naprawczą dla twojego zespołu.
WP‑Firewall łączy zarządzane zabezpieczenia WAF, skanowanie złośliwego oprogramowania i praktyczne wskazówki dotyczące naprawy dostosowane do środowisk WordPress, abyś mógł szybko zredukować ryzyko związane z incydentami takimi jak ujawnienia LFI.
Jak zweryfikować, że Twoja strona jest bezpieczna po usunięciu zagrożeń
Po zastosowaniu poprawek i wzmocnieniu zabezpieczeń:
- Ponownie przeskanuj stronę za pomocą renomowanego skanera złośliwego oprogramowania i integralności.
- Przejrzyj ostatnie logi w poszukiwaniu dalszych prób i sprawdź, czy blokowanie zapobiegło wykorzystaniu.
- Zweryfikuj wersje rdzenia, motywu i wtyczek — upewnij się, że wszystko na stronie jest aktualne.
- Przejrzyj konta użytkowników w poszukiwaniu nieznanych użytkowników z uprawnieniami administratora.
- Potwierdź, że kopie zapasowe są czyste i zaplanowane.
- Monitoruj logi dostępu przez co najmniej 30 dni w poszukiwaniu podejrzanego zachowania.
Jeśli zmieniłeś dane uwierzytelniające, sprawdź usługi zależne (zadania cron, wtyczki z zewnętrznymi połączeniami, integracje stagingowe), aby upewnić się, że nadal działają i ich sekrety są zaktualizowane.
Rekomendacje oparte na dowodach dla dostawców hostingu i agencji
Dostawcy hostingu i agencje zarządzające wieloma stronami WordPress powinny:
- Natychmiast po ujawnieniu podatności stosować wirtualne poprawki na krawędzi (WAF).
- Utrzymywać inwentarz zainstalowanych motywów/wtyczek na stronach klientów, aby priorytetowo traktować aktualizacje.
- Oferować opcje automatycznych aktualizacji lub zarządzanego łatania dla krytycznych klas podatności.
- Zapewnić wsparcie w zakresie reakcji na incydenty i jasne ścieżki eskalacji dla klientów, którzy podejrzewają kompromitację.
- Wdrożyć centralne logowanie i monitorowanie, aby dostrzegać wzorce masowego skanowania w ich infrastrukturze.
Te kontrole operacyjne zmniejszają okno narażenia i ograniczają skalę kampanii masowego wykorzystania.
Ryzyka po wykorzystaniu: co robią napastnicy następnie
Jeśli napastnik skutecznie wykorzysta LFI i odczyta wp-config.php lub inne wrażliwe pliki, typowe następne kroki obejmują:
- Zbieranie danych uwierzytelniających do bazy danych i używanie ich do wykradania danych lub wstrzykiwania złośliwej treści.
- Tworzenie użytkowników administratora w WordPressie.
- Przesyłanie powłok sieciowych lub tylni drzwi (często ukrytych jako pliki PHP w folderach przesyłania lub motywów).
- Wykorzystanie skompromitowanej witryny do przejścia do innych witryn na tym samym serwerze lub wysyłania spamu i phishingowych wiadomości.
- Wykorzystanie zasobów serwera do kopania kryptowalut lub dalszej infrastruktury atakującego.
Dlatego szybkie działanie (łatki, wirtualne łatki, rotacja poświadczeń) jest niezbędne.
Zacznij chronić swoją witrynę WordPress w kilka minut
Chroń swoją witrynę za pomocą WP‑Firewall — zacznij za darmo
Jeśli prowadzisz jedną lub więcej witryn WordPress, nie musisz czekać, aby zredukować ryzyko. Zarejestruj się w planie podstawowym WP‑Firewall (darmowym) i uzyskaj natychmiastowe podstawowe zabezpieczenia: zarządzany zapora, nielimitowana przepustowość, zapora aplikacji internetowej (WAF) dostosowana do zagrożeń WordPress, skaner złośliwego oprogramowania oraz łagodzenie ryzyk OWASP Top 10. Ten darmowy poziom jest zaprojektowany, aby zatrzymać zautomatyzowane ataki i aktywność skanowania, które wykorzystują luki, takie jak Local File Inclusion, podczas gdy planujesz aktualizacje i wzmocnienia. Dowiedz się więcej i zarejestruj się tutaj: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Uwaga: plan podstawowy można później zaktualizować, aby dodać automatyczne usuwanie złośliwego oprogramowania, kontrolę zezwolenia/zakazu IP, miesięczne raporty bezpieczeństwa oraz wirtualne łatki dla zagrożeń zero-day.)
Lista kontrolna: Co zrobić teraz (jednostronicowa lista działań)
- [ ] Natychmiast zaktualizuj MetaMax do 1.1.5 (lub usuń/wyłącz motyw, jeśli nie możesz zaktualizować).
- [ ] Wprowadź WAF/wirtualną łatkę, aby zablokować wzorce LFI.
- [ ] Skanuj witrynę pod kątem złośliwego oprogramowania i podejrzanych plików.
- [ ] Rotuj dane bazy danych i poświadczenia uprzywilejowane, jeśli podejrzewasz kompromitację.
- [ ] Wzmocnij uprawnienia plików i wyłącz wykonywanie PHP w katalogach przesyłania.
- [ ] Usuń nieużywane motywy/wtyczki i wyłącz edytowanie plików w wp-admin.
- [ ] Monitoruj logi pod kątem powtarzających się prób wykorzystania i nietypowych zachowań.
- [ ] Upewnij się, że kopie zapasowe są dostępne i przetestowane.
Ostatnie przemyślenia zespołu WP‑Firewall
Luki LFI są jednymi z najpoważniejszych klas błędów na poziomie aplikacji, ponieważ często prowadzą do szybkiej eskalacji: proste odczytanie wp-config.php może dostarczyć wszystkich elementów, których potrzebuje atakujący do pełnego przejęcia witryny. Dobrą wiadomością jest to, że ta klasa problemów jest naprawialna: załatw oprogramowanie, wprowadź wirtualne zabezpieczenia przed witryną, wzmocnij środowisko i monitoruj wskaźniki kompromitacji.
Jeśli zarządzasz wieloma stronami WordPress, przyjmij podejście oparte na inwentarzu, aby szybko reagować na ujawnienia motywów i wtyczek. Jeśli wolisz zatrzymać próby wykorzystania podczas łatania, zarządzany WAF WordPress w połączeniu z skanowaniem złośliwego oprogramowania i dostosowaną pomocą znacznie zmniejszy twoje ryzyko i da ci czas na bezpieczne aktualizacje.
Jeśli potrzebujesz pomocy w szybkim wdrożeniu wirtualnej łatki — lub chcesz natychmiastowej podstawy ochrony za darmo — zarejestruj się w planie WP‑Firewall Basic (Darmowy) i włącz podstawowe zabezpieczenia od razu: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Bądź bezpieczny i proaktywny — luki w zabezpieczeniach są często odkrywane, ale to, jak szybko działasz, ma znaczenie między zablokowanym atakiem a pełnym kompromitacją.
— Zespół ds. bezpieczeństwa WP‑Firewall
Odniesienia i dalsza lektura
- Wskazówki dotyczące wzmocnienia WordPressa (oficjalna dokumentacja).
- Wytyczne OWASP Top 10 dotyczące ryzyk związanych z wstrzykiwaniem i dołączaniem plików.
- Najlepsze praktyki dotyczące reakcji na incydenty i rotacji poświadczeń.
(Nie publikuj publicznie kodu exploitów ani parametrów; jeśli jesteś administratorem strony i potrzebujesz dokładnych wskaźników do triage, skontaktuj się z zaufanym dostawcą zabezpieczeń WordPress lub swoim hostem w celu uzyskania bezpiecznych, prywatnych wskazówek.)
