Krótko: W Kubernetes PHP tkwi w obrazie kontenera, a nie w klastrze. Po PHP2Shell muszą Państwo przebudować każdy obraz PHP w Kubernetes z wersją PHP z usuniętą luką, ponownie wdrożyć wszystkie dotknięte workloady i potem sprawdzić stan w każdym działającym podzie. Zaktualizowany obraz bazowy w rejestrze sam w sobie niczego nie zmienia w działających podach.
Dlaczego sam klaster nie łata
Kubernetes zarządza kontenerami, ale nie dba o oprogramowanie wewnątrz nich. Każdy pod działa z obrazem, z którego wystartował, dopóki nie zostanie wymieniony. Kto prowadzi aplikacje PHP w klastrze, odpowiada więc za obrazy, nawet jeśli klaster działa jako zarządzana usługa u dostawcy chmury. Dostawca utrzymuje zwykle płaszczyznę sterowania i węzły, a nie obrazy klientów.
PHP2Shell obejmuje CVE-2026-109618 i CVE-2026-109619, każdą z oceną CVSS v4.0 9.2. Dotknięte są między innymi PHP-FPM, Apache z mod_php i FrankenPHP, czyli zwykłe tryby pracy w obrazach PHP. Usunięte są PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35.
Inwentaryzacja: który obraz PHP w Kubernetes działa gdzie?
Proszę zacząć od listy wszystkich obrazów w klastrze. Poniższe polecenia tylko odczytują. Nazwy przestrzeni nazw, deploymentów i kontenerów to przykłady.
# Wszystkie obrazy wszystkich podów, pogrupowane
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'
# Faktycznie działający digest obrazu dla każdego kontenera
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'
# Wersja PHP w działającym podzie
kubectl exec -n shop deploy/web -c php -- php -v
Obok deploymentów proszę pamiętać o StatefulSetach, DaemonSetach, CronJobach i kontenerach init. W większych klastrach pomagają skanery obrazów, które przeszukują obrazy pod kątem znanych CVE. Dla pakietów dystrybucji wewnątrz obrazu obowiązuje jak wszędzie: backport może pozostawić numer wersji bez zmian, wtedy liczy się dziennik zmian pakietu.
Przebudowa obrazów
Proszę najpierw zaktualizować obraz bazowy. Jeśli używają Państwo oficjalnych obrazów PHP, proszę wybrać wariant z usuniętą luką w wersji PHP. Następnie proszę przebudować własny obraz, nie przejmując starej warstwy bazowej z cache.
# Przykład: przebudowa obrazu, aktywne pobranie obrazu bazowego na nowo
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .
# Sprawdzenie wersji PHP w nowym obrazie przed rolloutem
docker run --rm registry.example.com/shop/web:2026-10-25 php -v
Nie należy polegać na tagach takich jak latest ani na samej wersji głównej. W manifeście proszę możliwie odwoływać się do digestu nowego obrazu, aby było jednoznaczne, jaki stan jest wdrażany. Jeśli wdrożenie przebiega przez GitOps lub Helm, proszę zmienić obraz tam, aby stan nie został cofnięty przy następnym uzgodnieniu.
Rollout i kontrola
Nowy rollout wymienia stopniowo wszystkie pody workloadu. Potem sprawdzają Państwo stan w działających podach. Dopiero wtedy poprawka działa, bo nowe pliki pomagają tylko wtedy, gdy stare procesy PHP już nie działają.
# Rollout z nowym obrazem (nazwy jako przykład)
kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256:<digest>
kubectl -n shop rollout status deploy/web
# Kontrola: czy wszystkie pody zostały uruchomione od nowa, czy aktywny jest nowy digest?
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v
Jeśli obraz został ponownie wypchnięty pod tym samym tagiem, kubectl rollout restart wywołuje restart; pody pobierają jednak obraz na nowo tylko wtedy, gdy przewiduje to imagePullPolicy. Bezpieczniejsza jest zmiana na nowy digest.
Proszę zabezpieczyć logi, zanim wymienią Państwo pody. Ze starym podem znikają jego lokalne logi. Proszę zachować logi serwera WWW i aplikacji od 20.10.2026, najlepiej na centralnej platformie logów.
Środki przejściowe w klastrze
Jeśli dla Państwa wersji PHP nie ma jeszcze obrazu z usuniętą luką, php.net zaleca środki przejściowe bez pełnej ochrony. W klastrze limity pamięci ustawia się przez limity zasobów kontenerów, oparte na cgroups. Odpowiada to zaleceniu, aby ograniczać pamięć przez kontener lub cgroups, a nie przez RLIMIT_AS czy RLIMIT_DATA.
; php.ini lub pula FPM w obrazie, np. dołączona przez ConfigMap
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Przy funkcji uploadu php.net podaje post_max_size = 32M. W PHP 8.5 dochodzi fatal_error_backtraces=0. Po zmianie konfiguracji potrzebny jest nowy rollout. Dodatkowo NetworkPolicy ograniczają połączenia wychodzące podów PHP, a Ingress z regułami ochronnymi może utrudnić próby ataku. Same reguły oparte na danych żądania nie wystarczają jednak według Cloudflare.
Trwale lepsze przygotowanie
Proszę zaplanować regularne automatyczne przebudowy wszystkich obrazów PHP, kontrolę obrazów w łańcuchu budowania oraz zasady dopuszczające tylko podpisane lub sprawdzone obrazy. Jeśli kontenery PHP działają z użytkownikiem bez uprawnień root i z systemem plików chronionym przed zapisem, szkody udanego ataku maleją. Wskazówki dla pojedynczych kontenerów podaje artykuł Łatanie PHP w kontenerach Docker, dla FrankenPHP artykuł Zabezpieczenie FrankenPHP.
W wielu klastrach aplikacje PHP nie działają same. Często są kontenery sidecar do logowania lub metryk, obrazy pomocnicze do migracji baz danych i zadania startujące tylko w nocy. Także obrazy zewnętrznych dostawców, na przykład dla wiki, interfejsu monitoringu lub systemu zgłoszeń, mogą zawierać PHP, choć nie widać tego po nazwie. Dlatego proszę sprawdzić nie tylko własne aplikacje, ale każdy obraz w klastrze. Dla obcych obrazów obowiązuje: proszę czekać na zaktualizowaną wersję producenta, sprawdzić jego informacje o zawartej wersji PHP i ograniczyć dostępność, dopóki nie nadejdzie. Jeśli taki system działa tylko wewnętrznie, obniża to ryzyko, ale nie zastępuje aktualizacji.
Jak konkretnie pomaga PHP SOS?
- Rejestrujemy wszystkie workloady z PHP, ich obrazy i digesty oraz sprawdzamy wersję PHP w działających podach.
- Przez usługę aktualizacji PHP przebudowujemy obrazy, wdrażamy je i dokumentujemy stan każdego workloadu.
- Zabezpieczamy logi przed wymianą i sprawdzamy ślady ataku.
- Dzięki monitoringowi bezpieczeństwa i zautomatyzowanym przebudowom dbamy o to, aby następna poprawka szybciej trafiła do klastra.
Częste pytania
Czy wystarczy zaktualizować obraz bazowy w rejestrze?
Nie. Działające pody nadal używają obrazu, z którym wystartowały. Dopiero nowy rollout z przebudowanym obrazem wymienia pody. Potem proszę sprawdzić wersję PHP w każdym działającym podzie.
Dlaczego odwoływać się do obrazów przez digest?
Tag może wskazywać różne stany obrazu, zależnie od tego, kiedy został pobrany. Digest wskazuje dokładnie jeden stan. Dzięki temu wiedzą Państwo na pewno, jaki kod działa w którym podzie, a rolloutu można prześledzić.
Co z CronJobami i kontenerami init?
One także mogą zawierać PHP i należą do inwentaryzacji. CronJoby przy każdym uruchomieniu startują nowe pody ze swojego szablonu; dlatego proszę zaktualizować obraz w szablonie. Kontenery init działają przy starcie każdego poda.
Czy NetworkPolicy chroni przed PHP2Shell?
Nie zamyka luki, ale może ograniczyć szkody. Kto ogranicza połączenia wychodzące z podów PHP, utrudnia doładowanie szkodliwego kodu i ruch boczny w klastrze.