Nazwa wtyczki	Perfmatters
Rodzaj podatności	Przeglądanie katalogów
Numer CVE	CVE-2026-4351
Pilność	Wysoki
Data publikacji CVE	2026-04-12
Adres URL źródła	CVE-2026-4351

Przechodzenie przez katalogi w Perfmatters (≤ 2.5.9) — Co właściciele stron WordPress muszą zrobić teraz

Data: 10 kwietnia 2026
Autor: Zespół ds. bezpieczeństwa WP‑Firewall

Streszczenie

Wysokosekwencyjna podatność na przechodzenie przez katalogi, która dotyczy wtyczki Perfmatters dla WordPress (wersje ≤ 2.5.9), została ujawniona (CVE‑2026‑4351). Uwierzytelniony atakujący z kontem Subskrybenta może manipulować obsługą fragmentów wtyczki i spowodować nadpisanie dowolnych plików w systemie plików. Może to prowadzić do trwałych tylni drzwi, eskalacji uprawnień, zniekształcenia strony lub całkowitego przejęcia strony. Dostawca wydał poprawioną wersję (2.6.0). Jeśli nie możesz natychmiast zaktualizować, powinieneś zastosować środki kompensacyjne — przede wszystkim WAF (wirtualne łatanie), wzmocnienie uprawnień, skanowanie i ukierunkowane monitorowanie — aby zminimalizować ryzyko.

Ten post wyjaśnia, w prosty, ale technicznie dokładny sposób:

• czym jest ta podatność i dlaczego jest poważna;
• jak ryzyko i możliwość wykorzystania przekładają się na ataki w rzeczywistym świecie;
• jakie natychmiastowe kroki podjąć (aktualizacja + tymczasowe łagodzenia);
• jak kompetentna zapora WordPress, taka jak WP‑Firewall, chroni cię teraz i w przyszłości;
• lista kontrolna reakcji na incydenty oraz długoterminowe zalecenia dotyczące wzmocnienia.

Napisaliśmy to jako pracujący operatorzy bezpieczeństwa, a nie teoretycy — działania, ostrożnie i skoncentrowani na pomocy właścicielom stron w ochronie użytkowników i danych bez umożliwiania atakującym.

Co dokładnie się stało?

Podatna ścieżka kodu znajduje się w obsłudze parametru w wtyczce Perfmatters, który jest używany do przechowywania i aktualizowania “fragmentów”. Uwierzytelniony użytkownik z uprawnieniami Subskrybenta mógłby dostarczyć spreparowany input w tym parametrze, co wyzwala przechodzenie przez katalogi i nadpisanie pliku na serwerze. Podatności na przechodzenie przez katalogi pozwalają atakującym na odniesienie się do ścieżek plików poza zamierzonym kontekstem katalogu (na przykład używając sekwencji takich jak ../) i, w połączeniu z możliwością zapisu, pozwalają na nadpisywanie dowolnych plików, które serwer WWW lub proces PHP mogą zapisać.

Konsekwencje obejmują:

• nadpisywanie plików motywów/wtyczek lub plików do przesłania zawartością atakującego (shelli webowych, tylni drzwi);
• osadzanie kodu PHP w plikach wtyczek/motywów, które są używane przez stronę;
• zastępowanie plików konfiguracyjnych lub przesyłanie plików PHP do lokalizacji wykonywanych przez serwer;
• przerywanie dostępności strony poprzez uszkodzenie krytycznych plików.

Dlaczego to ma znaczenie (model zagrożeń)

Kluczowe cechy, które sprawiają, że ta podatność jest niebezpieczna:

• Wymagane uprawnienia: Subskrybent. Wiele stron WordPress pozwala na rejestrację użytkowników na tym poziomie roli (strony członkowskie, przepływy pracy komentarzy, treści z ograniczonym dostępem), więc atakujący nie musi być administratorem.
• Nadpisywanie dowolnych plików: nie ogranicza się do obszaru przechowywania w piaskownicy; pliki poza zamierzoną ścieżką mogą być celem, gdy przechodzenie przez katalogi jest możliwe.
• Wysoki CVSS (8.1): odzwierciedla potencjał do wykonania kodu i szeroki wpływ.
• Potencjał masowego wykorzystania: gdy jakikolwiek wzór wykorzystania jest publiczny i łatwy do zautomatyzowania, atakujący o niskich umiejętnościach mogą szybko skanować i kompromitować wiele stron.

Uwierzytelnione, ale nisko uprawnione konta są powszechne na stronach WordPress. W praktyce atakujący często uzyskują dostęp Subskrybenta, rejestrując się, wykorzystując słabe zewnętrzne uwierzytelnienie, kupując skompromitowane konta lub wykorzystując stuffing poświadczeń. To sprawia, że luka jest praktyczna w terenie.

Podsumowanie techniczne (nieeksploatacyjne)

• Wrażliwy punkt końcowy: akcja wtyczki obsługująca parametr snippets.
• Klasa podatności: Przechodzenie przez katalog + nadpisywanie dowolnych plików.
• Wyzwalacz: stworzony zestaw danych ścieżki w snippets, który omija zamierzoną sanitizację/walidację i skutkuje zapisem do rozwiązanej ścieżki poza dozwolonym katalogiem.
• Poprawione w wersji: 2.6.0 przez autora wtyczki.
• CVE: CVE‑2026‑4351 (ujawnienie publiczne).

Nie dostarczymy dowodów koncepcji ani kodu, który pozwoliłby atakującym powtórzyć wykorzystanie. Jeśli jesteś deweloperem lub administratorem strony, skontaktuj się z pomocą WP‑Firewall lub dostawcą wtyczki w celu uzyskania bezpiecznych kroków reprodukcji lub logów.

Natychmiastowe działania — triage i łagodzenie

Jeśli Twoja strona używa Perfmatters i działa w wersji ≤ 2.5.9, wykonaj te kroki teraz — w mniej więcej tej kolejności:

1. Zaktualizuj wtyczkę do 2.6.0 (lub nowszej)
   • To jedyne pełne rozwiązanie. Testuj na stronie testowej, jeśli musisz, ale priorytetowo traktuj szybkie zastosowanie poprawki na produkcji, jeśli to możliwe.
   • Jeśli zarządzasz wieloma stronami, użyj automatyzacji aktualizacji lub narzędzi do centralnego zarządzania, aby szybko wdrożyć 2.6.0.
2. Jeśli nie możesz zaktualizować natychmiast, zastosuj wirtualne łatanie za pomocą WAF
   • Zablokuj wszelkie żądania z podejrzanym zawartością parametru snippets (np. zawierające sekwencje przechodzenia przez katalog, takie jak "../" lub próby zapisu poza dozwolonymi katalogami).
   • Dozwolenie tylko na ważne wzory (whitelist) jest bezpieczniejsze niż czarna lista. Reguła, która pozwala tylko na oczekiwane nazwy/znaki snippets, jest najlepsza.
   • Klienci WP‑Firewall: publikujemy i wdrażamy regułę łagodzenia, która automatycznie wykrywa i blokuje tego typu próby wykorzystania.
3. Ogranicz dostęp do punktów końcowych wtyczek, gdzie to możliwe.
   • Jeśli Twoja strona nie wymaga publicznego edytowania punktów końcowych, ogranicz dostęp według IP lub zabezpiecz inną warstwą uwierzytelniania.
   • Wprowadź kontrole uprawnień po stronie serwera: upewnij się, że tylko użytkownicy z odpowiednimi uprawnieniami mogą wywoływać zapisy plików. (To jest zmiana dla dewelopera, a nie tymczasowe rozwiązanie.)
4. Wzmocnij uprawnienia systemu plików
   • Upewnij się, że wp‑content, wtyczki i motywy mają surowe uprawnienia. Serwer WWW/PHP powinien mieć prawo do zapisu tylko w wymaganych katalogach (uploads) i nie w katalogach kodu rdzenia wtyczek, jeśli to możliwe.
   • Typowe wytyczne: pliki 644, katalogi 755. Właściciel/grupa powinny być skonfigurowane tak, aby proces PHP nie mógł nadpisywać plików rdzenia wtyczek, chyba że jest to celowo dozwolone.
5. Skanuj w poszukiwaniu oznak kompromitacji
   • Uruchom skanowanie złośliwego oprogramowania (WP‑Firewall zawiera skaner we wszystkich planach), aby wykryć nowo dodane pliki PHP, zmodyfikowane pliki lub podejrzaną zawartość.
   • Szukaj niedawno zmodyfikowanych plików w katalogach wtyczek i motywów, szczególnie plików z niedawnymi znacznikami czasowymi w oknie ujawnienia.
   • Monitoruj nieoczekiwanych użytkowników administratora, dziwne zaplanowane zadania (cron) lub anomalne połączenia wychodzące.
6. Rotuj dane uwierzytelniające i przeglądaj konta.
   • Wymuś reset hasła dla kont administracyjnych oraz dla wszelkich kont utworzonych krótko przed podejrzaną aktywnością.
   • Cofnij klucze API lub inne sekrety, które mogły zostać ujawnione.
7. Kopia zapasowa i odzyskiwanie
   • Upewnij się, że masz czysty backup sprzed jakiegokolwiek podejrzanego naruszenia. Jeśli wykryjesz infekcję, przywróć z czystego backupu po usunięciu artefaktów atakującego.
   • Zachowaj logi i forensyczny zrzut przed przywróceniem — to pomaga w analizie po incydencie.

Wykrywanie — na co zwrócić uwagę

Wskaźniki wykorzystania (IOC) obejmują, ale nie ograniczają się do:

• Nowo utworzone lub zmodyfikowane pliki w katalogach wtyczek/motywów, które zawierają kod PHP lub z obfuskowaną zawartość.
• Pliki zapisane poza normalnym magazynem wtyczek — np. pliki PHP w przesyłanie/.
• Nieoczekiwane konta użytkowników administratora lub edytora, lub wcześniej nieznane edytory wtyczek.
• Logi dostępu serwera WWW pokazujące żądania POST z podejrzanymi wartościami parametrów do punktów końcowych wtyczek.
• Podejrzane zaplanowane zadania (zdarzenia wp‑cron) lub trwałe opcje w bazie danych z nieoczekiwaną zawartością.
• Aktywność sieciowa wychodząca do nieznanych adresów IP/domen z serwera.

Dzienniki i wskazówki dotyczące wyszukiwania:

• Przeszukaj dzienniki dostępu pod kątem punktów końcowych wtyczek i szukaj żądań, które zawierają nazwę parametru związaną z fragmentami.
• Szukaj nietypowej zawartości w ciałach POST (sekwencje ścieżek, kod base64, długie ciągi).
• Na hostach z systemami integralności plików (tripwire, fsmonitor) szukaj niedawno zmienionych plików wtyczek.

Dlaczego WAF / wirtualne łatanie to krytyczne zabezpieczenie tymczasowe

Wirtualna łatka (reguła WAF) chroni podatne strony, podczas gdy zarządzasz aktualizacjami. Wirtualne łatanie blokuje wzorce eksploatacji na warstwie HTTP, zanim podatny kod zostanie uruchomiony. W przypadku problemów z przechodzeniem przez katalogi i dowolnym zapisem, reguły WAF zazwyczaj:

• Sprawdzają parametry (ładunek GET/POST/JSON) pod kątem znanych złośliwych wzorców (np. tokeny przechodzenia przez ścieżki, nieoczekiwane rozszerzenia plików, bajty null).
• Blokują lub sanitizują żądania od użytkowników, którzy nie powinni wykonywać zapisów plików (np. rola subskrybenta).
• Ograniczają liczbę żądań i blokują podejrzane adresy IP oraz konta użytkowników wykazujące zachowania skanowania lub sondowania.

WP‑Firewall zapewnia zarządzane reguły, które są dostosowane do zachowania WordPressa. Chociaż wirtualna łatka nie jest substytutem poprawki kodu, zmniejsza natychmiastową powierzchnię ataku i zyskuje czas na zaktualizowanie wszystkich instancji.

Lista kontrolna wzmacniania — poza pilnymi działaniami łagodzącymi

Po zastosowaniu natychmiastowych działań łagodzących, postępuj zgodnie z tym średnioterminowym planem wzmacniania:

• Zaktualizuj wszystkie wtyczki, motywy i rdzeń do aktualnych stabilnych wersji.
• Wprowadź zasadę najmniejszych uprawnień dla kont użytkowników; usuń nieużywane konta lub zmniejsz role.
• Ogranicz możliwości edytora wtyczek: upewnij się, że tylko zaufani administratorzy mogą przesyłać lub edytować kod wtyczek/motywów.
• Przenieś katalog przesyłania poza katalog główny serwera lub użyj reguł .htaccess/Nginx, aby zablokować wykonanie w przesyłkach.
• Wyłącz pełny dostęp do zapisu plików w katalogach wtyczek, jeśli twój host wspiera oddzielanie własności plików (np. używając suExec, puli PHP‑FPM na użytkownika).
• Wprowadź uwierzytelnianie dwuskładnikowe (2FA) dla wszystkich uprzywilejowanych kont.
• Zautomatyzowane skany bezpieczeństwa: zaplanowane skany złośliwego oprogramowania i monitorowanie zmian plików.
• Tylko dostęp oparty na kluczu SFTP / SSH; unikaj zwykłego FTP.
• Centralne logowanie i integracja SIEM w celu wykrywania anomalii.

WP‑Firewall — jak chronimy Twoje strony WordPress

W WP‑Firewall zapewniamy warstwowe zabezpieczenia oparte na rzeczywistości hostingu WordPress:

• Zarządzany zapora aplikacji internetowej (WAF): zasady specjalnie dostosowane do wtyczek WordPress i powszechnych wzorców eksploatacji. Dla tej podatności Perfmatters publikujemy i aktualizujemy sygnatury zasad, aby wykrywać podejrzane parametry fragmentów i blokować próby eksploatacji, zanim dotrą do wtyczki.
• Skaner złośliwego oprogramowania: skanuje pliki, porównuje z znanymi czystymi kopiami i szuka wstrzykniętego kodu PHP oraz powłok internetowych.
• Łagodzenie OWASP Top 10: zasady sygnatur i zachowań, które bronią przed powszechnymi słabościami aplikacji internetowych, w tym przejściem do katalogu, niebezpiecznymi bezpośrednimi odniesieniami do obiektów i skryptami między witrynami.
• Zarządzane wirtualne łatanie: gdy zostanie zidentyfikowana luka zero-day lub ujawniona podatność, WP‑Firewall wprowadza zasadę awaryjną w naszych chronionych instalacjach, aby zyskać czas na łatkę.
• Automatyczne usuwanie i powiadomienia (płatne plany): automatyczne usuwanie lub kwarantanna zidentyfikowanego złośliwego oprogramowania oraz priorytetowe powiadamianie administratorów.

Uwagi dotyczące naszego Planu Bezpłatnego i dlaczego ma to znaczenie

Rozumiemy, że właściciele stron i małe firmy często zarządzają wieloma instalacjami WordPress z ograniczonym budżetem. Nasz plan Podstawowy (Bezpłatny) zapewnia podstawową ochronę, abyś nie był narażony podczas koordynowania aktualizacji:

• Zarządzany zapora (WAF) z aktualizacjami zasad awaryjnych;
• Nielimitowana przepustowość, aby środki ochronne nie ograniczały ruchu na stronie;
• Skaner złośliwego oprogramowania do wykrywania podejrzanych plików i modyfikacji;
• Zakres łagodzenia dla klas ryzyka OWASP Top 10.

Jeśli chronisz jakąkolwiek publiczną stronę WordPress, włączenie przynajmniej tej podstawowej ochrony jest rozsądne — dramatycznie zmniejsza to prawdopodobieństwo, że zautomatyzowane skanery eksploatacji odniosą sukces w czasie aktualizacji.

Reakcja na incydent: krok po kroku

Jeśli uważasz, że zostałeś wykorzystany za pośrednictwem tej podatności, postępuj zgodnie z uporządkowaną reakcją na incydent:

1. Izolować
   • Tymczasowo wyłącz stronę lub wprowadź ją w tryb konserwacji, jeśli integralność strony budzi wątpliwości.
   • Jeśli atakujący zainstalował powłokę sieciową lub trwałe tylne drzwi, odizoluj serwer (sieć), aby zapobiec eksfiltracji danych.
2. Zachowaj dowody
   • Zbierz logi dostępu do serwera WWW, logi błędów i migawki bazy danych.
   • Wykonaj kopię forensyczną systemu plików przed jego modyfikacją.
3. Określenie zakresu
   • Określ, które pliki zostały zapisane/zaktualizowane i które konta mogły być używane.
   • Szukaj mechanizmów utrzymywania (zadania cron, opcje w tabeli opcji WP, wtyczki porzucone przez atakującego).
4. Czyszczenie
   • Usuń wstrzyknięte pliki i tylne drzwi. Preferuj przywracanie czystych plików z znanych dobrych kopii zapasowych.
   • Zmień dane uwierzytelniające (użytkownicy administratora WP, panel sterowania hostingu, SFTP, klucze API).
   • Ponownie zainstaluj skompromitowane wtyczki/motywy z oficjalnych źródeł.
5. Środek zaradczy
   • Zaktualizuj Perfmatters do wersji 2.6.0.
   • Zastosuj wzmocnienia hosta, zasady WAF i poprawki uprawnień do plików.
   • Załatw inne luki i przeprowadź pełny audyt bezpieczeństwa.
6. Przywróć i zweryfikuj
   • Przywróć usługę z czystej kopii zapasowej. Zweryfikuj integralność za pomocą sum kontrolnych plików i skanów.
   • Ponownie wprowadź witrynę do produkcji z włączonym monitorowaniem.
7. Przegląd po incydencie
   • Udokumentuj przyczynę, działania, punkty do nauki.
   • Zaktualizuj podręczniki operacyjne i automatyzację, aby przyszła luka była usuwana szybciej.

Zasady wykrywania i monitorowania (przykłady)

Poniżej znajdują się pomysły na nieeksploatowalne, defensywne zasady, które możesz wdrożyć w WAF lub narzędziu do monitorowania serwera. Zostały napisane dla jasności, a nie jako wdrażalne fragmenty kodu.

• Blokada wzorca: blokuj żądania, w których "fragmenty" parametr (POST lub JSON) zawiera sekwencje podwójnych kropek (../) lub zakodowane warianty () gdy używane w kontekście ścieżki pliku.
• Egzekwowanie typu parametru: zezwól tylko na oczekiwane znaki dla identyfikatorów fragmentów (alfanumeryczne, myślniki, podkreślenia).
• Ograniczenie ról: blokuj żądania zapisu z kont z rolą Subskrybenta do punktów końcowych, które wykonują zapisy plików; uruchom dodatkowe kontrole dla operacji zapisu wydawanych przez konta o niskich uprawnieniach.
• Monitorowanie zapisu plików: powiadom, gdy jakikolwiek plik w katalogach wtyczek lub motywów zostanie utworzony lub zmodyfikowany przez proces serwera WWW/PHP.
• Ograniczenie liczby żądań: ogranicz podejrzane powtarzające się próby do tego samego punktu końcowego z tego samego adresu IP.

Pamiętaj: zbyt szerokie zasady mogą zepsuć legalną funkcjonalność; najpierw przetestuj zasady na etapie testowym i zastosuj tryb tylko do logowania, jeśli jest dostępny.

Lista kontrolna komunikacji dla właścicieli stron

• Natychmiast powiadom wewnętrznych interesariuszy oraz zespoły IT/gospodarzy.
• Informuj użytkowników strony tylko wtedy, gdy istnieją dowody na ujawnienie danych związane z luką lub exploitem.
• Jeśli hostujesz dane użytkowników podlegające regulacjom (prawo o ochronie prywatności), skonsultuj się z prawnikiem w sprawie obowiązków ujawnienia.
• Podziel się szczegółami incydentu ze swoim dostawcą hostingu — często mają oni uprzywilejowany dostęp i narzędzia detekcji, które mogą pomóc.

Często zadawane pytania (FAQ)

Q: Mam rejestrację Subskrybenta na mojej stronie; czy to czyni mnie podatnym na atak?
A: Luka wymaga konta Subskrybenta do wykorzystania. Jeśli twoja strona pozwala na otwartą rejestrację i przydziela rolę Subskrybenta, powinieneś założyć ryzyko i podjąć natychmiastowe działania. Włączenie zasad WAF i zastosowanie łatki usuwa lukę.

Q: Moja strona jest za zaporą hosta. Czy jestem bezpieczny?
A: Zapory hosta mogą pomóc, ale rzadko sprawdzają parametry aplikacji w ciałach POST tak, jak robi to WAF. Wirtualne łatanie na poziomie aplikacji jest bardziej skuteczne dla tej klasy luk.

Q: Czy powinienem teraz dezaktywować wtyczkę Perfmatters?
A: Jeśli nie możesz zaktualizować natychmiast, dezaktywacja wtyczki usuwa podatną ścieżkę kodu i jest prostą łagodzeniem. Jednak dezaktywacja może zmienić wydajność lub funkcjonalność strony. Jeśli mocno polegasz na wtyczce, wirtualne łatanie i ograniczenie dostępu mogą być preferowane podczas planowania aktualizacji.

Q: Czy skanowanie strony wystarczy, aby być pewnym, że nie zostałem skompromitowany?
A: Skanowanie to dobry początek, ale nie zawsze jest doskonałe. Połącz kontrole integralności plików, analizę logów i przegląd konfiguracji. Jeśli podejrzewasz zaawansowaną kompromitację, rozważ profesjonalną reakcję na incydenty.

Szybko chroń swoją stronę — zacznij od tej akcji

• Zaktualizuj Perfmatters do wersji 2.6.0 lub nowszej jako swój pierwszy priorytet.
• Jeśli nie możesz zaktualizować od razu, włącz zarządzane zasady WAF WP‑Firewall, aby zablokować próby wykorzystania parametru snippets i podobnych wzorców przechodzenia przez katalogi.
• Przeprowadź pełne skanowanie złośliwego oprogramowania i sprawdź ostatnie zmiany plików. Jeśli znajdziesz jakiekolwiek podejrzane pliki, zachowaj logi i odizoluj stronę, podczas gdy prowadzisz dochodzenie.

Zabezpiecz swoją stronę już dziś — zacznij od darmowego planu WP‑Firewall

Jeśli potrzebujesz szybkiej sieci bezpieczeństwa podczas koordynowania aktualizacji na wielu stronach, wypróbuj podstawowy (bezpłatny) plan WP‑Firewall. Oferuje on podstawową ochronę: zarządzany WAF z aktualizacjami zasad awaryjnych, skaner złośliwego oprogramowania do identyfikacji podejrzanych plików, nielimitowaną przepustowość dla ochrony bez ograniczeń oraz ochronę przed ryzykiem OWASP Top 10. Zacznij teraz i zmniejsz swoje narażenie podczas łatania: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Ulepszanie swojej ochrony — jak nasze plany pomagają

• Bezpłatny (Podstawowy) plan: podstawowe zarządzane zasady zapory, skanowanie złośliwego oprogramowania, łagodzenia OWASP — dobre do natychmiastowej ochrony w sytuacjach awaryjnych.
• Standardowy plan: dodaje automatyczne usuwanie złośliwego oprogramowania oraz ograniczone kontrole czarnej/białej listy IP — przydatne, jeśli potrzebujesz pomocy w usuwaniu zagrożeń.
• Plany Pro/Warstwowe: obejmują miesięczne raporty bezpieczeństwa, automatyczne łatanie wirtualne i usługi zarządzane — zalecane dla firm i agencji prowadzących wiele stron.

Dlaczego powinieneś dbać o terminowe łatanie

Łatanie wirtualne pomaga, ale jest tymczasowe. Poprawki kodu usuwają przyczynę; zasady WAF to środki ochronne. Atakujący w końcu celują w znane podatne oprogramowanie na dużą skalę, a automatyzacja ułatwia masowe kompromitacje. Połączenie szybkiego łatania, ochrony WAF i dobrej higieny operacyjnej to jedyna zrównoważona obrona.

Zakończenie rekomendacji

1. Natychmiast zaktualizuj Perfmatters do 2.6.0.
2. Jeśli nie możesz zaktualizować teraz, włącz ochronę na poziomie aplikacji (WAF) i wzmocnij uprawnienia oraz dostęp.
3. Skanuj w poszukiwaniu kompromitacji i zachowaj logi przed czyszczeniem.
4. Zastosuj długoterminowe wzmocnienie: 2FA, minimalne uprawnienia, monitorowanie integralności plików, zaplanowane łatanie.
5. Rozważ skorzystanie z zarządzanej usługi bezpieczeństwa, jeśli prowadzisz wiele stron lub brakuje ci wewnętrznych zasobów bezpieczeństwa.

Jeśli potrzebujesz pomocy w ocenie narażenia na wielu stronach, włączeniu awaryjnego łatania wirtualnego lub przeprowadzaniu skanów i reakcji na incydenty, nasz zespół w WP‑Firewall jest gotowy do pomocy. Budujemy nasze łagodzenia w oparciu o nowoczesny krajobraz zagrożeń WordPressa, aby zmniejszyć ryzyko bez zakłócania funkcjonalności strony.

Dodatek: Szybka lista kontrolna (kopiuj-wklej)

• Potwierdź wersję Perfmatters na każdej stronie.
• Zaktualizuj do 2.6.0 (lub nowszej) natychmiast, gdzie to możliwe.
• Jeśli nie aktualizujesz natychmiast, włącz/zweryfikuj WAF z zasadami blokującymi przejście przez ścieżki w parametrach fragmentów.
• Uruchom pełne skanowanie złośliwego oprogramowania i wykrywanie zmian w plikach.
• Przejrzyj ostatnie zmiany w katalogach wtyczek/motywów (znaczniki czasowe).
• Zmień dane uwierzytelniające dla kont administratora i hostingu.
• Sprawdź nieznanych użytkowników administratora/edytora i usuń ich.
• Wzmocnij uprawnienia systemu plików i zablokuj wykonanie PHP w katalogach przesyłania.
• Zachowaj logi i kopię zapasową przed jakąkolwiek naprawą.
• Rozważ wsparcie zarządzane, jeśli nie jesteś pewien.

Jeśli potrzebujesz pomocy: nasz zespół może wdrożyć awaryjne wirtualne poprawki w Twoich instalacjach, przeprowadzić skanowanie integralności i doradzić w kwestii kroków naprawczych dostosowanych do Twojego środowiska hostingowego. Zarejestruj się, aby uzyskać natychmiastową ochronę z naszym darmowym planem tutaj: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Jeśli chcesz, możemy:

• zaproponuj sugestię skryptu skanowania, który możesz uruchomić na swoim serwerze, aby wylistować ostatnie zmiany w plikach (bezpieczne, tylko do odczytu);
• pomóż sformułować konserwatywne zasady WAF, które możesz najpierw przetestować w trybie logowania;
• przejrzyj swój proces aktualizacji/poprawek, aby skrócić czas reakcji na przyszłe ujawnienia.

Bądź bezpieczny,
Zespół ds. bezpieczeństwa WP‑Firewall