Krótko: U dostawców chmury i PaaS poprawkę nie zawsze automatycznie instaluje dostawca. Jeśli zarządza on środowiskiem uruchomieniowym PHP, aktualizuje je, często jednak dopiero przy następnym wdrożeniu. Jeśli samodzielnie budują Państwo obrazy lub buildy albo sami prowadzą platformę, muszą Państwo zbudować i wdrożyć od nowa. Rozstrzygające jest zawsze środowisko uruchomieniowe, które Państwa strona właśnie obsługuje.
Aktualizacja PHP w PaaS: do kogo należy środowisko uruchomieniowe?
Usługi platformowe, w żargonie PaaS (Platform as a Service), zdejmują z firm prowadzenie serwerów. Wgrywają Państwo kod, a platforma go buduje i uruchamia. Przy PHP2Shell rodzi się z tego typowa niepewność: kto właściwie ma zaktualizować PHP?
Vercel ujmuje to w swoim biuletynie o PHP2Shell wprost: aktualizacja lokalnego środowiska programistycznego, kodu aplikacji czy wtyczek nie wystarcza. Rozstrzygające jest środowisko uruchomieniowe PHP wdrożenia, które faktycznie odpowiada na żądania. To, czy jest ono załatane, zależy od tego, kto je dostarcza i kiedy było ostatnio budowane.
Cztery modele działania w porównaniu
Nazwy u dostawców się różnią. Dla pytania o poprawkę większość ofert da się przypisać do jednego z tych modeli:
| Model | Kto aktualizuje PHP? | Co muszą Państwo zrobić |
|---|---|---|
| Środowisko uruchomieniowe zarządzane przez dostawcę | Dostawca | Uzyskać potwierdzenie, w razie potrzeby wdrożyć od nowa, aby nowe środowisko zaczęło działać |
| Środowisko oparte na buildzie (buildpack) | Dostawca udostępnia nową wersję, Państwa build ją ustala | Wywołać nowy build, sprawdzić wersję w protokole buildu |
| Własny obraz kontenera | Państwo | Zbudować obraz z poprawionym PHP od nowa i wdrożyć |
| Samodzielnie prowadzona platforma | Państwo, dla platformy i aplikacji | Załatać platformę i każdą aplikację osobno |
Wiele firm korzysta jednocześnie z kilku modeli, na przykład ze środowiska zarządzanego dla strony i własnych kontenerów dla narzędzi wewnętrznych. Każda aplikacja potrzebuje więc własnej odpowiedzi.
Pułapka tkwi w słowie „zarządzane”. Nawet jeśli dostawca utrzymuje środowisko uruchomieniowe, już wdrożona aplikacja często działa dalej na stanie, z którym została zbudowana. Nowa wersja zaczyna wtedy działać dopiero przy następnym buildzie lub wdrożeniu. Niektóre platformy utrzymują ponadto starsze wdrożenia lub środowiska podglądu osiągalne pod własnymi adresami. Dlatego należy pytać nie tylko, czy dostawca załatał, lecz także od kiedy działające instancje korzystają z poprawki i co dzieje się ze starymi wdrożeniami.
Co Vercel i Coolify mówią o PHP2Shell
Dwóch dostawców upubliczniło swoje wskazówki. Są pouczające, ponieważ jasno nazywają granice własnych środków ochrony.
Vercel aktywował według własnego biuletynu przed publikacją reguły ochronne w swoim Web Application Firewall (WAF), czyli filtrze żądań webowych. Obowiązują automatycznie dla funkcji PHP na Vercel i dla żądań, które Vercel przekazuje do zewnętrznych serwerów PHP. Jednocześnie Vercel wymaga natychmiastowej aktualizacji środowiska uruchomieniowego PHP do poprawionej wersji. Wdrożenia kontenerowe mają zostać zbudowane od nowa z zaktualizowanym obrazem bazowym PHP i wdrożone. Żądań, które omijają Vercel i trafiają bezpośrednio do zewnętrznego serwera PHP, WAF nie obejmuje.
Coolify, platforma, którą można prowadzić samodzielnie, była według własnego advisory sama dotknięta: wszystkie gałęzie wersji 4. Jako pierwsze poprawione wersje Coolify podaje 4.0.1, 4.1.3, 4.2.1, 4.3.24 i 4.4.7 oraz zaleca 4.4.7. Ważny jest dopisek: aktualizacja Coolify nie aktualizuje aplikacji PHP, które na nim działają. Ich środowiska uruchomieniowe lub obrazy trzeba zaktualizować osobno i zbudować lub wdrożyć od nowa. Dotyczy to według Coolify także klientów Coolify Cloud oraz aplikacji za Cloudflare, ponieważ reguły Cloudflare sprawdzają tylko ruch przechodzący przez Cloudflare.
Co dają reguły Cloudflare, ocenia artykuł Reguły ochronne Cloudflare przeciw PHP2Shell.
Jak sprawdzić środowisko, które faktycznie obsługuje żądania
Poniższe kroki działają niezależnie od dostawcy. Mają dać dowód, a nie przeczucie.
- Wypisać wszystkie środowiska: produkcja, staging, wdrożenia podglądu i usługi w tle, takie jak workery kolejek. Każde środowisko może mieć inne środowisko uruchomieniowe.
- Odczytać wersję środowiska dla każdego środowiska: w konsoli dostawcy, w protokole buildu lub w pliku konfiguracyjnym projektu.
- Sprawdzić datę ostatniego wdrożenia: Jeśli jest wcześniejsza niż 21.10.2026, z dużym prawdopodobieństwem nadal działa stare środowisko, o ile dostawca wyraźnie nie potwierdzi czegoś innego.
- Zajrzeć do działającej instancji: Jeśli platforma oferuje konsolę, poniższe polecenie pokazuje wersję instancji.
- Uwzględnić zewnętrzne serwery PHP: Serwery, do których platforma przekazuje żądania, potrzebują własnej aktualizacji i nie powinny być osiągalne bezpośrednio z internetu.
# W konsoli działającej instancji (jeśli oferuje ją dostawca)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
Oczekiwane są 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 albo backport potwierdzony przez dostawcę. Proszę pamiętać, że wiersz poleceń instancji nie zawsze używa tego samego środowiska co proces webowy. Do kontroli nie należy zakładać publicznie dostępnego pliku phpinfo. Jak właściwie interpretować numer wersji i stan backportów, opisuje Sprawdzanie wersji PHP i stanu poprawek.
Nowe wdrożenie nie usuwa szkodliwego oprogramowania, które wcześniej trafiło do pamięci trwałych, takich jak woluminy uploadu lub baza danych. Te obszary sprawdzają Państwo osobno.
Odpowiedzialność zapisać na piśmie
PHP2Shell pokazuje, jak niejasna bywa granica między platformą a klientem. Dla każdej aplikacji proszę ustalić, kto dostarcza środowisko uruchomieniowe, kto przy komunikatach bezpieczeństwa buduje od nowa i jak dostawca zapowiada poprawki. Należy do tego także, kto ma dostęp do konsoli platformy, gdy sprawa jest pilna, i kto poza godzinami pracy może wywołać nowy build.
Do własnej dokumentacji wystarczy krótka tabela dla każdej aplikacji: platforma, model działania, gałąź PHP, data ostatniego buildu, osoba odpowiedzialna. Kto ma tę listę pod ręką przy następnym komunikacie, oszczędza dni, które wiele zespołów po 21 października spędziło na szukaniu. W aplikacjach kontenerowych należy do tego, kto utrzymuje obraz bazowy; tło wyjaśnia PHP w kontenerach.
Dla serwerów zarządzanych bez charakteru PaaS obowiązują podobne pytania, które zebraliśmy w Serwer managed: wyjaśnić odpowiedzialność.
Jak konkretnie pomaga PHP SOS?
- Przypisać: Przypisujemy każdą z Państwa aplikacji do modelu działania i wyjaśniamy, kto dostarcza środowisko uruchomieniowe PHP.
- Udowodnić: Sprawdzamy środowisko, datę buildu i wdrożenie dla każdego środowiska i dokumentujemy wynik.
- Zbudować od nowa i wdrożyć: W ramach usługi PHP-Patch-Service aktualizujemy obrazy i buildy oraz wdrażamy je w sposób kontrolowany.
- Zamknąć luki: Sprawdzamy, czy zewnętrzne serwery PHP są osiągalne bezpośrednio, i ograniczamy dostęp.
Częste pytania
Czy mój dostawca PaaS łata PHP automatycznie?
To zależy od modelu. Jeśli dostawca zarządza środowiskiem uruchomieniowym, aktualizuje je, często jednak dopiero dla nowych wdrożeń. Jeśli samodzielnie budują Państwo obrazy lub buildy, muszą Państwo zbudować i wdrożyć od nowa. Proszę kazać sobie potwierdzić stan dla swojej aplikacji.
Czy WAF mojego dostawcy platformy wystarczy przeciw PHP2Shell?
Nie. Vercel i Coolify wyraźnie piszą, że reguły ochronne nie zastępują aktualizacji środowiska uruchomieniowego PHP. Działają ponadto tylko na ruch, który przechodzi przez platformę.
Czy po poprawce muszę wdrożyć od nowa?
Często tak. Vercel wskazuje dla wdrożeń kontenerowych przebudowę z zaktualizowanym obrazem bazowym PHP i nowe wdrożenie. Na platformach opartych na buildach środowisko uruchomieniowe jest ustalane podczas buildu; poprawkę przejmuje dopiero nowy build.
Używam Coolify. Czy wystarczy aktualizacja Coolify?
Nie. Według advisory Coolify aktualizacja dotyczy tylko samego Coolify. Środowiska uruchomieniowe PHP lub obrazy kontenerów Państwa aplikacji trzeba zaktualizować osobno i zbudować lub wdrożyć od nowa.