Krótko: Jeśli podejrzewają Państwo, że serwer został zhakowany przez PHP2Shell, proszę zgłosić się teraz. Czy są Państwo dotknięci? Proszę zadzwonić. Pomożemy. Od pierwszej wiadomości przejmujemy powstrzymanie incydentu, zabezpieczamy ślady, zamykamy lukę, usuwamy złośliwy kod i dokumentujemy incydent aż do jego zakończenia.
Teraz niczego nie usuwać i niczego nie instalować od nowa. Usunięte pliki i nadpisane logi to ślady, po których widać, czy i jak ktoś się włamał. W razie potrzeby proszę odłączyć serwer od sieci, ale pozostawić go bez zmian. Zgłoś awarię, powiemy Państwu, jaki jest następny krok.
Czy są Państwo dotknięci? Oznaki, że PHP2Shell został już wykorzystany
PHP2Shell to nazwa dwóch krytycznych luk w samym PHP, przez które atakujący mogą bez logowania zdalnie wykonać złośliwy kod. Jak dotąd nie ma jednoznacznego odcisku palca. Dlatego liczy się to, co robi serwer, a nie to, co znajdzie skaner. Wskazówki na włamanie to:
- Procesy serwera WWW lub PHP-FPM uruchamiające powłokę, taką jak
shlubbash. To silny sygnał ostrzegawczy. - Nowe lub zmienione pliki PHP w folderach uploadu, pamięci podręcznej lub plików tymczasowych, których nikt nie utworzył.
- Zadania cron, usługi lub klucze SSH, których Państwo nie znają.
- Połączenia wychodzące do nieznanych celów, nagle duże obciążenie lub nietypowy ruch.
- Żądania w logach od 17.10.2026, szczególnie podejrzane uploady i żądania sesji przed wgraniem poprawki.
- Komunikaty od hostingodawcy, przeglądarki lub wyszukiwarki o spamie, złośliwym oprogramowaniu lub przekierowaniach.
Więcej na ten temat znajdą Państwo w artykule Czy już doszło do naruszenia?. Brak jakichkolwiek oznak nie dowodzi, że serwer jest czysty. Oznacza tylko, że dotąd nic nie zwróciło uwagi.
Co należy zrobić teraz
- Niczego nie zmieniać. Nie usuwać plików, nie przywracać kopii zapasowej, nie instalować od nowa, zanim wszystko nie zostanie zabezpieczone.
- Zabezpieczyć logi. Proszę poprosić hostingodawcę lub dział IT, aby nie nadpisywali dzienników dostępu, błędów i systemowych. Prasa branżowa zaleca przechowywanie logów od 20.10.2026.
- Zdecydować o dostępności. Jeśli dane mogą wypływać lub zagrożeni mogą być odwiedzający, proszę wyłączyć stronę z sieci lub włączyć tryb konserwacji.
- Zebrać dostępy. Proszę zanotować, kto ma dostęp do serwera, panelu, CMS i bazy danych. Hasła zmieniają Państwo dopiero po uzgodnieniu i z czystego urządzenia.
- Poinformować osoby. Zarząd, inspektora ochrony danych, a przy istniejącej polisie ubezpieczyciela.
- Zadzwonić lub napisać do nas. Im wcześniej poznamy sytuację, tym więcej da się udokumentować.
Jak PHP SOS pomaga w praktyce?
Pracujemy zdalnie, bez dojazdu, w całych Niemczech i w Europie.
- Ocena sytuacji: Wyjaśniamy, jakie systemy działają, jaki tryb pracy PHP jest używany, co zwróciło uwagę i jakie dane mogły zostać dotknięte.
- Zabezpieczenie i zamknięcie: Zabezpieczamy pliki, bazę danych i logi oraz ustalamy stan przed każdą zmianą. Następnie zamykamy lukę poprawką lub, jeśli nie jest ona jeszcze możliwa, środkami przejściowymi i restartujemy wszystkie procesy PHP.
- Sprawdzenie i oczyszczenie: Szukamy webshelli, tylnych drzwi, zadań cron i obcych dostępów i usuwamy je albo odbudowujemy stan z zaufanych źródeł. Sposób postępowania opisuje strona Usuwanie malware i webshelli.
- Wzmocnienie i raport: Zmieniamy dotknięte sekrety, uzupełniamy środki ochrony i dostarczamy raport, który oddziela to, co udowodnione, od tego, co prawdopodobne, i od tego, co nieznane.
Jeśli incydent wykracza poza jeden serwer, przechodzimy do uporządkowanej reakcji na incydenty (Incident Response). Jeśli potrzebne są dowody, które wytrzymają przed sądem, angażujemy informatykę śledczą.
Dlaczego sama poprawka po ataku nie wystarcza
Luki leżą w interpreterze PHP, a nie w CMS. Projekt PHP opublikował 21.10.2026 wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Kto po tym zaktualizował system i zrestartował wszystkie procesy robocze, jest chroniony przed nowymi atakami tą drogą. To, co atakujący zdążył wcześniej umieścić, jednak pozostaje: webshell, dodatkowe konto, zaplanowane zadanie. Właśnie dlatego dni między 17 a 21.10. są szczególnie ważne.
Dochodzi druga kwestia: webshell jest często dopiero pierwszym krokiem. Kto mógł wykonywać kod na serwerze WWW, mógł też odczytywać pliki konfiguracyjne i przejmować z nich dostępy do bazy danych, poczty i API. Te sekrety trzeba wymienić, inaczej drzwi pozostają otwarte, mimo że PHP jest załatane. Jak sensownie sprawdzać pliki i czasy zmian, opisuje poradnik o rozpoznawaniu webshelli.
Obowiązek zgłoszenia i dokumentacja
Jeżeli mogły zostać dotknięte dane osobowe, może pojawić się obowiązek zgłoszenia do organu nadzorczego w ciągu 72 godzin. Termin biegnie od uzyskania wiedzy, a nie od zakończenia dochodzenia. To, czy Państwa przypadek podlega zgłoszeniu, rozstrzyga inspektor ochrony danych lub prawnik; nie udzielamy porad prawnych. Nasza dokumentacja dostarcza do tego podstawy. Więcej o terminie znajdą Państwo w artykule Obowiązek zgłoszenia w 72 godziny według RODO, a kolejne kroki w liście kontrolnej po włamaniu.
Co warto nam przesłać
- Opis tego, co zwróciło uwagę, od kiedy i kto to zauważył
- Rodzaj serwera: własny serwer, serwer zarządzany lub pakiet hostingowy, a także hostingodawca
- Wynik polecenia
php -voraz, jeśli jest znany, tryb pracy (PHP-FPM, mod_php, LiteSpeed) - Czas aktualizacji PHP, jeśli została już wgrana
- Dostęp do serwera lub zgoda na rozmowę z hostingodawcą
- Osoba kontaktowa uprawniona do decyzji o wyłączeniu i restartach
Dlaczego PHP SOS
Pracujemy w standardzie Made in Germany i od ponad 25 lat specjalizujemy się w bezpieczeństwie IT wraz z naszą siecią partnerów złożoną z ekspertów od cyberbezpieczeństwa. Mają Państwo jedną osobę kontaktową, która towarzyszy od pierwszej wiadomości do zakończenia sprawy. Wszystko, co robimy, jest dokumentowane, aby mogli Państwo to wykazać wobec zarządu, ubezpieczyciela i urzędów. Nie obiecujemy niczego, czego nikt nie może dotrzymać: jeśli brakuje logów, mówimy to otwarcie i wskazujemy, co jest udowodnione, a co pozostaje przypuszczeniem.
Czy są Państwo dotknięci? Proszę zadzwonić. Pomożemy.
Proszę nie czekać, aż podejrzenie stanie się pewnością. Proszę zadzwonić lub napisać na WhatsApp. Przejmujemy sprawę od pierwszej wiadomości i zostajemy przy niej, aż incydent zostanie zakończony i udokumentowany. Zgłoś awarię teraz.
Częste pytania
Czy wystarczy zaktualizować PHP, jeśli mój serwer mógł już zostać zhakowany?
Nie. Aktualizacja zamyka lukę, ale nie usuwa już wprowadzonego złośliwego oprogramowania i nie dowodzi, że wcześniej nic się nie stało. Po wgraniu poprawki trzeba sprawdzić serwer pod kątem śladów włamania.
Po czym poznać udany atak PHP2Shell?
Nie opublikowano potwierdzonych wskaźników naruszenia (Indicators of Compromise). Wykrywanie opiera się na zachowaniu: procesy serwera WWW uruchamiające powłokę, nowe pliki PHP w folderach uploadu lub pamięci podręcznej, nieznane zadania cron lub klucze SSH oraz podejrzane połączenia wychodzące.
Czy przy podejrzeniu włamania odłączyć serwer od sieci?
Często jest to słuszne, ponieważ BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji) zaleca czasowe odłączenie serwera WWW od sieci nawet wtedy, gdy aktualizacja nie jest od razu możliwa. Ważne, aby przy tym niczego nie usuwać i zachować logi oraz pliki, żeby można było wyjaśnić incydent.
Czy po ataku PHP2Shell muszę zawiadomić organ ochrony danych?
Jeżeli mogły zostać dotknięte dane osobowe, zgłoszenie w ciągu 72 godzin może być konieczne. Decyzję podejmują Państwo wspólnie z inspektorem ochrony danych lub prawnikiem; my dostarczamy do tego fakty techniczne.
Czy serwery rzeczywiście zostały już zhakowane przez PHP2Shell?
Według doniesień medialnych pierwsze próby ataku zaobserwowano od 17.10.2026, a Cloudflare informował o zaobserwowanych próbach ataku. BSI początkowo nie zgłaszało potwierdzonych udanych ataków na szeroką skalę. W pojedynczym przypadku można to wyjaśnić tylko na samym serwerze.