Stručně: U bezpečnostní zranitelnosti PHP, jako je PHP2Shell, odpovídá za aktualizaci PHP na webhostingu poskytovatel, nikoli vy. Vaším úkolem je získat písemné potvrzení, zvolit v zákaznické administraci podporovanou verzi PHP a zkontrolovat svůj web, zda nenese stopy útoku. Záplata poskytovatele neodstraní škodlivý software, který se na váš web dostal dříve.
Situace jednoduše řečeno
PHP je programovací jazyk, na kterém běží většina webů, e-shopů a CMS, jako je WordPress. PHP2Shell označuje dvě kritické chyby v samotném PHP (CVE-2026-109618 a CVE-2026-109619). Útočníci přes ně mohou bez hesla spustit na serveru vlastní kód. BSI (německý Spolkový úřad pro informační bezpečnost) vyhlásil výstražný stupeň 3 (oranžový) a doporučuje okamžitou aktualizaci.
Na sdíleném hostingu sdílí jeden server mnoho zákazníků. Technologii pod tím, tedy operační systém, webový server a PHP, provozuje poskytovatel. Vy sami spravujete jen svůj web, databázi a přístupy. Proto aktualizaci PHP nemůžete sami nasadit a nemusíte.
Webhosting a zranitelnost PHP: kdo je odpovědný?
Rozdělení vyplývá z vaší smlouvy. U většiny tarifů platí zhruba toto rozdělení:
| Úkol | Poskytovatel | Vy jako zákazník |
|---|---|---|
| Aktualizovat balíčky PHP | ano | ne |
| Restartovat procesy PHP | ano | ne |
| Nastavit přechodné hodnoty pro celý server | ano | ne |
| Zvolit verzi PHP pro váš web | poskytuje | vybírá |
| Aktualizovat CMS, pluginy, šablony | ne | ano |
| Přístupové údaje a administrátorské účty | ne | ano |
| Zkontrolovat web na škodlivý kód | částečně | ano |
| Posouzení z hlediska ochrany osobních údajů | ne | ano |
Důležitý je poslední řádek: pokud na vašem webu dojde k incidentu s osobními údaji, odpovídáte zpravidla vy jako provozovatel, nikoli poskytovatel. Více na stránce Oznamovací povinnost podle GDPR.
Co byste měli udělat sami
1. Získat potvrzení. Zeptejte se svého poskytovatele písemně, zda jsou verze PHP ve vašem balíčku zabezpečeny proti oběma CVE, od kdy, a zda byly restartovány všechny procesy PHP. Hotový vzor najdete na stránce Zeptejte se hostingu na stav záplat. Nedivte se, pokud v zákaznické administraci dál stojí starší číslo verze, například 8.2.34: někteří poskytovatelé dodávají opravy jako backport, aniž by se číslo změnilo.
2. Zkontrolovat verzi PHP. V zákaznické administraci zjistěte, jakou verzi PHP váš web používá. PHP 8.1 a starší už od projektu PHP oficiální aktualizace nedostávají. PHP 8.2 dosáhne konce podpory 31. 12. 2026. Zda vaše CMS novější verzi snese, ověřte podle systémových požadavků výrobce, například na wordpress.org.
3. Zkontrolovat web. Dávejte pozor na neznámé administrátorské účty, neočekávaná přesměrování, cizí soubory v přístupu FTP a varování v Google Search Console. Seznam typických příznaků najdete na stránce Jsem už kompromitován?.
4. Vytvořit zálohu. Stáhněte si aktuální zálohu souborů a databáze a uložte ji odděleně. Požádejte poskytovatele také o uchování přístupových logů vašeho balíčku od 20. 10. 2026.
Po potvrzení od poskytovatele preventivně změňte hesla do zákaznické administrace, FTP/SFTP, databáze a administrátorů CMS a kde je to možné, zapněte dvoufázové přihlašování.
Co na sdíleném hostingu sami vyřešit nemůžete
Přechodná opatření doporučená php.net, například session.upload_progress.enabled=0, fungují jen tehdy, když jsou nastavena v konfiguraci serveru. Záznam v .user.ini nebo pomocí ini_set() v kódu podle php.net nestačí. Také limity paměti na úrovni cgroup a restart procesů PHP leží na poskytovateli.
Pokud poskytovatel neodpovídá nebo odpovídá jen vyhýbavě, máte tři možnosti: urgovat a stanovit lhůtu, web dočasně přepnout do režimu údržby, nebo přejít k poskytovateli s jasným stanoviskem. BSI doporučuje webové servery dočasně odpojit od sítě, pokud aktualizace není okamžitě možná.
Zkontrolujte také, zda je váš tarif ještě aktuální. Balíčky, které roky běží beze změny, někdy leží na starších generacích serverů se staršími verzemi PHP, o které poskytovatel pečuje jen omezeně. Přechod na aktuální tarif téhož poskytovatele bývá spojen s malými náklady práce a přináší novější verze PHP. Zeptejte se na to, pokud je odpověď ke stavu záplat neuspokojivá.
Pokud je web už nápadný
Záplata u poskytovatele uzavírá zranitelnost do budoucna. Neodstraní ale zadní vrátka, která útočníci zabudovali dříve, a nedokazuje, že se předtím nic nestalo. Pokud najdete nápadnosti, nemažte soubory nazdařbůh. Nejdříve zajistěte stav, aby zůstala příčina později dohledatelná.
Jak konkrétně pomáhá PHP SOS?
- S vámi sestavíme dotaz na poskytovatele a jeho odpověď technicky vyhodnotíme.
- Zkontrolujeme váš web na webshelly, cizí účty a manipulované soubory a při nálezu jej vyčistíme v rámci našeho odstranění malwaru.
- Při akutním podezření převezmeme nouzovou pomoc pro napadené weby se zajištěním důkazů.
- Pomůžeme s výběrem vhodné verze PHP a web poté otestujeme.
Časté dotazy
Musím jako zákazník hostingu aktualizovat PHP sám?
Zpravidla ne, protože PHP je na sdíleném hostingu součástí platformy poskytovatele. Verzi PHP ale často můžete zvolit v zákaznické administraci. Pokud je tam verze bez oficiálních aktualizací, měli byste ji změnit nebo se poskytovatele zeptat, jak ji zabezpečuje.
Můj web je offline. Byl jsem napaden?
Ne nutně. Někteří poskytovatelé weby preventivně odpojili od sítě, aby zranitelnost uzavřeli. Zeptejte se poskytovatele na důvod a nechte si potvrdit, zda existují náznaky útoku na váš balíček.
Mohu přechodná opatření nastavit sám v .user.ini?
U session.upload_progress.enabled php.net výslovně uvádí, že .user.ini a ini_set() nestačí. Toto nastavení musí provést poskytovatel v konfiguraci serveru.
Co bych měl mít od poskytovatele písemně?
Potvrzení, že verze PHP ve vašem balíčku jsou zabezpečeny proti CVE-2026-109618 a CVE-2026-109619, od kdy to platí a že procesy PHP byly restartovány. Tuto odpověď uchovejte spolu se svými dokumenty.