Niezałatane PHP to otwarte drzwi. My je zamykamy.
Zdalna pomoc awaryjna dla firm w Europie: łatanie PHP, sprawdzanie śladów włamania, usuwanie złośliwego kodu, utwardzanie serwerów. Natychmiast, ze specjalistycznymi partnerami, aż do zamknięcia i udokumentowania incydentu.
$ php -v PHP 8.3.35 (cli) (built: Sep 30 2026) ! Stan przed poprawką z 21.10.2026 $ phpsos pruefen --ziel produktion Tryb pracy ....... php-fpm CVE-2026-109618 .. otwarte CVE-2026-109619 .. otwarte Restart procesów worker .. oczekuje $ phpsos absichern [ok] Zainstalowano pakiet 8.3.36 [ok] Wszystkie procesy worker zrestartowane [ok] System plików sprawdzony pod kątem webshelli [ok] Raport dla zarządu sporządzony
- Made in GermanyBezpieczeństwo IT z Niemiec, praca zgodna z europejskim prawem ochrony danych.
- Ponad 25 latOd ponad 25 lat specjalizujemy się w bezpieczeństwie IT i obsłudze serwerów wraz z naszą siecią partnerów.
- Sieć partnerówWyspecjalizowani specjaliści ds. cyberbezpieczeństwa w zakresie informatyki śledczej, testów penetracyjnych i utwardzania serwerów, koordynowani przez jedną osobę kontaktową.
Czy to Państwa dotyczy? Prosimy zadzwonić. Pomożemy.
Włamanie, zablokowany serwis, znaleziony web shell albo niepewność, czy PHP2Shell Państwa dotyczy: prosimy o kontakt już teraz. Przejmujemy sprawę od pierwszej wiadomości, zdalnie i bez dojazdu.
Czy Państwa PHP jest już załatane?
Proszę wpisać wersję PHP. Test porównuje ją z komunikatami bezpieczeństwa php.net i wskazuje, co zrobić dalej. Ważne: nawet załatana wersja nie dowodzi, że przed aktualizacją nic się nie wydarzyło.
Jak pilna jest Państwa sytuacja?
Cztery pytania, klasyfikacja, pierwsze kroki i przygotowana wiadomość WhatsApp do nas. Przy poziomie 3 obowiązuje zasada: niczego nie usuwać, niczego nie instalować od nowa, zabezpieczyć ślady.
Od wezwania pomocy do utwardzonego serwera
Przejmujemy stronę techniczną i dostarczamy dowody, których potrzebują zarząd, ochrona danych i ubezpieczyciel.
Natychmiastowa pomoc przy PHP2Shell: wsparcie przy luce bezpieczeństwa w PHP
Zamykamy PHP2Shell na Państwa serwerach WWW zdalnie: inwentaryzacja, poprawka lub środek przejściowy, restart wszystkich workerów i pisemny dowód.
Czytaj dalej →02Strona zhakowana, co robić? Zdalna pomoc awaryjna
Państwa strona została zhakowana lub zachowuje się podejrzanie? Przejmujemy zdalnie powstrzymanie ataku, zabezpieczenie śladów, oczyszczanie i dokumentację.
Czytaj dalej →03Usługa łatania PHP: aktualizacja z restartem i dowodem
Instalujemy aktualizację PHP na Państwa serwerach, restartujemy wszystkie procesy PHP i dostarczamy pisemny dowód wersji, stanu pakietów i restartu.
Czytaj dalej →04Utwardzanie serwerów WWW z PHP
Utwardzamy Państwa serwery WWW z PHP według stałego planu: izolacja każdej strony, bezpieczna konfiguracja PHP, uprawnienia plików, dostępy, logi i kopie zapasowe.
Czytaj dalej →05Usuwanie malware i webshelli ze strony internetowej
Usuwamy złośliwy kod, webshelle i tylne furtki ze stron i serwerów, odbudowujemy z zaufanych źródeł i zamykamy drogę włamania.
Czytaj dalej →06Incident Response przy atakach na serwery
Uporządkowana obsługa incydentów przy atakach na serwery WWW: obraz sytuacji, powstrzymanie, usunięcie, przywrócenie i podsumowanie ze stałymi rolami.
Czytaj dalej →Tak działamy w razie awarii
Jasne kroki, jedna osoba kontaktowa, wszystko zdalnie. Specjaliści z naszej sieci partnerów dołączają, gdy potrzebna jest informatyka śledcza lub pentest.
Rozpoznanie sytuacji
Piszą Państwo na WhatsApp lub dzwonią. Ustalamy system, wersję PHP, firmę hostingową i obserwacje.
Zabezpieczenie i zamknięcie luki
Zabezpieczenie śladów, załatanie PHP lub wdrożenie środków tymczasowych, restart wszystkich procesów worker, udokumentowanie stanu poprawek.
Kontrola i oczyszczanie
Sprawdzenie plików, bazy danych, kont i logów pod kątem śladów włamania. Usunięcie webshelli i tylnych furtek.
Utwardzanie i raport
Utwardzenie konfiguracji, wdrożenie monitoringu, raport dla zarządu, ochrony danych i ubezpieczyciela.
Poprawka jeszcze niemożliwa? Środki tymczasowe
php.net podaje ustawienia, które utrudniają znane ścieżki ataku do czasu zainstalowania aktualizacji. Proszę wybrać tryb pracy, skopiować wiersze, a następnie zrestartować wszystkie procesy PHP.
BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) zaleca: jeśli aktualizacja nie jest od razu możliwa, tymczasowo odłączyć serwer WWW od sieci.
Środki tymczasowe według php.net, nie zastępują aktualizacji. memory_limit=-1 tylko razem z limitem pamięci ustawionym przez kontener lub cgroup. Wcześniej wykonać kopię zapasową konfiguracji.
Kto za co odpowiada? Luka między firmą hostingową a agencją
Wiele firm polega na tym, że „ktoś” zainstaluje poprawki. Zwykle podział wygląda tak:
| Zadanie | Firma hostingowa (hosting współdzielony) | Agencja / web design | PHP SOS |
|---|---|---|---|
| Zaktualizować pakiet PHP | najczęściej tak | najczęściej nie | tak, lub z Państwa firmą hostingową |
| Zrestartować wszystkie procesy worker i to udokumentować | częściowo | nie | tak, z dowodem |
| Sprawdzić, czy przed poprawką doszło do włamania | zazwyczaj nie | częściowo | tak |
| Usunąć webshelle i tylne furtki | zazwyczaj nie | częściowo | tak |
| Raport dla zarządu, ochrony danych i ubezpieczyciela | nie | rzadko | tak |
| Utwardzanie i bieżący monitoring | częściowo | częściowo | tak |
Co jest udokumentowane i co należy teraz zrobić
Fakty z komunikatów php.net i BSI, opracowane dla zarządu i administratorów.
Czym jest PHP2Shell? Luka wyjaśniona prosto
PHP2Shell to dwie krytyczne luki w samym PHP, przez które atakujący mogą bez logowania wykonać kod na serwerach WWW. Oto sytuacja jasnymi słowami.
Czytaj dalej →CVE-2026-109618: RCE przez stan out-of-memory
CVE-2026-109618 to jedna z dwóch luk PHP2Shell: stan out-of-memory może przerwać PHP w trakcie przetwarzania żądania. Naprawione od PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35.
Czytaj dalej →CVE-2026-109619: RCE przez przestarzały stan globalny
CVE-2026-109619 to druga luka PHP2Shell: stan wewnętrzny żądania może pozostać po zwolnieniu pamięci i zostać wykorzystany przez następne żądanie w tym samym workerze.
Czytaj dalej →CVE-2026-115560: wskazówka o session upload progress
CVE-2026-115560 to wskazówka php.net z 23.10.2026: możliwe wykonanie kodu tylko przy nietypowej konfiguracji sesji. Środek do kolejnego wydania: session.upload_progress.enabled=0.
Czytaj dalej →Które wersje PHP są podatne?
PHP2Shell jest naprawione w PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Dla PHP 8.1 i starszego nie ma już oficjalnych aktualizacji. Tabela pokazuje stan dla każdej gałęzi.
Czytaj dalej →Jak prawidłowo sprawdzić wersję PHP i stan poprawek
Sama wyświetlana wersja PHP nie mówi, czy PHP2Shell jest zamknięte. Decydują stan pakietów, backporty i to, czy nowe procesy faktycznie działają.
Czytaj dalej →Dla Państwa platformy i serwera
Gdzie złośliwy kod ukrywa się w WordPressie, Shopware lub TYPO3 i jak naprawdę łatać w Plesk, cPanel lub w kontenerze.
Platformy
Serwery i hosting
Każda branża ma do stracenia inne dane
Dane zdrowotne, tajemnica klientów kancelarii, dane płatnicze: kontrolę i raport dostosowujemy do Państwa obowiązków.
10 kroków, zanim przejmiemy sprawę
Proszę zaznaczać to, co zostało zrobione. Lista pozostaje zapisana w Państwa przeglądarce.
Zaznaczenia są zapisywane wyłącznie w Państwa przeglądarce.
72 godziny, NIS2, ubezpieczenie
Ogólna orientacja dla zarządu. To nie jest porada prawna.
Obowiązek zgłoszenia z RODO: 72 godziny po incydencie
Po ataku na serwer WWW może istnieć obowiązek zgłoszenia do organu nadzorczego. Tu ogólnie wyjaśniamy, kiedy biegną 72 godziny i co należy do zgłoszenia.
Czytaj dalej →NIS2 a bezpieczeństwo serwerów WWW
NIS2 zobowiązuje wiele firm do zarządzania ryzykiem i zgłoszeń. Tu ogólnie wyjaśniamy, co to oznacza dla serwerów WWW i gdzie znaleźć wiarygodne informacje.
Czytaj dalej →Cyberubezpieczenie: co liczy się w razie szkody
Przy ataku o świadczeniu często decydują wczesne poinformowanie ubezpieczyciela, zabezpieczone dowody i uzgodnione kroki. Tu ogólnie podajemy typowe punkty.
Czytaj dalej →Odpowiedzialność zarządu za luki w bezpieczeństwie IT
Bezpieczeństwo IT to zadanie kierownictwa. Tu ogólnie wyjaśniamy, jakie obowiązki staranności obowiązują i jak zarząd podejmuje czytelne decyzje przy lukach takich jak PHP2Shell.
Czytaj dalej →Artykuły eksperckie dla administratorów i programistów
Oś czasu PHP2Shell: chronologia od 17 do 25 października 2026
Wszystkie potwierdzone daty dotyczące PHP2Shell w jednym zestawieniu, od pierwszej zaobserwowanej próby ataku do stanu na 25.10.2026, oraz wnioski dla Państwa kontroli.
Czytaj dalej →Potwierdzenie aktualizacji PHP od hostingu: jak zapytać o stan poprawek
Wyświetlana wersja PHP po PHP2Shell niewiele dowodzi. Za pomocą tego wzoru zażądają Państwo od hostingu potwierdzenia, które można udokumentować.
Czytaj dalej →Jak wykryć i usunąć webshell
Jak wyszukać tylne furtki na serwerach WWW z PHP bez niszczenia śladów i dlaczego samo usunięcie rzadko wystarcza.
Czytaj dalej →Backdoor w WordPressie: systematyczne wyszukiwanie tylnych furtek
Gdzie zwykle ukrywają się tylne furtki w WordPressie i jak administratorzy mogą je systematycznie wyszukać za pomocą WP-CLI i kilku poleceń.
Czytaj dalej →Jak bezpiecznie skonfigurować php.ini
Które ustawienia w php.ini zmniejszają powierzchnię ataku, jak chronić je przed nadpisaniem i co obowiązuje dodatkowo po PHP2Shell.
Czytaj dalej →Jak prawidłowo stosować PHP disable_functions
Za pomocą disable_functions blokują Państwo ryzykowne funkcje PHP. Jak ustalić listę odpowiednio do aplikacji, nie paraliżując strony.
Czytaj dalej →Sytuacja, instrukcje, pomoc w podejmowaniu decyzji
Od poziomu ostrzeżenia BSI i changelogów pakietów po pytanie, czy zainstalować system od nowa, czy go oczyścić. Każdy artykuł ze źródłami.
PHP2Shell: co jest udowodnione, a co nie
Sprawdzenie faktów dotyczących PHP2Shell: które twierdzenia pochodzą ze źródeł pierwotnych, które z doniesień medialnych i których twierdzeń nie da się obronić.
Czytaj dalej →Zmiana wersji PHP w panelu klienta hostingu
Jak przestawić wersję PHP w panelu klienta dostawcy hostingu, którą wersję wybrać i co sprawdzić przed zmianą i po niej.
Czytaj dalej →Sygnał ostrzegawczy: serwer WWW uruchamia powłokę
Jeśli proces PHP-FPM lub serwera WWW uruchamia powłokę, to jeden z najsilniejszych sygnałów ostrzegawczych włamania. Oto jak sprawdzić drzewo procesów, ocenić wyjątki i stale monitorować wzorzec.
Czytaj dalej →Izolowanie pul PHP-FPM dla każdej strony
Osobna pula dla każdej strony to początek, a nie koniec. Jak sprawdzić istniejące pule i utwardzić gniazda, rozszerzenia, strony statusu, zasoby i logi.
Czytaj dalej →Bezpieczne przechowywanie haseł w PHP: prawidłowe użycie password_hash
Jak programiści przechowują hasła w PHP za pomocą password_hash i password_verify, dobierają odpowiednią metodę i zastępują stare skróty MD5 lub SHA-1 bez resetu haseł dla wszystkich użytkowników.
Czytaj dalej →Umowy z dostawcami IT: jasne uregulowanie obowiązków w zakresie bezpieczeństwa
PHP2Shell pokazał, jak często niejasne jest, kto ma łatać. Jakie obowiązki w zakresie bezpieczeństwa należą do umów z agencją, firmą hostingową i dostawcą IT.
Czytaj dalej →Język programowania PHP, wyjaśniony zrozumiale
Jak PHP generuje stronę, czym są SAPI, PHP-FPM i OPcache oraz dlaczego to właśnie decyduje o bezpieczeństwie. Do tego słownik wszystkich pojęć fachowych.
Czym jest PHP2Shell?
PHP2Shell to dwie krytyczne luki w samym PHP (CVE-2026-109618 i CVE-2026-109619, CVSS 9,2). Mogą umożliwić atakującym wykonanie złośliwego kodu na serwerze bez logowania. Poprawki są dostępne od 21.10.2026.
Które wersje PHP są bezpieczne?
Poprawki zawierają wersje PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Firmy hostingowe i dystrybucje czasem wprowadzają backporty bez zmiany numeru wersji. Rozstrzygający jest stan pakietu lub pisemne potwierdzenie dostawcy.
Czy wystarczy aktualizacja WordPressa lub sklepu?
Nie. Luka tkwi w PHP, a nie w CMS. Aktualizacja CMS jej nie zamyka. Z kolei poprawka PHP nie usuwa złośliwego kodu, który został wprowadzony wcześniej.
Jak szybko mogą Państwo pomóc?
Pracujemy zdalnie i zaczynamy, gdy tylko otrzymamy dostępy. Proszę napisać do nas na WhatsApp: system, wersja PHP i obserwacje. Następnie od razu ustalimy sposób działania.
Czy pracują Państwo także dla agencji i klientów firm hostingowych?
Tak. Pracujemy bezpośrednio dla firm, w tle na zlecenie agencji oraz w uzgodnieniu z Państwa firmą hostingową, jeśli to ona zarządza serwerem.
Czy musimy zgłosić incydent?
Jeżeli mogą być dotknięte dane osobowe, zgodnie z art. 33 RODO obowiązuje zwykle termin zgłoszenia wynoszący 72 godziny od momentu stwierdzenia naruszenia. To, czy ma on zastosowanie, należy ustalić z inspektorem ochrony danych. Dostarczamy do tego dokumentację techniczną.
Liczy się każda godzina. Proszę napisać do nas teraz.
Proszę krótko opisać system, wersję PHP i obserwacje. Skontaktujemy się z Państwem, ustalimy sytuację i będziemy pracować zdalnie, aż incydent zostanie zamknięty i udokumentowany.