Nazwa wtyczki	Piotnet Addons dla Elementor Pro
Rodzaj podatności	Dowolne przesyłanie plików
Numer CVE	CVE-2026-4885
Pilność	Krytyczny
Data publikacji CVE	2026-05-21
Adres URL źródła	CVE-2026-4885

Pilne: CVE-2026-4885 — Nieautoryzowane przesyłanie dowolnych plików w Piotnet Addons dla Elementor Pro (≤ 7.1.70) — Co właściciele stron muszą zrobić teraz

Streszczenie: Wysokosekwencyjna luka (CVE-2026-4885) została opublikowana dla wtyczki Piotnet Addons dla Elementor Pro w wersjach do 7.1.70. Umożliwia ona nieautoryzowanym atakującym przesyłanie dowolnych plików na dotknięte strony. Możliwość przesyłania plików bez autoryzacji często prowadzi do instalacji webshelli i pełnego przejęcia strony. Niniejsze ostrzeżenie wyjaśnia zagrożenie w prostych słowach, obejmuje natychmiastowe środki zaradcze, które możesz zastosować (w tym zasady WAF i wzmocnienie konfiguracji), dostarcza instrukcje wykrywania i czyszczenia oraz daje wskazówki dotyczące bezpiecznego rozwoju dla integratorów wtyczek i autorów motywów.

Ważny: Jeśli wtyczka jest zainstalowana i aktywna na Twojej stronie i nie możesz natychmiast zastosować oficjalnej poprawki, postępuj zgodnie z poniższymi natychmiastowymi krokami zaradczymi. Traktuj wszystkie strony z podatną wtyczką jako wysokie ryzyko, aż do pełnego usunięcia i weryfikacji czystości.

---

Czym jest luka (jasno i prosto)

• Zgłoszono lukę w Piotnet Addons dla Elementor Pro, która dotyczy wersji ≤ 7.1.70.
• Klasyfikacja: Nieautoryzowane przesyłanie dowolnych plików (CVE-2026-4885).
• Waga: Wysoka (CVSS 10 zgłoszone przez początkowe ujawnienie).
• Co to oznacza: Atakujący nie musi być zalogowany na Twojej stronie, aby wysyłać żądania, które skutkują tworzeniem plików na Twoim serwerze WWW. Jeśli atakujący może umieścić plik PHP (lub inny plik wykonywalny) w lokalizacji dostępnej przez sieć, mogą uruchomić dowolny kod na Twoim serwerze, zainstalować tylne drzwi, ukraść dane lub przejść do innych systemów.

To jedna z bardziej niebezpiecznych klas luk, ponieważ przesyłanie plików jest bezpośrednią drogą do zdalnego wykonania kodu (RCE), gdy przesyłki nie są odpowiednio weryfikowane, oczyszczane i przechowywane.

---

Dlaczego to ma znaczenie dla Twojej strony WordPress

• Wiele stron internetowych korzysta z Elementor i wtyczek dodatków do tworzenia formularzy, przesyłania zasobów i akceptowania plików od odwiedzających. Luka w szeroko stosowanym dodatku znacznie zwiększa powierzchnię ataku.
• Luka jest nieautoryzowana — aktorzy zagrożeń mogą skanować sieć w poszukiwaniu stron z podatną wersją i próbować masowo wykorzystywać.
• Udane wykorzystanie często prowadzi do trwałych tylnych drzwi i szybkiego ruchu bocznego: zautomatyzowane kampanie będą próbować ponownie wykorzystać te same webshelli na tysiącach skompromitowanych stron.
• Nawet strony o skromnym ruchu lub niskiej widoczności są celem — atakujący używają zautomatyzowanych narzędzi do znajdowania celów według wersji wtyczki.

---

Typowe cele atakującego po wykorzystaniu dowolnego przesyłania

1. Przesłać webshell (np. plik PHP, który umożliwia zdalne wykonanie poleceń).
2. Zwiększyć dostęp, tworząc użytkowników administratorów lub zbierając dane uwierzytelniające bazy danych.
3. Wdrożyć spam/iniekcję treści w celu nadużycia SEO.
4. Hostować strony phishingowe lub pobierania złośliwego oprogramowania.
5. Wydobywaj kryptowaluty lub przełącz się na inne systemy w środowisku hostingowym.
6. Utrzymuj trwałość za pomocą zaplanowanych zadań, modyfikacji motywów/wtyczek lub nowych kont administratorów.

Ponieważ luka jest nieautoryzowana, automatyzacja oznacza, że szybkie i szerokie wykorzystanie jest prawdopodobne.

---

Wskaźniki kompromitacji (IoCs) i na co zwracać uwagę

Kiedy podejrzewasz wykorzystanie, priorytetowo traktuj kontrole logów i systemu plików. Szukaj następujących oznak:

• Nowe lub niedawno zmodyfikowane pliki PHP, PHTML, PHT lub pliki o podejrzanych nazwach w wp-content/przesyłanie i podfolderach. Napastnicy często ukrywają pliki w folderach rocznych/miesięcznych lub tworzą brzmiące niewinnie katalogi.
• Pliki z podwójnymi rozszerzeniami (np., image.php.jpg) lub nazwy plików zawierające słowa kluczowe, takie jak powłoka, cmd, exec, wp-includes lub długie losowe nazwy z osadzonymi znacznikami otwierającymi PHP.
• Żądania w logach dostępu z multipart/form-data POST do punktów końcowych wtyczek lub nietypowe żądania POST do stron, które wcześniej były używane tylko przez wtyczkę (szukaj powtarzających się POST z tego samego IP).
• Żądania z niezwykle dużą liczbą przesyłek z jednego IP lub user-agenta, lub przesyłki z podejrzanymi user-agentami (automatyczne skanery).
• Obecność treści zakodowanej w base64 lub z obfuskowanym kodem wewnątrz przesłanych plików (szukaj base64_decode, ocena, str_rot13, gzuncompressitp.).
• Nagłych zmian w plikach rdzeniowych (indeks.php, wp-config.php) lub w plikach motywów; nowi użytkownicy administratorzy; zaplanowane zadania (cron), które nie powinny być obecne.
• Połączenia wychodzące do nieznanych adresów IP lub domen pochodzące z procesów PHP.

Przydatne szybkie kontrole:

• WP-CLI: wp media list --format=csv --fields=ID,filename,date,post_id | tail -n 50 aby przeglądać ostatnie przesyłki multimedialne.
• Wyszukiwanie w systemie plików: find wp-content/uploads -type f -mtime -7 -print (pliki zmodyfikowane w ciągu ostatnich 7 dni).
• Szukaj tagów PHP w przesyłanych plikach: grep -R --line-number "<?php" wp-content/uploads | head -n 50

Jeśli znajdziesz podejrzane pliki, traktuj stronę jako skompromitowaną i odizoluj ją w celu oczyszczenia.

---

Natychmiastowe działania dla właścicieli witryn (pierwsze 24 godziny)

1. Potwierdź wersję wtyczki. Jeśli zainstalowana jest wtyczka Piotnet Addons For Elementor Pro i wersja ≤ 7.1.70, uznaj, że jesteś w bezpośrednim ryzyku.
2. Jeśli dostępna jest poprawiona wersja wtyczki od dostawcy, zaktualizuj ją natychmiast. Jeśli nie ma oficjalnej poprawki dla twojej wersji, przejdź do innych działań łagodzących poniżej.
3. Zastosuj tymczasowe łagodzenie:
   • Wyłącz wtyczkę (preferowane), dopóki nie zostanie poprawiona. Jeśli wyłączenie nie jest możliwe natychmiast, ponieważ łamie krytyczną funkcjonalność, zastosuj zasady WAF, aby zablokować wykorzystanie (szczegóły poniżej).
   • Jeśli możesz tymczasowo wprowadzić stronę w tryb konserwacji, zrób to podczas badania.
4. Zablokuj podatne punkty końcowe przesyłania na krawędzi aplikacji webowej (WAF / serwer www). Odrzuć lub 403 wszelkie nieautoryzowane POST-y do punktów końcowych używanych przez rutyny przesyłania Piotnet Addons (użyj blokowania opartego na wzorach; przykładowe zasady zostaną podane później).
5. Zablokuj bezpośrednie wykonywanie PHP w katalogach przesyłania (zobacz sugestie .htaccess / NGINX poniżej).
6. Przeskanuj stronę (skaner złośliwego oprogramowania, kontrole integralności plików) i sprawdź podejrzane pliki lub nowych użytkowników administratora. Izoluj, a jeśli jest skompromitowana, przywróć z czystej kopii zapasowej utworzonej przed podejrzanym naruszeniem.
7. Zmień hasła i klucze dla kont administratorów, poświadczeń bazy danych oraz wszelkich powiązanych poświadczeń API, jeśli podejrzewasz naruszenie.
8. Powiadom swojego dostawcę hostingu, jeśli podejrzewasz aktywne naruszenie — mogą pomóc w izolacji konta i skanowaniu.

Te kroki są priorytetowe: wyłączenie podatnej wtyczki i blokowanie obsługi przesyłania na poziomie WAF zapewni najsilniejszą natychmiastową ochronę.

---

Jak zapora aplikacji webowej (WAF) / wirtualna poprawka może pomóc

Prawidłowo skonfigurowany WAF może blokować próby wykorzystania, zanim dotrą do strony — jest to krytyczne, gdy nie ma jeszcze dostępnej oficjalnej poprawki lub gdy nie możesz zaktualizować natychmiast (kompatybilność, staging, dostosowania).

Zalecane działania WAF:

• Utwórz zasady blokujące nieautoryzowane żądania POST do punktów końcowych przesyłania wtyczki (odrzuć według ścieżki URI, parametrów zapytania lub wzorów ciała żądania).
• Wymuś białą listę typów plików: zezwól tylko na bezpieczne rozszerzenia do przesyłania (np. obrazy: .jpg, .jpeg, .png, .gif) i zablokuj PHP oraz inne wykonywalne rozszerzenia.
• Wykryj i zablokuj przesyłania zawierające kod PHP lub typowe sygnatury webshelli (ciągi takie jak <?php, oceniać(, dekodowanie_base64().
• Zablokuj żądania, w których nazwa pliku zawiera podejrzane znaki lub podwójne rozszerzenia.
• Ogranicz liczbę powtarzających się prób przesyłania i zablokuj adresy IP, które wysyłają wiele żądań przesyłania w krótkim czasie.

Poniżej znajdują się praktyczne zasady, które możesz dostosować. Najpierw przetestuj w trybie wykrywania, aby uniknąć fałszywych pozytywów i dostosować do swojego środowiska.

---

Przykładowe zasady WAF / serwera (przykłady — przetestuj przed użyciem)

Uwaga: To są przykładowe sygnatury i zasady serwera. Dostosuj ścieżki, URI i wzorce, aby pasowały do twojego środowiska. Zawsze najpierw testuj w stagingu.

Przykładowa zasada ModSecurity do blokowania POST-ów do wspólnych obsługiwaczy przesyłania (dostosuj ścieżkę punktu końcowego wtyczki w razie potrzeby):

# Blokuj podejrzane nieautoryzowane przesyłania do obsługiwaczy przesyłania Piotnet"

Ogólna zasada ModSecurity do blokowania wszelkich przesyłek zawierających tagi PHP:

# Blokuj przesyłaną zawartość zawierającą tagi PHP (multipart/form-data)"

Konfiguracja Nginx do zabraniania wykonywania plików PHP w przesyłkach:

location ~* /wp-content/uploads/.*\.(php|phtml|php5|php7)$ {

Apache/.htaccess do zapobiegania wykonywaniu w przesyłkach:

# Umieść to w wp-content/uploads/.htaccess

Zasada WAF do blokowania nazw plików zawierających Plik .php lub podejrzane podwójne rozszerzenia:

SecRule ARGS_NAMES|ARGS "@rx \.php$|\.php\." "phase:2,deny,id:1001003,msg:'Zablokowano nazwę pliku zawierającą .php',t:none"

Jeszcze raz: dostosuj te zasady do swojego serwera i dokładnych punktów końcowych przesyłania wtyczki. Zacznij w trybie monitorowania/rejestrowania, aby zmierzyć fałszywe pozytywy. Jeśli korzystasz z zarządzanego WAF, poproś dostawcę o zastosowanie dostosowanej wirtualnej łatki.

---

Rekomendacje dotyczące wzmocnienia zabezpieczeń dla stron WordPress

Nawet poza blokowaniem tej konkretnej luki, stosuj te praktyki wzmacniające:

• Zabroń wykonywania PHP w wp-content/uploads/ poprzez konfigurację serwera WWW.
• Ustaw bezpieczne uprawnienia do plików: zazwyczaj 644 dla plików i 755 dla katalogów. Unikaj 777.
• Utrzymuj rdzeń WordPressa, motywy i wtyczki w aktualnej wersji. Najpierw uruchom aktualizacje w kontrolowanym środowisku stagingowym.
• Usuń lub dezaktywuj wtyczki/motywy, których nie używasz.
• Używaj silnych, unikalnych haseł i wymuszaj 2FA dla kont z dostępem administracyjnym.
• Ogranicz możliwości wtyczek/użytkowników: nie przyznawaj dostępu na poziomie administratora użytkownikom lub skryptom, które go nie potrzebują.
• Używaj monitorowania integralności plików (FIM), aby wykrywać zmiany w rdzeniu WordPressa i plikach motywów.
• Regularnie twórz kopie zapasowe plików i bazy danych w lokalizacji poza serwerem i testuj przywracanie.
• Monitoruj logi pod kątem anomalii i skonfiguruj powiadomienia dla podejrzanych wzorców.

---

Lista kontrolna wykrywania i dochodzenia (praktyczne kroki)

1. Potwierdź wersję wtyczki: WP Admin > Wtyczki lub za pomocą WP-CLI: wp lista wtyczek --format=json
2. Sprawdź ostatnie przesyłania: find wp-content/uploads -type f -mtime -14 -ls
3. Szukaj tagów PHP w przesyłanych plikach: grep -R --line-number "<?php" wp-content/uploads | tee suspicious_uploads.txt
4. Sprawdź logi dostępu pod kątem podejrzanych POSTów: grep "POST" /var/log/nginx/access.log | grep -i "upload" | tail -n 200
5. Sprawdź nowe konta administratorów: wp user list --role=administrator
6. Szukaj cech webshella: pliki z zafałszowaną zawartością, ocena, base64_decode, gzinflate, system(, shell_exec(.
7. Użyj swojego skanera złośliwego oprogramowania, aby przeprowadzić pełne skanowanie witryny; następnie ręcznie zweryfikuj wszelkie trafienia.
8. Jeśli potwierdzisz kompromitację, wyłącz witrynę (tryb konserwacji), zbierz logi do osi czasu kryminalistycznej i zaplanuj przywrócenie z czystej kopii zapasowej lub profesjonalnego czyszczenia.

---

Kroki czyszczenia i odzyskiwania, jeśli witryna została skompromitowana

• Izoluj środowisko: wyłącz dostęp publiczny, jeśli to możliwe, podczas czyszczenia.
• Zrób zrzut pliku i bazy danych do celów śledczych (nie modyfikuj; zachowaj dowody).
• Zidentyfikuj i usuń pliki backdoor oraz wszelkich nieautoryzowanych użytkowników admina lub zaplanowane zadania.
• Zainstaluj ponownie rdzeń WordPressa, motywy i wtyczki z zaufanych źródeł i zweryfikuj sumy kontrolne.
• Zmień wszystkie dane uwierzytelniające: admin WordPressa, FTP/SFTP, baza danych, panel sterowania hostingu, klucze API i wszelkie inne tajne informacje.
• Przywróć z czystej kopii zapasowej, jeśli infekcja jest rozległa lub jeśli nie możesz pewnie usunąć wszystkich backdoorów.
• Przeskanuj ponownie po oczyszczeniu i przeprowadź test penetracyjny w celu wykrycia pozostałych luk.
• Rozważ skorzystanie z profesjonalnej usługi reagowania na incydenty, jeśli kompromitacja wykazuje oznaki głębokiej intruzji lub ruchu bocznego.

---

Wskazówki dla deweloperów: jak zabezpieczyć funkcje przesyłania.

Jeśli jesteś deweloperem wtyczek lub motywów odpowiedzialnym za funkcjonalność przesyłania, stosuj te praktyki bezpiecznego rozwoju:

• Wymagaj uwierzytelnienia i sprawdzania uprawnień dla wszystkich punktów końcowych przesyłania (zweryfikuj uprawnienia użytkownika, np., current_user_can('upload_files')).
• Wprowadź ochronę CSRF (nonce) dla wszelkich działań przesyłania.
• Waliduj rozszerzenie pliku ORAZ typ MIME po stronie serwera. Nie polegaj na sprawdzeniach po stronie klienta.
• Sprawdź zawartość przesłanego pliku pod kątem osadzonego kodu wykonywalnego (np., <?php) i odrzuć go.
• Przechowuj przesłane pliki poza katalogiem głównym, gdy to możliwe, lub na osobnej domenie/subdomenie, która nie wykonuje skryptów po stronie serwera.
• Generuj bezpieczne, losowe nazwy plików; unikaj bezpośredniego używania nazw plików dostarczonych przez użytkowników.
• Ogranicz dozwolone typy plików za pomocą ścisłych białych list (np. tylko obrazy tam, gdzie oczekiwane są obrazy).
• Wprowadź limity rozmiaru plików i limity szybkości, aby zminimalizować nadużycia.
• Rejestruj aktywność przesyłania, w tym IP, agenta użytkownika, nazwę pliku i znacznik czasu, i monitoruj anomalie.
• Regularne przeglądy kodu pod kątem bezpieczeństwa i korzystanie z narzędzi do analizy statycznej.

Te środki zmniejszają ryzyko i ograniczają wpływ, jeśli jedna warstwa zawiedzie.

---

Przykłady wzmocnienia dla właścicieli stron i administratorów systemów

1. Zapobiegaj wykonaniu PHP w przesyłkach (Apache .htaccess):

# wp-content/uploads/.htaccess

2. Nginx: wyłącz przetwarzanie PHP w przesyłach

location /wp-content/uploads/ {

3. Przydatne polecenia WP-CLI do szybkiej inspekcji

# Lista wtyczek i wersji

---

Dlaczego powinieneś traktować każdą stronę z podatną wtyczką jako priorytet wysokiego poziomu

• Zautomatyzowane skanery exploitów mogą znaleźć i zaatakować strony w ciągu kilku minut po ujawnieniu publicznym.
• Nieautoryzowany oznacza, że nie jest wymagane żadne łamanie haseł ani kompromitacja danych uwierzytelniających.
• Wiele hostów korzysta ze wspólnej infrastruktury, co zwiększa ryzyko, jeśli atakujący mogą przejść z jednego skompromitowanego konta.
• Nawet niekrytyczne strony mogą być monetyzowane przez atakujących na spam, phishing, kopanie kryptowalut lub infrastrukturę do dalszych ataków.

Gdy pojawia się problem z przesyłaniem plików o wysokim poziomie zagrożenia bez autoryzacji, szybka akcja zamyka okno możliwości, na którym polegają atakujący.

---

Praktyczny plan, który możesz wdrożyć dzisiaj po południu

1. Sprawdź wersję wtyczki. Jeśli ≤ 7.1.70, kontynuuj.
2. Jeśli to możliwe, zaktualizuj wtyczkę z zaufanego źródła. Jeśli brak aktualizacji, dezaktywuj wtyczkę.
3. Włącz tryb konserwacji i przeprowadź pełne skanowanie złośliwego oprogramowania.
4. Zastosuj zasady WAF, aby zablokować punkty końcowe przesyłania i sprawdź logi pod kątem wcześniejszych prób POST.
5. Szukaj wp-content/przesyłanie dla plików PHP lub podejrzanych; izoluj i usuń potwierdzone webshale.
6. Rotuj hasła i klucze.
7. Po oczyszczeniu, monitoruj uważnie przez co najmniej 14 dni w poszukiwaniu ponownego pojawienia się oznak.

Jeśli zarządzasz wieloma stronami, priorytetowo traktuj te z formularzami publicznymi i funkcjami przesyłania plików.

---

Dla dostawców hostingu i agencji (lista kontrolna działań)

• Wdróż zasady wirtualnego łatania na krawędzi dla wszystkich hostowanych stron korzystających z podatnego wtyczki.
• Powiadom klientów o jasnym przewodniku naprawczym i zalecanym harmonogramie.
• Oferuj wsparcie w oczyszczaniu i skanowanie potencjalnie skompromitowanych kont.
• Upewnij się, że klienci mają łatwe opcje wprowadzenia stron w tryb konserwacji, aktualizacji wtyczek oraz uzyskania kopii zapasowych/przywracania.

---

Zarejestruj się w WP‑Firewall Basic (Darmowe): Natychmiastowa ochrona dla każdej strony WordPress

Ochrona Twojej strony przed aktywnymi próbami wykorzystania zaczyna się od prawidłowo skonfigurowanej zapory i skanowania złośliwego oprogramowania. Plan WP‑Firewall Basic (Darmowy) zapewnia podstawową ochronę dla stron WordPress — w tym zarządzaną zaporę, szerokie pokrycie WAF, nieograniczoną przepustowość, automatyczne skanowanie złośliwego oprogramowania oraz łagodzenie ryzyk OWASP Top 10. Jeśli chcesz natychmiastowej, ciągłej ochrony podczas stosowania powyższych działań ręcznych, wypróbuj teraz plan Basic WP‑Firewall: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Dlaczego plan Basic jest odpowiedni w tej chwili:

• Zarządzane zasady WAF do szybkiego wirtualnego łatania znanych luk
• Ciągłe skanowanie złośliwego oprogramowania w celu wykrywania wskaźników kompromitacji
• Ochrona przed nieograniczoną przepustowością, aby opierać się automatycznym atakom i masowemu skanowaniu
• Brak kosztów za plan podstawowy, dzięki czemu możesz szybko dodać warstwę ochrony podczas bezpiecznej aktualizacji wtyczek

Zacznij od darmowej ochrony Basic i zaktualizuj później, jeśli potrzebujesz automatycznej naprawy i wirtualnego łatania na dużą skalę.

---

Długoterminowa prewencja: polityki i automatyzacja, które powinieneś wdrożyć

• Wdróż automatyczne zarządzanie łatkami i monitorowanie wersji wtyczek w całej flocie.
• Użyj etapu wdrożenia: testuj aktualizacje w środowisku testowym przed produkcją.
• Wprowadź zasady minimalnych uprawnień dla użytkowników, usług i interfejsów API.
• Zautomatyzuj codzienne lub cotygodniowe skanowanie złośliwego oprogramowania i monitorowanie integralności plików.
• Utrzymuj udokumentowany plan reakcji na incydenty, w tym niezawodne kopie zapasowe i przetestowany proces przywracania.
• Subskrybuj zaufane kanały doradcze dotyczące bezpieczeństwa i dodaj warstwę wirtualnego łatania (WAF) dla krytycznych luk w zabezpieczeniach.

---

Ostateczne przemyślenia zespołu reakcji na incydenty WP‑Firewall

CVE-2026-4885 przypomina, że funkcje akceptujące przesyłanie plików są szczególnie wrażliwe i muszą być budowane i wdrażane z wieloma warstwami walidacji i ochrony. Luki w zabezpieczeniach związane z nieautoryzowanym przesyłaniem plików są często automatyzowane przez aktorów zagrożeń i mogą powodować szybkie, szerokie kompromitacje.

Jeśli Twoja strona korzysta z Piotnet Addons For Elementor Pro w wersji 7.1.70 lub starszej, traktuj to jako incydent o wysokim priorytecie: zaktualizuj natychmiast, jeśli dostawca opublikuje łatkę, lub zastosuj opisane tutaj środki zaradcze — wyłącz wtyczkę, wzmocnij katalogi przesyłania i wdrażaj zasady WAF, aby blokować złośliwe żądania. Po usunięciu zagrożenia, dokładnie przeskanuj, zmień dane uwierzytelniające i monitoruj ponowne infekcje.

Jeśli potrzebujesz pomocy w wdrażaniu zasad WAF lub uzyskaniu zarządzanego zapory przed swoją stroną WordPress, WP‑Firewall oferuje darmowy plan podstawowy, który można szybko włączyć, aby zapewnić natychmiastową warstwę ochrony podczas usuwania i przywracania wszelkich dotkniętych stron: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Bądź bezpieczny. Jeśli potrzebujesz pomocy w dochodzeniu, łagodzeniu lub sprzątaniu, nasi inżynierowie ds. bezpieczeństwa są dostępni, aby pomóc Ci przejść przez kroki i zweryfikować Twoje środowisko.

— Zespół ds. bezpieczeństwa WP‑Firewall

---

Zasoby i szybkie odniesienia

• Odniesienie do luki: CVE-2026-4885 (publiczna porada)
• Wspólna lista kontrolna sprzątania: migawka kopii zapasowej, skanowanie, usunięcie webshelli, zmiana danych uwierzytelniających, przywrócenie z czystej kopii zapasowej, jeśli to konieczne

(Koniec powiadomienia)