PHP2Shell: zranitelnost PHP, která ohrožuje váš PrestaShop e-shop

20. října se objevilo varování, které uvedlo do napětí půlku internetu: dvě vážné zranitelnosti v PHP, jazyku, na kterém běží váš e-shop na PrestaShopu, dovolují cizímu člověku převzít kontrolu nad serverem bez jména a hesla. Říká se jim PHP2Shell. PHP vydalo opravu 21. října a co máte udělat, záleží na jediné věci: na verzi PHP, na které váš e-shop běží.

Vysvětlíme to bez odborných výrazů: co se stalo, jak zjistit, jestli se vás to týká, co udělat dnes a jak zjistit, jestli váš hosting už opravu nainstaloval.

Co je PHP2Shell a proč je tak vážný?

PHP je motor, na kterém stojí PrestaShop, WordPress, Magento a většina e-shopů a webů na světě. Obě zranitelnosti, vedené jako CVE-2026-109618 a CVE-2026-109619, mají hodnocení závažnosti 9,2 z 10. V praxi to znamená, že kdo je umí zneužít, může na vašem serveru spustit cokoli: nechat tam zadní vrátka, ukrást data vašich zákazníků nebo do e-shopu podstrčit falešnou captchu, jako je ClickFix.

Od jiných varování se liší tím, že útok nevede přes PrestaShop ani přes žádný modul. Odehraje se v PHP, ještě než váš e-shop návštěvu vůbec přečte. Je jedno, jak dobře se o něj staráte: pokud je PHP na serveru zranitelné, je zranitelný i e-shop.

A informace unikly s předstihem. Bezpečnostní firma Sansec uvádí, že spolu s varováním se objevil snímek už hotového útočného nástroje, a očekávala hromadné útoky hned po zveřejnění opravy. Podle stejného zdroje Cloudflare už zaznamenal první pokusy a nasadil pravidla, která je mají zastavit.

Týká se to mého e-shopu na PrestaShopu?

Nejspíš ano. PHP ve svém bezpečnostním upozornění považuje za ohroženou každou instalaci, která obsluhuje webové stránky, ať ji server spouští jakkoli, a nejvyšší riziko vidí u serverů Apache s mod_php, kde už existuje předvedený útok, který funguje bez jména a hesla. Sansec mluví o každém serveru s PHP 5.4 nebo novějším, což je v praxi každý e-shop na PrestaShopu, který dnes běží.

Otázka, na které opravdu záleží, je jiná: dostanete opravu? PHP chybu opravilo ve verzích 8.2.35, 8.3.36, 8.4.27 a 8.5.12. Pro staré verze, které už nemají oficiální podporu, zveřejnilo PHP záplatu bez nového vydání a během jednoho až dvou dnů z ní panely a systémy, které hostingy používají, udělaly běžnou aktualizaci: cPanel a CloudLinux od PHP 5.2 do 8.1; DirectAdmin, Ubuntu, Red Hat, AlmaLinux a repozitář Remi ve verzích 7.4 až 8.1, které ještě udržují. A každá verze PrestaShopu funguje jen s určitými verzemi PHP:

• PrestaShop 1.6: funguje s PHP 5.6 až 7.1. Záplata existuje, pokud váš hosting používá cPanel nebo CloudLinux; jinde jen v rámci placené rozšířené podpory, například od TuxCare nebo Zend.
• PrestaShop 1.7: nejvýše PHP 7.4. Záplatované 7.4 už je skoro ve všech panelech: stačí, aby ho hosting nainstaloval.
• PrestaShop 8: nejvýše PHP 8.1. Stejně jako u 1.7: záplatované 8.1 už existuje a záleží na vašem hostingu.
• PrestaShop 9: funguje s PHP 8.1 až 8.4. S PHP 8.2 nebo novějším dostává oficiální aktualizaci; na 8.1 stačí zvýšit verzi PHP.

Jinými slovy: skoro každý e-shop dnes může běžet na PHP bez této chyby. Pokud to ale není PrestaShop 9, záleží na tom, jestli hosting záplatu nainstaloval, a protože se číslo verze nemění, na první pohled to nepoznáte: musíte se ho zeptat. Je to navíc nouzová záplata: PHP 8.1 a starší nemají oficiální podporu, takže při další chybě budete zase záviset na tom, že ji někdo opraví na vlastní pěst.

Jak zjistit, jakou verzi máte

Přihlaste se do administrace e-shopu a otevřete Nástroje → Informace. Uvidíte tam verzi PrestaShopu a o kousek níž verzi PHP. S těmi dvěma čísly už víte, do které skupiny patříte.

Co udělat ještě dnes a v jakém pořadí

1. Zjistěte obě verze, PrestaShopu i PHP, jak jsme popsali výše.
2. Udělejte úplnou zálohu, souborů i databáze, a uložte ji mimo server. Když se něco stane, je to jediné, co vám dovolí vrátit se zpět.
3. Pokud je váš e-shop na PrestaShopu 9, požádejte hosting, ať aktualizuje PHP na verzi 8.2.35, 8.3.36, 8.4.27 nebo 8.5.12 či novější, nebo to udělejte sami v administraci hostingu, pokud vám dovolí verzi vybrat. Pokud jste na PHP 8.1, využijte příležitost a přejděte na 8.3 nebo 8.4.
4. Pokud používáte Cloudflare, zkontrolujte, že je obláček u vaší domény oranžový: provoz tak projde jeho pravidly dřív, než se dostane k vašemu serveru. Moc to ale nepomůže, pokud je adresa vašeho serveru známá a přijímá návštěvy odkudkoli, takže požádejte svého technika, ať ho otevře jen pro Cloudflare.
5. Pokud je váš e-shop 1.6, 1.7 nebo 8, zeptejte se hostingu, jestli už nainstaloval záplatu na PHP2Shell pro vaši verzi PHP. Pokud ne, požádejte svého technika o nouzová opatření, která popisujeme níže. A stanovte si termín aktualizace na PrestaShop 9: tak se vrátíte k PHP s oficiální podporou.

Přepnutí e-shopu do režimu údržby v administraci vás tentokrát neochrání: PHP návštěvu přečte dřív, než PrestaShop rozhodne, že ukáže stránku údržby.

A co když můj hosting záplatu nemá?

PHP navrhuje několik nastavení serveru, která některé cesty útoku uzavřou, a upozorňuje, že e-shop bezpečným neudělají: to dokáže jen aktualizace. Sansec přidává další nouzové opatření: zablokovat na serveru typ odesílání, kterým putují soubory nahrávané na web. Má to svou cenu: dokud platí, nikdo nemůže do vašeho e-shopu nahrávat soubory. Vy ne fotky nového produktu a vaši zákazníci ne přílohu v kontaktním formuláři. E-shop přitom dál normálně prodává.

Získáte tím pár dní, nic víc: buď hosting záplatu nainstaluje, nebo přejdete k takovému, který ji má. A až vyjde další chyba v PHP —a vyjde—, bude na tom váš e-shop zase záviset, protože PHP 8.1 a starší už nemají oficiální podporu.

Jaké PHP podporuje která verze PrestaShopu a dokdy dostává záplaty, najdete v jedné tabulce v článku jaká verze PHP pro PrestaShop.

Vyplatí se teď přejít na novější PrestaShop?

Je to otázka, která se vždycky odkládá, protože e-shop funguje. PHP2Shell ukazuje, co se stane, když se odkládá příliš dlouho: den, kdy problém přijde, si nevybíráte vy, a jestli se k vám oprava dostane, záleží na jiných.

Přechod na PrestaShop 9 vás dostane na PHP, které bude dostávat záplaty ještě roky. Dělá se bez zavření e-shopu, ponecháte si produkty, zákazníky, objednávky i pozice v Googlu a u malého e-shopu stojí od 690 €. Celé to popisujeme v článku přechod z PrestaShopu 1.7 nebo 1.6 na 9 a na naší stránce o migraci PrestaShopu 1.6 a 1.7 na 9.

A pokud nechcete taková upozornění hlídat sami, k tomu slouží údržba PrestaShopu: hlídáme váš obchod, udržujeme jeho moduly aktuální, a pokud běží na serveru BK Modules, i PHP, aby vás takové upozornění nezaskočilo.

Potřebujete pomoc ještě dnes?

Pokud nevíte, do které skupiny patříte, pokud vám hosting neodpovídá nebo pokud je váš e-shop na verzi 1.6, 1.7 nebo 8 a chcete se z ní dostat, napište nám svou verzi PrestaShopu a PHP. Řekneme vám, co udělat ještě dnes, a pokud bude potřeba, dáme vám pevnou cenu za přechod na PrestaShop 9.

Chci povýšit svůj e-shop

Pro váš technický tým

Opravené verze: 8.2.35, 8.3.36, 8.4.27 a 8.5.12. Pro 7.4, 8.0 a 8.1 zveřejňuje PHP minimální opravu ve zdrojovém kódu, odkázanou z bezpečnostního oznámení, bez nového vydání. Záplatované balíčky si ponechávají číslo verze, takže je php -v nerozliší: rozhoduje revize balíčku (rpm -q, dpkg -l). Opravené revize: cPanel EasyApache 4 ea-php74 7.4.33-19, ea-php80 8.0.30-12, ea-php81 8.1.34-5; CloudLinux ea-php / alt-php 5.2–8.5 (21–22/10); Remi 7.4.33-31, 8.0.30-21, 8.1.34-6; Ubuntu 22.04 8.1.2-1ubuntu2.28. Částečná opatření, která uvádí PHP, patří do php.ini, do poolu PHP-FPM (php_admin_value) nebo do konfigurace serveru, nikdy přes ini_set() ani .user.ini, s restartem všech procesů:

; CVE-2026-109618
memory_limit = -1
post_max_size = 32M   ; 8M, pokud se nenahrávají soubory
; CVE-2026-109619
session.upload_progress.enabled = 0
; pouze v PHP 8.5
fatal_error_backtraces = 0

PHP žádá, aby se memory_limit nenahrazoval systémovými limity (RLIMIT_AS, RLIMIT_DATA). Opatření Sansecu, blokování multipart/form-data (rozbije veškeré nahrávání souborů, včetně administrace), v Apache:

RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

V Nginxu:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

S Cloudflare omezit port 443 zdrojového serveru na jeho rozsahy IP; jinak útok dorazí přímo na IP serveru.