Stručně: U cloudových a PaaS poskytovatelů záplatuje automaticky ne vždy poskytovatel. Spravuje-li běhové prostředí PHP, aktualizuje ho, často však až s dalším nasazením. Sestavujete-li image nebo buildy sami nebo provozujete platformu sami, musíte je sestavit a nasadit znovu. Rozhodující je vždy běhové prostředí, které váš web právě obsluhuje.
Aktualizace PHP u PaaS: komu patří běhové prostředí?
Platformní služby, odborně PaaS (Platform as a Service), snímají z firem provoz serverů. Nahrajete kód, platforma jej sestaví a provozuje. U PHP2Shell z toho vzniká typická nejistota: kdo vlastně má PHP aktualizovat?
Vercel to ve svém bulletinu k PHP2Shell shrnuje stručně: Aktualizace lokálního vývojového prostředí, kódu aplikace nebo pluginů nestačí. Rozhodující je běhové prostředí PHP nasazení, které skutečně odpovídá na požadavky. Zda je toto prostředí zaplatované, závisí na tom, kdo ho poskytuje a kdy bylo naposledy sestaveno.
Čtyři provozní modely v porovnání
Označení u poskytovatelů se liší. Pro otázku záplat lze většinu nabídek přiřadit k jednomu z těchto modelů:
| Model | Kdo aktualizuje PHP? | Co musíte udělat |
|---|---|---|
| Běhové prostředí spravované poskytovatelem | poskytovatel | Získat potvrzení, příp. nasadit znovu, aby se nové prostředí uplatnilo |
| Běhové prostředí založené na buildu (buildpack) | poskytovatel připraví novou verzi, váš build ji zafixuje | Spustit nový build, zkontrolovat verzi v protokolu buildu |
| Vlastní image kontejneru | vy | Image s opraveným PHP znovu sestavit a nasadit |
| Samostatně provozovaná platforma | vy, pro platformu i aplikace | Zaplatovat platformu a každou aplikaci zvlášť |
Mnoho firem používá více modelů současně, například spravované běhové prostředí pro web a vlastní kontejnery pro interní nástroje. Každá aplikace proto potřebuje vlastní odpověď.
Past se skrývá ve slově „spravované“. I když poskytovatel prostředí udržuje, již nasazená aplikace často dál běží se stavem, s nímž byla sestavena. Nová verze se pak uplatní až při dalším buildu nebo nasazení. Některé platformy navíc ponechávají starší nasazení nebo náhledová prostředí dostupná na vlastních adresách. Ptejte se proto nejen, zda poskytovatel zaplatoval, ale také od kdy vaše běžící instance záplatu používají a co se děje se starými nasazeními.
Co říkají Vercel a Coolify k PHP2Shell
Dva poskytovatelé zveřejnili svá upozornění. Jsou poučná, protože jasně pojmenovávají hranice vlastních ochranných opatření.
Vercel podle vlastního bulletinu aktivoval před zveřejněním ochranná pravidla ve své Web Application Firewall (WAF), tedy filtru webových požadavků. Platí automaticky pro funkce PHP na Vercelu a pro požadavky, které Vercel předává externím serverům PHP. Zároveň Vercel vyžaduje, aby bylo běhové prostředí PHP okamžitě aktualizováno na opravenou verzi. Nasazení v kontejnerech se mají znovu sestavit s aktualizovaným základním image PHP a znovu nasadit. Požadavky, které Vercel obcházejí a jdou přímo na externí server PHP, WAF nepokrývá.
Coolify, platforma, kterou lze provozovat vlastními silami, byla podle vlastního advisory sama postižena: všechny větve verze 4. Jako první opravené stavy Coolify uvádí 4.0.1, 4.1.3, 4.2.1, 4.3.24 a 4.4.7 a doporučuje 4.4.7. Důležitý je dodatek: Aktualizace Coolify neaktualizuje aplikace PHP, které přes něj provozujete. Jejich běhová prostředí nebo image musíte aktualizovat zvlášť a znovu sestavit nebo nasadit. Podle Coolify to platí i pro zákazníky Coolify Cloud a také za Cloudflare, protože pravidla Cloudflare kontrolují jen provoz, který přes Cloudflare prochází.
Co pravidla Cloudflare dokážou, zařazuje článek Ochranná pravidla Cloudflare proti PHP2Shell.
Jak ověřit běhové prostředí, které skutečně obsluhuje
Následující kroky fungují nezávisle na poskytovateli. Míří na důkaz, nikoli na pocit.
- Vypsat všechna prostředí: produkce, staging, náhledová nasazení a služby na pozadí, jako jsou workery front. Každé prostředí může mít jiné běhové prostředí.
- Přečíst verzi běhového prostředí pro každé prostředí: v konzoli poskytovatele, v protokolu buildu nebo v konfiguračním souboru projektu.
- Zkontrolovat datum posledního nasazení: Pokud je před 21. 10. 2026, běží s velkou pravděpodobností stále staré běhové prostředí, pokud poskytovatel výslovně nepotvrdí něco jiného.
- Nahlédnout do běžící instance: Nabízí-li platforma konzoli, zobrazí následující příkaz verzi instance.
- Zahrnout externí servery PHP: Servery, na které platforma předává požadavky, potřebují vlastní aktualizaci a neměly by být dostupné přímo z internetu.
# V konzoli běžící instance (pokud ji poskytovatel nabízí)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
Očekává se 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35, případně backport potvrzený poskytovatelem. Mějte na paměti, že příkazová řádka instance nemusí vždy používat totéž běhové prostředí jako webový proces. Pro kontrolu nezakládejte veřejně dostupný soubor phpinfo. Jak správně vykládat číslo verze a stav backportů, popisuje článek Kontrola verze PHP a stavu záplat.
Nové nasazení neodstraní škodlivý software, který se dříve dostal do trvalých úložišť, jako jsou svazky uploadů nebo databáze. Tyto oblasti zkontrolujte zvlášť.
Odpovědnost zapsat písemně
PHP2Shell ukazuje, jak nejasná je často hranice mezi platformou a zákazníkem. U každé aplikace si zaznamenejte, kdo poskytuje běhové prostředí, kdo při bezpečnostních oznámeních sestavuje znovu a jak poskytovatel oznamuje záplaty. K tomu patří také, kdo má v případě spěchu přístup do konzole platformy a kdo smí mimo pracovní dobu spustit nový build.
Pro vlastní dokumentaci stačí krátká tabulka pro každou aplikaci: platforma, provozní model, větev PHP, datum posledního buildu, odpovědná osoba. Kdo bude mít tento seznam při příštím oznámení po ruce, ušetří dny, které mnoho týmů po 21. říjnu strávilo hledáním. U aplikací v kontejnerech k tomu patří, kdo udržuje základní image; souvislosti vysvětluje PHP v kontejnerech.
Pro spravované servery bez povahy PaaS platí podobné otázky, které jsme shrnuli v článku Spravovaný server: ujasnit odpovědnost.
Jak konkrétně pomáhá PHP SOS?
- Přiřadit: Každou vaši aplikaci přiřadíme k provoznímu modelu a ujasníme, kdo poskytuje běhové prostředí PHP.
- Doložit: Pro každé prostředí ověříme běhové prostředí, datum buildu a nasazení a výsledek zdokumentujeme.
- Znovu sestavit a nasadit: Prostřednictvím PHP Patch Service aktualizujeme image a buildy a kontrolovaně je nasadíme.
- Uzavřít mezery: Ověříme, zda jsou externí servery PHP dostupné přímo, a přístup omezíme.
Časté dotazy
Záplatuje můj poskytovatel PaaS PHP automaticky?
Záleží na modelu. Spravuje-li běhové prostředí poskytovatel, aktualizuje ho, často však až pro nová nasazení. Sestavujete-li image nebo buildy sami, musíte je sestavit a nasadit znovu. Nechte si stav pro svou aplikaci potvrdit.
Stačí WAF mého poskytovatele platformy proti PHP2Shell?
Ne. Vercel a Coolify výslovně píší, že ochranná pravidla nenahrazují aktualizaci běhového prostředí PHP. Působí navíc jen na provoz, který prochází platformou.
Musím po záplatě nasadit znovu?
Často ano. Vercel u nasazení v kontejnerech uvádí nové sestavení s aktualizovaným základním image PHP a nové nasazení. U platforem založených na buildech se běhové prostředí zafixuje při buildu; záplatu převezme až nový build.
Používám Coolify. Stačí aktualizace Coolify?
Ne. Podle advisory Coolify aktualizace upraví jen samotný Coolify. Běhová prostředí PHP nebo image kontejnerů vašich aplikací musíte aktualizovat zvlášť a znovu sestavit nebo nasadit.