Röviden: Kubernetesben a PHP a konténer-image-ben van, nem a fürtben. A PHP2Shell után minden Kubernetes PHP-image-et újra kell építeni javított PHP-verzióval, az összes érintett workloadot újra ki kell állítani, majd minden futó podban ellenőrizni kell az állapotot. A registryben frissített alap-image önmagában nem változtat a futó podokon.
Miért nem javít a fürt maga
A Kubernetes konténereket kezel, de nem foglalkozik a bennük lévő szoftverrel. Minden pod azzal az image-gel fut, amelyből elindult, amíg le nem cserélik. Aki PHP-alkalmazásokat üzemeltet a fürtben, ezért felelős az image-ekért, akkor is, ha a fürt felhőszolgáltatónál menedzselt szolgáltatásként fut. A szolgáltató jellemzően a vezérlősíkot és a csomópontokat gondozza, nem az ügyfelek image-eit.
A PHP2Shell a CVE-2026-109618 és a CVE-2026-109619 rést foglalja magában, egyenként CVSS v4.0 9,2 értékkel. Érintett többek között a PHP-FPM, az Apache mod_php-vel és a FrankenPHP, vagyis a PHP-image-ek szokásos üzemmódjai. Javított a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35.
Készletfelmérés: melyik Kubernetes PHP-image hol fut?
Kezdje a fürt összes image-ének listájával. A következő parancsok csak olvasnak. A névterek, deploymentek és konténerek nevei példák.
# Az összes pod összes image-e, csoportosítva
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'
# Konténerenként a ténylegesen futó image-digest
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'
# A PHP-verzió egy futó podban
kubectl exec -n shop deploy/web -c php -- php -v
A deploymentek mellett gondoljon a StatefulSetekre, DaemonSetekre, CronJobokra és az init-konténerekre is. Nagyobb fürtökben segítenek az image-szkennerek, amelyek az image-eket ismert CVE-kre átvizsgálják. Az image-en belüli disztribúciós csomagoknál mint mindenhol: egy backport a verziószámot változatlanul hagyhatja, ilyenkor a csomag változásnaplója számít.
Image-ek újraépítése
Először frissítse az alap-image-et. Ha hivatalos PHP-image-eket használ, válasszon javított PHP-verziós változatot. Majd építse újra a saját image-ét úgy, hogy a régi alapréteget ne vegye át a gyorsítótárból.
# Példa: az image újraépítése, az alap-image aktív újrahúzásával
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .
# A PHP-verzió ellenőrzése az új image-ben a rollout előtt
docker run --rm registry.example.com/shop/web:2026-10-25 php -v
Ne támaszkodjon a latest-hez hasonló címkékre vagy puszta főverzióra. A manifestben lehetőleg az új image digestjére hivatkozzon, hogy egyértelmű legyen, melyik állapotot állítják ki. Ha a kiállítás GitOpson vagy Helmen keresztül fut, ott módosítsa az image-et, hogy az állapotot a következő egyeztetésnél ne állítsák vissza.
Rollout és ellenőrzés
Egy új rollout egy workload összes podját fokozatosan lecseréli. Utána ellenőrizze az állapotot a futó podokban. A javítás csak ekkor hatásos, mert az új fájlok csak akkor segítenek, ha régi PHP-folyamatok már nem futnak.
# Rollout új image-gel (a nevek példák)
kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256:<digest>
kubectl -n shop rollout status deploy/web
# Ellenőrzés: az összes pod újraindult, az új digest aktív?
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v
Ha az image-et azonos címkével töltötték fel újra, a kubectl rollout restart újraindítást vált ki; a podok azonban csak akkor húzzák le újra az image-et, ha az imagePullPolicy ezt előírja. Biztosabb az új digestre való váltás.
A podok lecserélése előtt mentse a naplókat. A régi poddal a helyi naplói is eltűnnek. Őrizze meg a webszerver- és alkalmazásnaplókat 2026. október 20-tól, ideális esetben egy központi naplóplatformon.
Átmeneti intézkedések a fürtben
Ha a PHP-verziójához még nem érhető el javított image, a php.net teljes védelem nélküli átmeneti intézkedéseket javasol. A fürtben a memóriakorlátokat a konténerek erőforráskorlátain keresztül állítsa be, amelyek cgroupokon alapulnak. Ez megfelel annak az ajánlásnak, hogy a memóriát konténerek vagy cgroupok útján kell korlátozni, nem a RLIMIT_AS vagy a RLIMIT_DATA segítségével.
; php.ini vagy FPM-pool az image-ben, pl. ConfigMapen keresztül beillesztve
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Feltöltési funkcióval a php.net post_max_size = 32M értéket nevezi meg. A PHP 8.5-nél ehhez jön a fatal_error_backtraces=0. A konfiguráció módosítása után új rollout szükséges. Kiegészítésként a NetworkPolicyk korlátozzák a PHP-podok kimenő kapcsolatait, és egy védelmi szabályokkal rendelkező Ingress megnehezítheti a támadási kísérleteket. A kizárólag a kéradatok alapján működő szabályok a Cloudflare szerint azonban nem elegendők.
Tartósan jobb felállás
Tervezzen rendszeres automatikus újraépítéseket az összes PHP-image-re, image-ellenőrzést a build-láncban, és olyan irányelveket, amelyek csak aláírt vagy ellenőrzött image-eket engednek. Ha a PHP-konténerek root jogok nélküli felhasználóval és írásvédett fájlrendszerrel futnak, csökken egy sikeres támadás kára. Az egyes konténerekre vonatkozó tudnivalók a következő oldalon vannak: PHP javítása Docker-konténerekben, a FrankenPHP-re pedig itt: FrankenPHP védelme.
Sok fürtben a PHP-alkalmazások nem egyedül futnak. Gyakoriak a naplózáshoz vagy metrikákhoz tartozó sidecar-konténerek, az adatbázis-migrációkhoz használt segéd-image-ek és az olyan jobok, amelyek csak éjjel indulnak. Külső szolgáltatók image-ei is, például egy wikihez, egy monitoringfelülethez vagy egy hibajegyrendszerhez, tartalmazhatnak PHP-t anélkül, hogy ez a nevükből felismerhető lenne. Ezért ne csak a saját alkalmazásait ellenőrizze, hanem a fürt minden image-ét. Idegen image-ekre ez érvényes: várjon a gyártó frissített változatára, ellenőrizze a gyártó adatait a tartalmazott PHP-verzióról, és korlátozza az elérhetőséget, amíg az nem áll rendelkezésre. Ha egy ilyen rendszer csak belsőleg fut, az csökkenti a kockázatot, de a frissítést nem helyettesíti.
Hogyan segít konkrétan a PHP SOS?
- Felmérjük az összes PHP-t tartalmazó workloadot, az image-eiket és a digestjeiket, és ellenőrizzük a PHP-verziót a futó podokban.
- A PHP-javítási szolgáltatáson keresztül újraépítjük az image-eket, kiállítjuk őket, és dokumentáljuk az állapotot workloadonként.
- A lecserélés előtt mentjük a naplókat, és ellenőrizzük a támadás nyomait.
- A biztonsági monitoringgal és az automatizált újraépítésekkel elérjük, hogy a következő javítás gyorsabban érkezzen meg a fürtbe.
Gyakori kérdések
Elég az alap-image-et frissíteni a registryben?
Nem. A futó podok tovább használják azt az image-et, amellyel elindultak. Csak egy új rollout az újraépített image-gel cseréli le a podokat. Utána ellenőrizze a PHP-verziót minden futó podban.
Miért érdemes az image-eket digesttel hivatkozni?
Egy címke különböző image-állapotokra mutathat, attól függően, mikor húzták le. A digest pontosan egy állapotot nevez meg. Így biztosan tudja, melyik kód fut melyik podban, és a rolloutok követhetők lesznek.
Mi a helyzet a CronJobokkal és az init-konténerekkel?
Ezek is tartalmazhatnak PHP-t, és a készletfelmérés részei. A CronJobok minden futáskor új podokat indítanak a sablonjukból; ezért a sablonban frissítse az image-et. Az init-konténerek minden pod indulásakor futnak.
Véd a NetworkPolicy a PHP2Shell ellen?
A rést nem zárja be, de korlátozhatja a kárt. Aki korlátozza a PHP-podok kimenő kapcsolatait, megnehezíti a kártékony kód utánatöltését és az oldalirányú mozgást a fürtben.