Stručně: Pokud je váš e-shop napaden nebo běží na nezáplatované verzi PHP, jde současně o tři věci: data zákazníků, pokladnu a vaše tržby. Převeďte e-shop řízeně do režimu údržby, zajistěte logy od 20. 10. 2026 a ujasněte si, kdo na vašem serveru PHP aktualizuje a restartuje.
Co je v e-shopu v sázce
E-shop je víc než web. Spravuje zákaznické účty s hashi hesel, doručovací a fakturační adresy, historii objednávek, poukazy a často také rozhraní na skladový systém, přepravce a tržiště. Kdo může na serveru spouštět kód, se zpravidla dostane k databázi a k tam uloženým klíčům API.
Data karet obvykle neleží u vás, ale u poskytovatele plateb. To uklidňuje jen zčásti: útočník může do objednávkového procesu vložit JavaScript, který čte zadávané údaje v prohlížeči. Takové skimmingové skripty si v provozu e-shopu téměř nikdo nevšimne, protože objednávky procházejí zcela normálně.
K tomu přistupují rozhraní. E-shop, který předává objednávky skladovému systému, přepravcům a tržištím, ukládá přístupové klíče k nim většinou do konfiguračních souborů na serveru. Kdo je zkopíruje, může jménem obchodníka vytvářet přepravní štítky, měnit zásoby nebo zneužívat účty na tržištích.
Typické e-shopové systémy a proč je PHP2Shell zasahuje
Rozšířené e-shopové systémy ve středních firmách v Evropě běží na PHP: Shopware 6, WooCommerce, Magento, OXID, PrestaShop a mnoho starších instalací Shopware 5. PHP2Shell (CVE-2026-109618 a CVE-2026-109619, každá CVSS 9.2) je v samotném PHP. Útočníci nepotřebují zákaznický účet ani administrátorský přístup.
Pro obchodníky to znamená: nejnovější aktualizace e-shopu nechrání. Rozhodující je, zda je na serveru PHP ve verzi 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35, nebo zda hosting nasadil backport, a zda byly poté restartovány všechny procesy PHP. U starých e-shopů na PHP 8.1 nebo starším už od projektu PHP nevycházejí oficiální aktualizace. Vedle nouzové situace pak stojí před vámi migrace, kterou nechcete řešit pod tlakem v hlavní sezoně.
Napadený e-shop: co incident konkrétně znamená
Napadený e-shop působí škody na několika úrovních, které se vzájemně posilují:
- Tržby: Každá hodina režimu údržby stojí objednávky. E-shop, který nepozorovaně běží dál, však může být výrazně dražší.
- Data zákazníků: Uniklé adresy a objednávky se používají pro cílené phishingové e-maily, které působí věrohodně, protože uvádějí skutečné objednávky.
- Viditelnost: Pokud Google rozpozná škodlivý kód, objeví se ve výsledcích vyhledávání varování. Jak se ho zbavit, najdete v poradně Odstranění varování Google.
- Partneři: Poskytovatelé plateb a tržiště mají vlastní pravidla pro bezpečnostní incidenty. Kdo hlásí příliš pozdě, riskuje potíže při vyúčtování.
Kdo je odpovědný: agentura, hosting, nebo obchodník?
U mnoha e-shopů otázka PHP padne mezi židle. Agentura e-shop postavila a spravuje pluginy, hosting provozuje server a obchodník předpokládá, že se o to stará jeden z nich. U spravovaného hostingu záplatuje většinou poskytovatel, u vlastního vServeru automaticky nikdo.
| Úkol | Typicky odpovídá | Ověřte si |
|---|---|---|
| Aktualizovat balíček PHP | hosting nebo správce serveru | písemné potvrzení se stavem balíčku |
| Restartovat procesy PHP | kdo server spravuje | čas restartu |
| E-shop a pluginy | agentura | smlouva o údržbě a přístupy |
| Informovat poskytovatele plateb | obchodník | smluvní oznamovací povinnosti |
Záplata PHP nedokazuje, že se předtím nic nestalo. Pokud byl e-shop napaden mezi 17. 10. a okamžikem záplaty, může vložený kód dál běžet. Nechte to zkontrolovat, než vyhlásíte odvolání poplachu.
První hodiny: pořadí kroků pro obchodníky
- Přepnout e-shop do režimu údržby, nebo pokud to nejde, dočasně ho odpojit od sítě.
- Zajistit logy webového serveru, PHP a e-shopu od 20. 10. 2026, než je smaže rotace.
- Nechat si u hostingu písemně potvrdit stav balíčku PHP a restart.
- Obnovit administrátorská hesla, klíče API pro platby, dopravu a tržiště i přístupy k databázi, a to až po vyčištění.
- Zkontrolovat pokladnu, platební pluginy a vložené skripty na změny.
Pokud existují náznaky úniku dat, běží 72hodinová lhůta podle GDPR. Právní posouzení provedete s pověřencem pro ochranu osobních údajů a případně s právníkem.
Jak konkrétně pomáhá PHP SOS?
- Na dálku ověřujeme skutečný stav balíčku PHP, provozní režim (například mod_php nebo PHP-FPM) a zda byli restartováni všichni workeři.
- Zkoumáme soubory e-shopu, databázi a pokladnu na webshelly, skimmingový kód a nové administrátorské účty a odstraňujeme nalezený škodlivý software.
- Koordinujeme se s vaší agenturou a hostingem, aby údržba e-shopu a provoz serveru nešly mimo sebe.
- Zjištění a opatření dokumentujeme tak, abyste je mohli předložit poskytovateli plateb, pojišťovně a pověřenci pro ochranu osobních údajů.
- Poté server zabezpečíme (hardening) a na přání převezmeme průběžné sledování.
Časté dotazy
Musím e-shop kvůli PHP2Shell odpojit od sítě?
BSI (německý spolkový úřad pro informační bezpečnost) doporučuje webové servery dočasně odpojit od sítě, pokud aktualizace PHP není okamžitě možná. U e-shopu je často lepší cestou režim údržby s informační stránkou než chybové hlášení. Jakmile je PHP záplatované a všechny procesy jsou restartované, může e-shop znovu otevřít.
Jsou data platebních karet v mém e-shopu ohrožena?
Ve většině e-shopů data karet neleží na vlastním serveru, ale u poskytovatele plateb. Nebezpečný je však zmanipulovaný kód v pokladně, který zachytí zadané údaje dříve, než se dostanou k poskytovateli. Proto patří pokladna při každé kontrole po útoku k povinnému rozsahu.
Stačí aktualizovat Shopware nebo WooCommerce?
Ne. PHP2Shell se týká samotného PHP, ne e-shopového systému. Aktualizace e-shopu zranitelnost neuzavře a záplata PHP neodstraní již vložený škodlivý kód.
Koho musím po úniku dat informovat?
U osobních údajů přichází v úvahu hlášení dozorovému úřadu pro ochranu osobních údajů do 72 hodin, podle rizika také informování dotčených osob. K tomu přistupují smluvní povinnosti vůči poskytovateli plateb a pojišťovně. Posouzení v konkrétním případě provedete s pověřencem pro ochranu osobních údajů a právníkem.