# A PHP javítása Kubernetesben

> Kubernetes PHP-image javítása a PHP2Shell után: sebezhető podok megkeresése, image-ek újraépítése, az összes workload kiállítása és az állapot igazolása podonként.

Forrás: https://phpsos.de/hu/server/kubernetes/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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.

```bash
# 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.

```bash
# 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.

```bash
# 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.

> **Fontos:**
> 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.

```ini
; 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](https://phpsos.de/hu/php2shell/docker-container-patchen/), a FrankenPHP-re pedig itt: [FrankenPHP védelme](https://phpsos.de/hu/server/frankenphp/).

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](https://phpsos.de/hu/leistungen/php-patch-service/) 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](https://phpsos.de/hu/leistungen/security-monitoring/) é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.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [BSI](https://www.bsi.bund.de/)