Röviden: Felhő- és PaaS-szolgáltatóknál nem automatikusan a szolgáltató javít. Ha ő kezeli a PHP-futtatókörnyezetet, ő frissíti, de gyakran csak a következő telepítéssel. Ha az image-eket vagy buildeket maga készíti, vagy a platformot maga üzemelteti, újra kell építenie és telepítenie. Mindig az a futtatókörnyezet a mérvadó, amelyet a weboldala éppen kiszolgál.
PHP-frissítés PaaS-nél: kié a futtatókörnyezet?
A platformszolgáltatások, szakzsargonban a PaaS (Platform as a Service), átveszik a szerverüzemeltetést a vállalatoktól. Feltölti a kódot, a platform felépíti és üzemelteti. A PHP2Shellnél ebből tipikus bizonytalanság adódik: kinek kell egyáltalán frissítenie a PHP-t?
A Vercel a PHP2Shellről szóló bulletinjében a lényegre mutat: nem elég frissíteni a helyi fejlesztői környezetet, az alkalmazáskódot vagy a bővítményeket. A döntő az a telepítés PHP-futtatókörnyezete, amely ténylegesen megválaszolja a kéréseket. Hogy ez a futtatókörnyezet javított-e, az attól függ, ki biztosítja, és mikor építették utoljára.
Négy üzemeltetési modell összehasonlítása
A szolgáltatók elnevezései eltérnek. A javítási kérdés szempontjából a legtöbb ajánlat besorolható az alábbi modellek egyikébe:
| Modell | Ki frissíti a PHP-t? | Mit kell tennie |
|---|---|---|
| A szolgáltató által kezelt futtatókörnyezet | A szolgáltató | Megerősítést kérni, szükség esetén újratelepíteni, hogy az új futtatókörnyezet érvényesüljön |
| Build-alapú futtatókörnyezet (buildpack) | A szolgáltató új verziót biztosít, az Ön buildje rögzíti | Új buildet indítani, a verziót ellenőrizni a build-naplóban |
| Saját konténer-image | Ön | A javított PHP-vel újraépíteni az image-et és telepíteni |
| Saját üzemeltetésű platform | Ön, a platformért és az alkalmazásokért | A platformot és minden alkalmazást külön javítani |
Sok vállalat egyszerre több modellt is használ, például kezelt futtatókörnyezetet a weboldalhoz és saját konténereket a belső eszközökhöz. Ezért minden alkalmazásnak külön válasz kell.
A „kezelt” szóban csapda rejlik. Még ha a szolgáltató gondozza is a futtatókörnyezetet, egy már telepített alkalmazás gyakran azzal az állapottal fut tovább, amellyel építették. Az új verzió ilyenkor csak a következő buildnél vagy telepítésnél lép életbe. Egyes platformok ráadásul régebbi telepítéseket vagy előnézeti környezeteket tartanak elérhetően saját címeken. Ne csak azt kérdezze meg, hogy a szolgáltató javított-e, hanem azt is, hogy mikortól használja a javítást a futó példányai, és mi lesz a régi telepítésekkel.
Mit mond a Vercel és a Coolify a PHP2Shellről
Két szolgáltató nyilvánosságra hozta a tudnivalóit. Tanulságosak, mert világosan megnevezik a saját védelmi intézkedéseik határait.
A Vercel saját bulletinje szerint a közzététel előtt védelmi szabályokat aktivált a webalkalmazás-tűzfalában (WAF), a webes kérések szűrőjében. Ezek automatikusan érvényesek a Vercelen lévő PHP-függvényekre és azokra a kérésekre, amelyeket a Vercel külső PHP-szerverekre továbbít. Egyúttal a Vercel kéri, hogy a PHP-futtatókörnyezetet azonnal frissítsék egy kijavított verzióra. A konténeres telepítéseket frissített PHP-alapimage-dzsel kell újraépíteni és telepíteni. A WAF nem fedi azokat a kéréseket, amelyek megkerülik a Vercelt, és közvetlenül egy külső PHP-szerverre mennek.
A Coolify, egy saját magunk üzemeltethető platform, a saját advisory-ja szerint maga is érintett volt: a 4-es verzió összes ága. Az első kijavított állapotokként a Coolify a 4.0.1, 4.1.3, 4.2.1, 4.3.24 és 4.4.7 verziót nevezi meg, és a 4.4.7-et ajánlja. Fontos a kiegészítés: a Coolify-frissítés nem frissíti azokat a PHP-alkalmazásokat, amelyeket rajta keresztül üzemeltet. Azok futtatókörnyezeteit vagy image-eit külön kell frissítenie, és újra kell építenie vagy telepítenie. Ez a Coolify szerint a Coolify Cloud ügyfeleire és a Cloudflare mögötti üzemeltetésre is érvényes, mert a Cloudflare-szabályok csak a Cloudflare-en keresztül haladó forgalmat vizsgálják.
Hogy mit tudnak a Cloudflare-szabályok, azt a Cloudflare védelmi szabályok a PHP2Shell ellen cikk helyezi el.
Így ellenőrizze a kiszolgáló futtatókörnyezetet
Az alábbi lépések a szolgáltatótól függetlenül működnek. Igazolásra irányulnak, nem megérzésre.
- Sorolja fel az összes környezetet: éles, staging, előnézeti telepítések és háttérszolgáltatások, például queue-workerek. Minden környezetnek más futtatókörnyezete lehet.
- Olvassa le a futtatókörnyezet verzióját környezetenként: a szolgáltató konzoljában, a build-naplóban vagy a projekt konfigurációs fájljában.
- Ellenőrizze az utolsó telepítés dátumát: Ha 2026. október 21. előtti, nagy valószínűséggel még a régi futtatókörnyezet fut, hacsak a szolgáltató kifejezetten mást nem erősít meg.
- Nézze meg a futó példányban: Ha a platform konzolt kínál, a következő parancs megmutatja a példány verzióját.
- Vonja be a külső PHP-szervereket: Azok a szerverek, amelyekre a platform kéréseket továbbít, saját frissítést igényelnek, és nem szabad közvetlenül elérhetőnek lenniük az internetről.
# A futó példány konzolján (ha a szolgáltató kínálja)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
Várt érték: 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35, illetve egy, a szolgáltató által megerősített backport. Vegye figyelembe, hogy egy példány parancssora nem mindig ugyanazt a futtatókörnyezetet használja, mint a webes folyamat. Az ellenőrzéshez ne hozzon létre nyilvánosan elérhető phpinfo-fájlt. Hogyan értelmezze helyesen a verziószámot és a backport-állapotot, azt a PHP-verzió és javítási állapot ellenőrzése írja le.
Egy új telepítés nem távolítja el azt a kártevőt, amely korábban tartós tárolókba, például feltöltési kötetekbe vagy az adatbázisba jutott. Ezeket a területeket külön ellenőrizze.
A felelősséget rögzítse írásban
A PHP2Shell megmutatja, mennyire tisztázatlan gyakran a határ a platform és az ügyfél között. Alkalmazásonként rögzítse, ki biztosítja a futtatókörnyezetet, ki épít újra biztonsági közleményeknél, és hogyan jelenti be a szolgáltató a javításokat. Idetartozik az is, ki fér hozzá a platform konzoljához, ha sürgős, és ki indíthat új buildet munkaidőn kívül.
A saját dokumentációhoz alkalmazásonként elég egy rövid táblázat: platform, üzemeltetési modell, PHP-ág, az utolsó build dátuma, felelős. Aki a következő közleménynél kéznél tartja ezt a listát, megspórolja azokat a napokat, amelyeket sok csapat október 21. után keresgéléssel töltött. Konténeres alkalmazásoknál idetartozik, ki gondozza az alapimage-et; a hátteret a PHP konténerekben oldal magyarázza.
A PaaS-jelleg nélküli kezelt szerverekre hasonló kérdések érvényesek, amelyeket a Menedzselt szerver: a felelősség tisztázása oldalon foglaltunk össze.
Hogyan segít konkrétan a PHP SOS?
- Besorolás: Minden alkalmazását besoroljuk egy üzemeltetési modellbe, és tisztázzuk, ki biztosítja a PHP-futtatókörnyezetet.
- Igazolás: Ellenőrizzük a futtatókörnyezetet, a build dátumát és a telepítést környezetenként, és dokumentáljuk az eredményt.
- Újraépítés és telepítés: A PHP-javítási szolgáltatáson keresztül frissítjük az image-eket és buildeket, és ellenőrzötten telepítjük őket.
- Hézagok zárása: Ellenőrizzük, hogy a külső PHP-szerverek közvetlenül elérhetők-e, és korlátozzuk a hozzáférést.
Gyakori kérdések
Automatikusan javítja a PHP-t a PaaS-szolgáltatóm?
Ez a modelltől függ. Ha a szolgáltató kezeli a futtatókörnyezetet, ő frissíti, de gyakran csak az új telepítésekhez. Ha az image-eket vagy buildeket maga készíti, újra kell építenie és újra kell telepítenie. Erősíttesse meg az alkalmazására vonatkozó állapotot.
Elég a platformszolgáltatóm WAF-ja a PHP2Shell ellen?
Nem. A Vercel és a Coolify kifejezetten leírja, hogy a védelmi szabályok nem pótolják a PHP-futtatókörnyezet frissítését. Ráadásul csak a platformon keresztül haladó forgalomra hatnak.
A javítás után újra kell telepítenem?
Gyakran igen. A Vercel konténeres telepítéseknél a frissített PHP-alapimage-dzsel való újraépítést és új telepítést nevez meg. A build-alapú platformokon a futtatókörnyezet a buildkor rögzül; csak egy új build veszi át a javítást.
Coolifyt használok. Elég a Coolify frissítése?
Nem. A Coolify-advisory szerint a frissítés csak magát a Coolifyt frissíti. Az alkalmazásai PHP-futtatókörnyezetét vagy konténer-image-eit külön kell frissítenie, és újra kell építenie vagy telepítenie.