Stručne: Ak je váš e-shop hacknutý alebo beží na nezáplatovanej verzii PHP, ide súčasne o tri veci: údaje zákazníkov, pokladňu a vaše tržby. Obchod kontrolovane prepnite do režimu údržby, zálohujte logy od 20. 10. 2026 a vyjasnite, kto na vašom serveri aktualizuje a reštartuje PHP.
Čo je v e-shope v stávke
Obchod je viac než web. Spravuje zákaznícke účty s hashmi hesiel, dodacie a fakturačné adresy, históriu objednávok, kupóny a často aj rozhrania na skladové hospodárstvo, prepravcov a trhoviská. Kto môže na serveri spustiť kód, spravidla sa dostane k databáze a k tam uloženým kľúčom API.
Údaje o kartách zvyčajne nie sú u vás, ale u poskytovateľa platieb. To upokojí len sčasti: útočník môže do objednávkového procesu zavliecť JavaScript, ktorý odpočúva vstupy v prehliadači. Takéto skimmingové skripty si v prevádzke obchodu sotva niekto všimne, pretože objednávky prebiehajú úplne normálne.
K tomu pristupujú rozhrania. Obchod, ktorý odovzdáva objednávky do skladového hospodárstva, prepravcom a na trhoviská, ukladá prístupové kľúče k nim väčšinou v konfiguračných súboroch na serveri. Kto ich skopíruje, môže v mene obchodníka vytvárať prepravné štítky, meniť zásoby alebo zneužívať účty na trhoviskách.
Typické obchodné systémy a prečo ich PHP2Shell zasahuje
Rozšírené obchodné systémy v európskych malých a stredných podnikoch bežia na PHP: Shopware 6, WooCommerce, Magento, OXID, PrestaShop a mnohé staršie inštalácie Shopware 5. PHP2Shell (CVE-2026-109618 a CVE-2026-109619, obe CVSS 9.2) je v samotnom PHP. Útočníci nepotrebujú zákaznícky účet ani prístup správcu.
Pre obchodníkov to znamená: najnovšia aktualizácia obchodu nechráni. Rozhodujúce je, či je PHP na serveri vo verzii 8.5.12, 8.4.27, 8.3.36 alebo 8.2.35, alebo či poskytovateľ hostingu nasadil backport, a či boli potom reštartované všetky procesy PHP. Pri starých obchodoch na PHP 8.1 alebo staršom už od projektu PHP neexistujú oficiálne aktualizácie. Popri núdzovej situácii potom prichádza migrácia, ktorú nechcete robiť pod časovým tlakom v hlavnej sezóne.
Hacknutý e-shop: čo incident konkrétne znamená
Napadnutý obchod spôsobuje škody na viacerých úrovniach, ktoré sa navzájom zosilňujú:
- Tržby: Každá hodina režimu údržby stojí objednávky. Obchod, ktorý nepozorovane beží ďalej, však môže vyjsť výrazne drahšie.
- Údaje zákazníkov: Uniknuté adresy a objednávky sa používajú na cielené phishingové e-maily, ktoré pôsobia pravdivo, pretože uvádzajú skutočné objednávky.
- Viditeľnosť: Ak Google rozpozná škodlivý kód, vo výsledkoch vyhľadávania sa zobrazí varovanie. Ako sa ho zbaviť, nájdete v príručke Odstránenie varovania Google.
- Partneri: Poskytovatelia platieb a trhoviská majú vlastné pravidlá pre bezpečnostné incidenty. Kto nahlási neskoro, riskuje problémy pri vyúčtovaní.
Kto je zodpovedný: agentúra, poskytovateľ hostingu alebo obchodník?
V mnohých obchodoch otázka PHP padne medzi všetkých. Agentúra obchod postavila a spravuje pluginy, poskytovateľ hostingu prevádzkuje server a obchodník predpokladá, že sa postará jeden z nich. Pri managed hostingu záplatuje väčšinou poskytovateľ hostingu, pri vlastnom vServeri nikto automaticky.
| Úloha | Typicky zodpovedá | Overte si |
|---|---|---|
| Aktualizovať balík PHP | poskytovateľ hostingu alebo správca servera | písomné potvrdenie so stavom balíka |
| Reštartovať procesy PHP | kto spravuje server | čas reštartu |
| Obchod a pluginy | agentúra | zmluva o údržbe a prístupy |
| Informovať poskytovateľa platieb | obchodník | zmluvné oznamovacie povinnosti |
Záplata PHP nedokazuje, že sa predtým nič nestalo. Ak bol obchod napadnutý medzi 17. 10. a okamihom záplaty, môže zavlečený kód bežať ďalej. Nechajte to skontrolovať skôr, než vyhlásite, že je všetko v poriadku.
Prvé hodiny: poradie krokov pre obchodníkov
- Obchod prepnúť do režimu údržby, alebo ak to nejde, dočasne odpojiť od siete.
- Zálohovať logy webového servera, PHP a obchodu od 20. 10. 2026, kým ich nezmaže rotácia.
- Nechať si od poskytovateľa hostingu písomne potvrdiť stav balíka PHP a reštart.
- Obnoviť admin heslá, kľúče API pre platby, prepravu a trhoviská a prístupy k databáze, a to až po vyčistení.
- Skontrolovať pokladňu, platobné pluginy a vložené skripty na zmeny.
Ak existujú náznaky úniku údajov, beží 72-hodinová lehota podľa GDPR. Právne posúdenie urobíte so svojou zodpovednou osobou za ochranu údajov a prípadne s právnikom.
Ako konkrétne pomáha PHP SOS?
- Na diaľku overíme skutočný stav balíka PHP, režim prevádzky (napríklad mod_php alebo PHP-FPM) a či boli reštartované všetky workery.
- Preskúmame súbory obchodu, databázu a pokladňu na webshelly, skimmingový kód a nové admin účty a odstránime nájdený škodlivý softvér.
- Koordinujeme sa s vašou agentúrou a poskytovateľom hostingu, aby sa údržba obchodu a prevádzka servera nerozchádzali.
- Zistenia a opatrenia zdokumentujeme tak, aby ste ich mohli predložiť poskytovateľovi platieb, poisťovateľovi a zodpovednej osobe za ochranu údajov.
- Potom server spevníme (hardening) a na želanie prevezmeme priebežné monitorovanie.
Časté otázky
Musím kvôli PHP2Shell odpojiť svoj obchod od siete?
BSI (nemecký Spolkový úrad pre informačnú bezpečnosť) odporúča webové servery dočasne odpojiť od siete, ak aktualizácia PHP nie je možná okamžite. Pri obchode je často lepšou cestou režim údržby so stránkou s upozornením než chybové hlásenie. Hneď ako je PHP záplatované a všetky procesy sú reštartované, môže sa obchod znova otvoriť.
Sú v mojom obchode ohrozené údaje o kreditných kartách?
Vo väčšine obchodov nie sú údaje o kartách uložené na vlastnom serveri, ale u poskytovateľa platieb. Nebezpečný je však zmanipulovaný kód v pokladni, ktorý zachytí vstupy skôr, než sa dostanú k poskytovateľovi. Preto pri každej kontrole po útoku patrí do rozsahu aj pokladňa.
Stačí aktualizovať Shopware alebo WooCommerce?
Nie. PHP2Shell sa týka samotného PHP, nie obchodného systému. Aktualizácia obchodu zraniteľnosť neuzavrie a záplata PHP neodstráni už zavlečený škodlivý kód.
Koho musím po úniku údajov informovať?
Pri osobných údajoch pripadá do úvahy oznámenie dozornému orgánu pre ochranu údajov do 72 hodín a podľa rizika aj informovanie dotknutých osôb. K tomu pristupujú zmluvné povinnosti voči poskytovateľovi platieb a poisťovateľovi. Posúdenie v konkrétnom prípade urobíte so zodpovednou osobou za ochranu údajov a s právnikom.