Krótko: Wirtualne łatanie dla PHP przeczekuje czas do zainstalowania właściwej aktualizacji. Łączymy w tym celu reguły Web Application Firewall ze środkami przejściowymi, które php.net opublikował w sprawie PHP2Shell, i od razu ustalamy drogę do regularnej poprawki. Nie zapewnia to pełnej ochrony, ale zmniejsza ryzyko w okresie przejściowym.
Kiedy wirtualne łatanie dla PHP ma sens
BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji) zaleca przy PHP2Shell natychmiastową aktualizację, a jeśli nie jest to możliwe, czasowe odłączenie serwerów WWW od sieci. Dla wielu firm jedno i drugie nie jest od razu wykonalne: sklep musi pozostać dostępny, rozwiązanie własne wymaga przed aktualizacją testu albo serwer działa z PHP 8.1 lub starszym, dla którego nie ma już oficjalnych aktualizacji.
W takich przypadkach wirtualne łatanie jest pomostem. Nie zastępuje decyzji, czy praca offline nie byłaby stosowniejsza. Tę ocenę podejmują Państwo, my dostarczamy ocenę techniczną.
Dlaczego sam WAF nie wystarcza
Cloudflare zgłosił zaobserwowane próby ataków i wdrożył reguły ochronne, ale ostrzega, że same reguły oparte na danych żądania nie wystarczają. Przyczyna leży w charakterze luk. W przypadku CVE-2026-109618 stan braku pamięci (out-of-memory) może przerwać PHP, gdy dane żądania są zainicjowane tylko częściowo. W przypadku CVE-2026-109619 stan wewnętrzny może pozostać po zwolnieniu pamięci i zostać wykorzystany przez późniejsze żądanie w tym samym workerze. Takie błędy zależą od stanu serwera, a nie tylko od treści pojedynczego żądania.
Dlatego stawiamy na kilka warstw: reguły WAF przed serwerem, środki przejściowe w samym PHP i wzmożoną obserwację serwera. Każda warstwa wychwytuje część, żadna sama nie wystarcza. Razem dają Państwu czas na uporządkowane zainstalowanie aktualizacji.
Środki przejściowe wg php.net
php.net podaje kilka ustawień, które obniżają ryzyko, wyraźnie bez pełnej ochrony. Ważne, aby aplikacje nie mogły nadpisać tych wartości. Przykład puli PHP-FPM z uploadami:
; Środki przejściowe PHP2Shell (brak pełnej ochrony), potem zrestartować wszystkie workery
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; tylko PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Bez uploadów php.net zaleca post_max_size = 8M. Ponieważ memory_limit zostaje zniesiony, potrzebny jest do tego limit pamięci na poziomie kontenera lub cgroup, a nie przez RLIMIT_AS czy RLIMIT_DATA. Ustawienie session.upload_progress.enabled=0 należy do php.ini, puli FPM lub konfiguracji serwera, a nie do ini_set() ani .user.ini. Jest ono zarazem środkiem zaradczym dla wskazówki dotyczącej CVE-2026-115560. Wszystkie środki w zestawieniu znajdą Państwo na stronie Środki natychmiastowe, gdy nie można jeszcze załatać.
Środki przejściowe działają dopiero po restarcie wszystkich workerów PHP. I chronią tylko przed przyszłymi atakami: czy ktoś włamał się wcześniej, nie rozstrzygają.
Kiedy lepszym wyborem jest praca offline
Wirtualne łatanie nie jest w każdej sytuacji właściwą odpowiedzią. W niektórych konstelacjach radzimy postąpić zgodnie z BSI i czasowo odłączyć serwer WWW od sieci do czasu załatania:
- serwer działa z Apache i mod_php, gdzie zespół PHP ocenia ryzyko najwyżej, a exploit pokazano, zanim w ogóle uruchomi się kod aplikacji
- na serwerze znajdują się dane szczególnie wymagające ochrony, na przykład dane zdrowotne, dane klientów kancelarii lub dane płatnicze
- nie ma możliwości trwałego ustawienia środków przejściowych w konfiguracji serwera, na przykład w niektórych pakietach hostingu współdzielonego
- istnieją już oznaki, że serwer został zaatakowany
Czasowa praca offline nie oznacza, że Państwa strona została zhakowana. Niektórzy dostawcy z ostrożności wyłączyli strony. Krótka, rzeczowa strona informacyjna dla odwiedzających jest wtedy zwykle lepszym rozwiązaniem niż niewyjaśniona niedostępność.
Jak konkretnie pomaga PHP SOS?
- Sprawdzenie sytuacji: Rejestrujemy wersje PHP, tryby pracy i istniejące warstwy ochrony, takie jak CDN, WAF czy reverse proxy. Przy mod_php zwracamy uwagę na podwyższone ryzyko, które widzi tam zespół PHP.
- Budowa warstw: Aktywujemy lub uzupełniamy reguły WAF, ustawiamy środki przejściowe na stałe w konfiguracji serwera i ograniczamy pamięć przez kontener lub cgroup. Dla konfiguracji Nginx opieramy się na Zabezpieczanie Nginx z PHP-FPM.
- Restart i test: Wszystkie procesy PHP są restartowane, następnie sprawdzamy uploady, formularze, logowanie i kasę.
- Obserwacja: W okresie przejściowym zwracamy większą uwagę na awarie workerów, skoki zużycia pamięci i nietypowe procesy.
- Planowanie poprawki: Ustalamy, kiedy i jak nastąpi regularna aktualizacja, i wdrażamy ją przez usługę łatania PHP.
Co Państwo otrzymują, czego potrzebujemy i czego nie obiecujemy
Otrzymują Państwo dokumentację wszystkich ustawionych reguł i ustawień wraz z uzasadnieniem, wyniki testów oraz plan terminów i działań dla właściwej poprawki. Od Państwa potrzebujemy dostępu do serwera lub panelu, dostępu do CDN lub WAF, jeśli istnieją, technicznej osoby kontaktowej oraz informacji o funkcjach uploadu w Państwa aplikacjach.
Nie obiecujemy, że wirtualne łatanie zapobiegnie atakowi. Obniża ono ryzyko na ograniczony czas. Przy PHP 8.1 i starszym nie jest stanem trwałym; tu w planie powinna znaleźć się migracja na wspieraną wersję.
Częste pytania
Czym jest wirtualne łatanie?
Wirtualne łatanie oznacza osłonięcie znanej luki przed aplikacją zamiast zmieniania samego kodu. Odbywa się to zwykle przez Web Application Firewall lub zmiany konfiguracji. Jest to rozwiązanie pomostowe, a nie zamiennik aktualizacji.
Czy WAF mojego dostawcy CDN wystarcza przeciw PHP2Shell?
Samodzielnie zwykle nie. Cloudflare wdrożył reguły ochronne, ale sam ostrzega, że same reguły oparte na danych żądania nie wystarczają. WAF jest dodatkową warstwą obok środków przejściowych i poprawki.
Jak długo mogę polegać na wirtualnym łataniu?
Jak najkrócej. Ma ono przeczekać czas do regularnej aktualizacji, na przykład do wolnego okna serwisowego lub przetestowania aplikacji. Przy PHP 8.1 i starszym potrzebny jest do tego plan migracji.
Czy środki przejściowe mogą zakłócić działanie mojej strony?
Tak, jest to możliwe. Mniejsze limity uploadu mogą uniemożliwić wysyłanie dużych plików, a wyłączenie session upload progress dotyczy wskaźników postępu przy wysyłaniu. Po każdej zmianie testujemy najważniejsze funkcje.