# FrankenPHP védelme

> FrankenPHP biztonság a PHP2Shell után: a beágyazott PHP-verzió ellenőrzése, a binary vagy image újraépítése, a workerek újraindítása, értékek védelme.

Forrás: https://phpsos.de/hu/server/frankenphp/  
Á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:** A FrankenPHP egy Caddy-alapú alkalmazásszerver, amely a PHP-t beágyazza a saját programjába. A FrankenPHP biztonság szempontjából a PHP2Shell után ez azt jelenti: nem a disztribúció PHP-csomagjai számítanak, hanem a FrankenPHP binaryban vagy a konténer-image-ben lévő PHP-verzió. Építsen vagy töltsön le javított PHP-t tartalmazó változatot, és indítsa újra az összes workert.

## Miért másképp javítják a FrankenPHP-t

A klasszikus beállításoknál a disztribúció csomagként szállítja a PHP-t, és a frissítés kicseréli a fájlokat. A FrankenPHP ezzel szemben beágyazott könyvtárként tartalmazza a PHP-t. Aki a hivatalos binaryt vagy az arra épülő konténer-image-et használja, a PHP-t együtt kapja meg. A hoszton végzett `apt upgrade` ezen nem változtat.

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. A PHP-projekt kifejezetten az érintett üzemmódok között említi a FrankenPHP-t. Javított a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35. A döntő tehát az, hogy a FrankenPHP-jét melyik PHP-verzió ellen építették.

## Worker mód és PHP2Shell

A FrankenPHP az alkalmazásokat worker módban is üzemeltetheti. Ilyenkor az alkalmazást egyszer töltik be, majd sok kérést dolgoz fel egymás után ugyanabban a folyamatban. Ez sebességet hoz, de meghosszabbítja az egyes folyamatok élettartamát.

A CVE-2026-109619 egy kérés olyan belső állapotát írja le, amely a memória felszabadítása után megmaradhat; egy későbbi kérés ugyanabban a workerben felhasználhatja, mielőtt visszaállítják. Worker módban sok kérés együttműködése egyetlen folyamatban a megszokott eset. Ez nem ok a worker mód mellőzésére, de egyértelmű ok arra, hogy a frissítéseket és az újraindításokat különösen gondosan hajtsa végre. A műszaki részleteket a következő oldal tartalmazza: [CVE-2026-109619](https://phpsos.de/hu/php2shell/cve-2026-109619/).

## FrankenPHP biztonság: a verzió ellenőrzése

A beágyazott PHP-verziót közvetlenül a futó rendszerben ellenőrizze. A következő parancsok csak olvasnak; a szolgáltatások és konténerek nevei példák.

```bash
# Telepített binary
frankenphp version

# A futó konténerben (a konténer neve példa)
docker exec app frankenphp version
docker exec app php -v

# Melyik image fut ténylegesen? (a digest a pontos állapotot mutatja)
docker inspect --format '{{.Image}} {{.Config.Image}}' app
```

Jegyezze fel a PHP-verziót a kimenetből. Ha az a javított állapotok előtti, a rendszer sebezhető. Mindig a futó konténert ellenőrizze, ne csak az utoljára épített image-et, mert egy új image csak a konténerek cseréje után hat.

## A frissítés telepítése és az összes worker újraindítása

Hogy a frissítés hogyan néz ki, az a telepítésétől függ:

- **Binary a hoszton:** telepíteni az új FrankenPHP-kiadást a javított PHP-verzióval, újraindítani a szolgáltatást.
- **Konténer:** beszerezni a javított PHP-verziós alap-image-et, újraépíteni a saját image-et az alaprétegre vonatkozó gyorsítótár nélkül, lecserélni a konténert.
- **Saját fordítású:** újraépíteni a javított PHP-verzió ellen, az összes kiterjesztést ugyanazzal a verzióval újra előállítani.

```bash
# Példa hoszttelepítésre systemd-szolgáltatásként
systemctl restart frankenphp

# Példa Docker Compose: újraépítés gyorsítótár nélkül és a konténer lecserélése
docker compose build --pull --no-cache
docker compose up -d --force-recreate
```

Utána ellenőrizze újra a PHP-verziót a futó konténerben és a folyamatok indulási idejét. Worker módban minden workernek újra kell indulnia. Kubernetesnél további lépések érvényesek, ezeket a [PHP javítása Kubernetesben](https://phpsos.de/hu/server/kubernetes/) oldal írja le, a konténerekre általában pedig a [PHP javítása Docker-konténerekben](https://phpsos.de/hu/php2shell/docker-container-patchen/) oldal.

> **Fontos:**
> A `latest` címke vagy egy főverzió az image nevében nem garantálja, hogy a legfrissebb állapota van. Aktívan húzza le újra az alap-image-et, és utána ellenőrizze a PHP-verziót a futó konténerben.

## Átmeneti intézkedések és megerősítés

Ha a frissítés nem végezhető el azonnal, a php.net átmeneti intézkedéseket javasol, amelyek nem nyújtanak teljes védelmet. A FrankenPHP-nél az értékeket abban a php.ini fájlban adja meg, amelyet a FrankenPHP betölt, vagy a Caddy-konfiguráció PHP-beállításain keresztül, nem az alkalmazásban `ini_set()`-tel.

```ini
; php.ini a konténerben vagy a hoszton
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 memóriakorlát konténerszintre való, például a konténer memóriakorlátjával, nem a `RLIMIT_AS` vagy a `RLIMIT_DATA` útján. Minden módosítás után indítsa újra az összes workert.

Tartós üzemeltetéshez érdemes az image-eket rögzített digesttel hivatkozni, rendszeresen automatizáltan újraépíteni, és egy image-szkennert beilleszteni a build-láncba. A javítás emellett nem távolítja el a korábban bejuttatott kártevőt. Őrizze meg a naplókat 2026. október 20-tól; konténereknél ez azt jelenti, hogy a lecserélés előtt el kell menteni őket.

Aki a FrankenPHP-t statikusan épített binaryként használja, tudnia kell, hogy ott a PHP mellett az összes kiterjesztés is szilárdan be van építve. A frissítés ezért mindig a teljes binary lecserélését jelenti. A csere után ellenőrizze a verziót és a betöltött kiterjesztések listáját, hogy minden úgy elérhető-e, mint korábban, és tesztelje az alkalmazást, mielőtt a régi állapotot elveti. Konténerkörnyezetekben ajánlott minden image-et a build dátumával megjelölni. Így bármikor követni tudja, melyik állapot mikor futott, és kétség esetén célzottan visszaléphet, anélkül hogy ismét sebezhető állapotba esne. A dokumentációjában rögzítse az image, a PHP-verzió és az időpont hozzárendelését.

## Hogyan segít konkrétan a PHP SOS?

- Ellenőrizzük, hogy a FrankenPHP-binaryjaiban és a futó konténereiben ténylegesen melyik PHP-verzió van.
- 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, lecseréljük a konténereket, és újraindítjuk az összes workert, igazolással.
- A lecserélés előtt mentjük a naplókat, és ellenőrizzük az alkalmazást nyomokra.
- Tartós üzemeltetéshez automatizált újraépítéseket és image-ellenőrzéseket állítunk be a [szerver-megerősítés](https://phpsos.de/hu/leistungen/server-haertung/) keretében.


## Gyakori kérdések

**Segít a FrankenPHP-nél egy apt- vagy dnf-frissítés?**  
Csak akkor, ha maga a FrankenPHP ezekből a csomagforrásokból származik, és a javított PHP ellen építették. Gyakran a PHP szilárdan benne van a FrankenPHP binaryban vagy a konténer-image-ben. Ilyenkor a binaryt vagy az image-et kell frissíteni.

**Miért különösen fontos a worker mód a PHP2Shellnél?**  
Worker módban az alkalmazás a memóriában marad, és sok kérést dolgoz fel egymás után ugyanabban a folyamatban. A CVE-2026-109619 éppen azt a belső állapotot érinti, amely ugyanabban a workerben kérések között megmaradhat. Az összes worker újraindítása a frissítés után ezért kötelező.

**Hogyan ellenőrzöm, melyik PHP-verzió van a FrankenPHP-ben?**  
A FrankenPHP binary a verzió lekérdezésekor kiírja a beágyazott PHP-verziót. Konténerben a parancsot a docker exec segítségével futtathatja. Ügyeljen arra, hogy a ténylegesen futó konténerben ellenőrizze a verziót, ne az újonnan épített image-ben.

**Vannak a FrankenPHP-nek saját átmeneti intézkedései?**  
A php.net általános tudnivalói érvényesek. Az értékeket abban a php.ini fájlban adja meg, amelyet a FrankenPHP betölt, vagy a Caddy-fájl PHP-konfigurációjában, nem az alkalmazásban ini_set()-tel. Utána indítsa újra az összes workert.

## 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/)