Data wpisu: 23.12.2025

Zainfekowana strona lub konto FTP i brak reakcji: jakie konsekwencje grożą klientowi

Jeżeli właściciel strony ma wiarygodną informację, że na jego serwerze znajdują się złośliwe pliki (np. webshell w WordPressie, trojan w plikach PHP) i mimo tego nie podejmuje żadnych działań, to ryzykuje nie tylko problemy techniczne, ale też konsekwencje prawne i organizacyjne. Kluczowe jest tu połączenie dwóch elementów: wiedzy o incydencie oraz zaniechania (braku reakcji w rozsądnym czasie).

Dlaczego „wiedza + bezczynność” zmienia sytuację

W praktyce inaczej ocenia się sytuację, gdy strona została zainfekowana bez wiedzy właściciela, a inaczej, gdy właściciel został o tym powiadomiony i nadal utrzymuje środowisko w stanie umożliwiającym nadużycia. Nawet jeśli to nie on wgrał złośliwe pliki, to brak reakcji:

  • zwiększa czas, w którym infrastruktura może być wykorzystywana do ataków lub spamu,
  • powiększa zakres szkód (np. utrata reputacji domeny, możliwy wyciek danych),
  • utrudnia późniejsze dowodzenie, że dochowano należytej staranności.

Najczęstsze skutki techniczne i biznesowe

To zwykle dzieje się najszybciej i najboleśniej, zanim ktokolwiek zacznie rozważać spory prawne:

  • Przejęcie kontroli nad stroną (webshell, ukryty administrator, zadania cron, mu-plugins) i powracające reinfekcje.
  • Wysyłka spamu i phishing z serwera lub przez skrypty na stronie (spadek dostarczalności poczty, blokady).
  • Ostrzeżenia w przeglądarkach i spadek ruchu (oznaczenia „ta strona może być niebezpieczna”, problemy w Google Search Console).
  • Wycieki danych logowania (kradzież haseł do panelu, FTP/SFTP, bazy danych, poczty).
  • Spadek konwersji i utrata zaufania (klienci boją się składać zamówienia, rośnie liczba reklamacji i zwrotów).

Konsekwencje po stronie hostingu i dostawców usług

Wiele firm reaguje automatycznie na nadużycia i nie czeka na wyjaśnienia:

  • Zawieszenie konta, odcięcie ruchu lub kwarantanna plików, jeśli serwer generuje zagrożenie lub nadmierne obciążenie.
  • Blokada wysyłki poczty (limity, blokady SMTP), jeśli z konta idzie spam.
  • Wymuszenie działań naprawczych (np. obowiązek czyszczenia, aktualizacji, zmiany haseł) pod groźbą wypowiedzenia usługi.
  • Problemy z integracjami (bramki płatności, reklamy, systemy mailingowe) z powodu reputacji domeny i zgłoszeń abuse.

Odpowiedzialność cywilna: ryzyko roszczeń, gdy ignoruje się infekcję

W prawie cywilnym istotna jest koncepcja winy i należytej staranności. Jeżeli z infrastruktury klienta wychodzą działania szkodzące innym (np. ataki, spam, phishing), a klient był wcześniej informowany o infekcji i nic nie zrobił, to druga strona może próbować budować roszczenia, wykazując:

  • powstanie szkody,
  • związek przyczynowy (że szkoda ma związek z nadużyciami wychodzącymi z tej infrastruktury),
  • zawinienie w postaci zaniedbania (np. brak reakcji mimo ostrzeżeń).

To nie oznacza, że roszczenia zawsze będą skuteczne, ale „wiedział i nic nie zrobił” istotnie pogarsza pozycję klienta, bo łatwiej zarzucić mu niedbalstwo. Patrz: "Uwaga".

RODO: gdy strona przetwarza dane osobowe

Jeśli strona zbiera lub przetwarza dane osobowe (np. sklep, formularze, konta użytkowników, newsletter), infekcja może oznaczać naruszenie ochrony danych. Wtedy liczy się nie tylko usunięcie wirusa, ale też obowiązki organizacyjne:

  • Ocena ryzyka dla praw i wolności osób, których dane dotyczą.
  • Zgłoszenie naruszenia do organu w przypadkach wymaganych przez przepisy, co do zasady bez zbędnej zwłoki i, gdy to możliwe, nie później niż w 72 godziny od stwierdzenia naruszenia.
  • Powiadomienie osób, których dane dotyczą, jeśli naruszenie może powodować wysokie ryzyko.
  • Dokumentowanie naruszeń i działań naprawczych (rozliczalność).

Zaniechanie działań mimo wiedzy o infekcji może zostać ocenione jako brak „odpowiednich środków technicznych i organizacyjnych” oraz niewywiązanie się z obowiązku należytej reakcji na incydent.

Odpowiedzialność karna: najczęściej po stronie sprawcy, ale klient nie powinien „tolerować” narzędzia ataku

Zwykle odpowiedzialność karna za ataki dotyczy sprawcy (osoby, która je przeprowadza). Natomiast klient, który świadomie utrzymuje webshell lub inne narzędzie umożliwiające nadużycia, ryzykuje, że jego zachowanie zostanie ocenione dużo surowiej niż „bierna ofiara włamania”. Im dłużej trwa tolerowanie infekcji mimo ostrzeżeń, tym trudniej bronić tezy, że klient działał rozsądnie i w dobrej wierze.

Co jest „minimum działań”, które klient powinien wykonać po otrzymaniu informacji o wirusie

Żeby ograniczyć ryzyka (techniczne, biznesowe i prawne), rozsądne minimum to:

  • Odcięcie dostępu atakującego: zmiana haseł (panel hostingu, SFTP/SSH, WordPress, baza danych, poczta), włączenie MFA, przejście z FTP na SFTP/SSH.
  • Usunięcie skutków: przywrócenie WordPress core z czystych źródeł, weryfikacja wtyczek i motywów, kontrola katalogu uploads (PHP tam zwykle jest podejrzane), sprawdzenie crona i mu-plugins.
  • Usunięcie przyczyny: aktualizacje, usunięcie nieużywanych wtyczek i motywów, ograniczenia logowania, WAF, monitor zmian plików.
  • Udokumentowanie reakcji: raport z wykrycia, lista działań, daty i wyniki skanów po czyszczeniu.
  • Jeśli są dane osobowe: ocena, czy doszło do naruszenia ochrony danych i czy potrzebne są zgłoszenia/powiadomienia.

Dlaczego wykonawca powinien wszystko komunikować na piśmie

Jeżeli klient ignoruje problem, wykonawca (administrator, agencja, freelancer) powinien zadbać o ślad dowodowy, bo w razie skarg i incydentów często pojawia się pytanie: kto wiedział i co zrobił. Dobra praktyka to:

  • przekazanie informacji o infekcji mailowo wraz z opisem ryzyk,
  • podanie rekomendowanych działań i proponowanego terminu reakcji,
  • uzyskanie pisemnego potwierdzenia decyzji klienta (np. odroczenie, odmowa),
  • jasne wskazanie, że bez wdrożenia działań nie da się zapewnić bezpieczeństwa.

Podsumowanie

Wiedza o wirusie na stronie lub koncie FTP i brak reakcji to realne ryzyko: blokady hostingu, utrata reputacji, spadek sprzedaży, możliwe obowiązki z RODO, a w skrajnych przypadkach spory o szkody. Najbezpieczniej działać szybko, twardo (czyszczenie + usunięcie przyczyny) i zostawić po sobie dokumentację działań. To zwykle jest tańsze niż gaszenie pożaru po kilku tygodniach bezczynności.

 

Uwaga: 

Jeśli właściciel strony „coś robi”, ale w praktyce robi to nieskutecznie (a infekcja wraca), to z perspektywy odpowiedzialności kluczowe nie jest samo „podjęcie działań”, tylko czy działania były adekwatne i staranne.

Co się zmienia, gdy działania są „zbyt słabe”

W prawie cywilnym liczy się należyta staranność – czyli standard zachowania, jakiego można wymagać w danych okolicznościach.

Jeżeli wirus wraca, to jest mocny argument, że:

  • przyczyna nie została usunięta (np. podatna wtyczka, wyciek haseł, backdoor na serwerze),
  • albo zabezpieczenia są niewystarczające (brak rotacji haseł, brak MFA, dalej FTP, brak twardego odtworzenia plików itp.).

To może być ocenione jako niedbalstwo (wina nieumyślna), a przy szkodzie – otwiera drogę do odpowiedzialności deliktowej. 

Jakie „poza-RODO” ryzyka są realne w takim scenariuszu

1) Odpowiedzialność cywilna (deliktowa), jeśli z jego strony idą szkody

Jeśli z zainfekowanej strony lecą ataki/spam/phishing i ktoś wykaże szkodę oraz związek z zaniedbaniami, to sam fakt, że „próbował”, nie musi go bronić, jeśli próby były pozorne lub nieadekwatne. Podstawą jest art. 415 k.c. (wina + szkoda). 

2) Odpowiedzialność umowna, jeśli ma zobowiązania wobec kogoś (hosting, kontrahenci, klienci)

Jeżeli ma umowę i „utrzymuje usługę/serwis” w sposób nienależyty (bo bezpieczeństwo leży po jego stronie), to wchodzi reżim art. 471 k.c. – niewykonanie lub nienależyte wykonanie zobowiązania. 

To bywa praktyczniejsze niż delikt, bo druga strona idzie prostą ścieżką: „umowa → obowiązek → nienależyte wykonanie → szkoda”.

3) Konsekwencje po stronie hostingu i usług (najczęstsze w realu)

Nawet bez pozwów: powtarzające się infekcje kończą się zwykle blokadami, ograniczeniami, blacklistami poczty, zgłoszeniami abuse. I tu tłumaczenie „czyściłem, ale wraca” często nie ma znaczenia – liczy się efekt: nadal generuje ryzyko.

Czy właściciel może się „wybronić”, że zlecił to komuś?

Częściowo tak, ale to nie jest tarcza absolutna. Jest przepis o powierzeniu czynności i tzw. „winie w wyborze” (art. 429 k.c.) – jeśli powierzył to profesjonaliście, może ograniczać swoją odpowiedzialność za cudzy czyn, ale nadal powinien reagować rozsądnie (np. nie ignorować zaleceń, nie blokować wdrożeń). 

Co w praktyce uznaje się za „działania niewystarczające” (czyli ryzykowne)

Najczęstsze przykłady:

  • usuwanie pojedynczych podejrzanych plików bez odtworzenia WordPress core z czystej paczki,
  • brak rotacji wszystkich haseł i kluczy (WP, DB, hosting, SFTP/SSH, poczta),
  • pozostawienie podatnej wtyczki/motywu,
  • brak weryfikacji uploads/ (PHP w uploads prawie zawsze oznacza kłopot),
  • brak sprawdzenia cronów/mu-plugins/backdoorów,
  • dalej używany zwykły FTP i/lub brak MFA.

Najkrótsza zasada „kiedy robi się naprawdę niebezpiecznie”

Jeśli infekcja wraca drugi/trzeci raz, a właściciel nadal robi tylko „kosmetykę” zamiast:

  • twardego odtworzenia (core + wtyczki z zaufanego źródła),
  • zamknięcia wektora (hasła/MFA/SFTP),
  • znalezienia przyczyny,

to coraz łatwiej postawić tezę: to nie jest „incydent”, tylko utrzymywanie niebezpiecznego stanu mimo wiedzy.

 

Źródła

  • https://uodo.gov.pl/pl/525/2584 (UODO: termin i zasady zgłaszania naruszeń)
  • https://uodo.gov.pl/pl/138/3561 (UODO: poradnik dotyczący naruszeń ochrony danych osobowych)
  • https://isap.sejm.gov.pl/isap.nsf/download.xsp/WDU19640160093/U/D19640093Lj.pdf (Kodeks cywilny, tekst jednolity)
  • https://isap.sejm.gov.pl/isap.nsf/download.xsp/WDU19970880553/U/D19970553Lj.pdf (Kodeks karny, tekst jednolity)
  • https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A32016R0679 (RODO/GDPR: Rozporządzenie (UE) 2016/679, tekst w PDF)
  • https://support.google.com/webmasters/answer/9044101?hl=en (Google Search Console: raport „Security issues”)

Autor wpisu:
Grzegorz Wiśniewski – ekspert z 25-letnim doświadczeniem w marketingu, IT , biznesie.CEO Soluma Group, CEO Soluma Interactive, red. naczelny Mindly.pl

Sprawdź nas!

Sprawdź naszych specjalistów w praktycznym działaniu. Zobacz co możemy zrobić dla Twojej firmy - przejrzyj ofertę lub skorzystaj z bezpłatnej konsultacji.

Darmowa konsultacjaZobacz cennik

Stosujemy pliki cookies. Jeśli nie blokujesz tych plików (samodzielnie przez ustawienia przeglądarki), to zgadzasz się na ich użycie oraz zapisanie w pamięci urządzenia. Zobacz politykę cookies.
Przewiń do góry