Stručně: Aktuální zranitelnost Magenta se jmenuje PHP2Shell a není v Magentu, ale v PHP. Záplata Magenta ji neuzavře. Po aktualizaci PHP s restartem byste měli zkontrolovat app/etc/env.php, databázi na skimmery a seznam účtů správců.
Co PHP2Shell znamená pro e-shopy na Magentu
Magento Open Source a Adobe Commerce jsou velké aplikace v PHP, které obvykle běží s PHP-FPM. Zranitelnosti CVE-2026-109618 a CVE-2026-109619 umožňují podle týmu PHP spuštění škodlivého kódu bez přihlášení. Zda je samotný e-shop aktuální, přitom nehraje roli.
E-shopy na Magentu jsou už léta oblíbeným cílem skimmingu platebních karet, při kterém se zadané údaje v pokladně odposlouchávají. PHP2Shell k tomu otevírá další cestu. Palo Alto Networks napočítalo více než 22,6 milionu exponovaných, potenciálně zranitelných instancí PHP; které e-shopy mezi nimi jsou, není známo.
Zranitelnost Magenta: jak správně zjistit stav PHP
Magento verzi PHP v administraci výrazně nezobrazuje. Stav proto ověřte v hostingovém panelu pro doménu nebo si jej nechte potvrdit poskytovatelem hostingu. php -v na příkazové řádce ukazuje jen PHP pro CLI, s nímž běží bin/magento a úlohy cron. Webové PHP přes FPM může být jiná verze a záplatovány musí být obě.
Opravené verze upstreamu jsou 8.5.12, 8.4.27, 8.3.36 a 8.2.35, backporty distribucí mohou nést starší čísla. Které verze PHP vaše verze Magenta podporuje, ověříte podle systémových požadavků v dokumentaci Adobe (experienceleague.adobe.com). U Adobe Commerce na infrastruktuře Adobe se na stav zeptejte Adobe nebo svého provozovatele. Návod krok za krokem nabízí článek Jak správně ověřit verzi PHP a stav záplaty.
Kde se škodlivý kód v Magentu nachází
| Místo | Obsah | Bod kontroly |
|---|---|---|
app/etc/env.php |
Databáze, šifrovací klíč, cesta do administrace | Datum změny, hodnoty při podezření obnovit |
pub/ |
Kořen dokumentů, pub/media, pub/static |
Soubory PHP ve složkách media a static |
app/code/ |
Vlastní moduly | Neznámé moduly, změněné soubory |
vendor/ |
Balíčky Composeru, i rozšíření | Odchylky od lockfile |
generated/, var/ |
Vygenerovaný kód, cache, logy | Zálohovat logy, kód vytvořit znovu |
| Databáze | Konfigurace, bloky CMS, uživatelé administrace | Cizí skripty, noví admini |
Skimmery bývají v Magentu často v databázi, například v nastavení doplňkových skriptů v hlavičce nebo patičce stránky a v blocích CMS. Prostá kontrola souborů je přehlédne. Neškodné čtecí přístupy pomohou při prvním pohledu (prefix tabulek podle instalace):
bin/magento info:adminuri
bin/magento module:status
SELECT username, email, created FROM admin_user;
SELECT path, value FROM core_config_data WHERE path LIKE 'design/%' AND value LIKE '%<script%';
Vyčištěná pokladna neznamená, že žádná data neunikla. Zálohujte logy od 20. 10. 2026 a výpisy databáze dříve, než skripty odstraníte. Jen tak lze později zjistit, od kdy a které objednávky byly zasaženy.
Administrace a rozšíření
Cesta do administrace je v Magentu volně volitelná a je uvedena v env.php. Obtížně uhodnutelná cesta je užitečná, ale nenahrazuje dvoufázové přihlášení ani omezení na známé sítě. Uživatele administrace a jejich role pravidelně kontrolujte, stejně jako integrace a tokeny API.
Rozšíření třetích stran je u Magenta mnoho: platební metody, napojení na ERP, vyhledávací a marketingové moduly. Každé přináší kód, který se musí při upgradech PHP ověřit. Pravidelně používejte composer audit a vypnuté moduly odstraňte úplně.
Pamatujte i na procesy na pozadí. Magento pracuje s úlohami cron a často s konzumenty front, kteří běží jako samostatné procesy PHP z příkazové řádky. Po aktualizaci PHP se musí restartovat stejně jako PHP-FPM. Po změně hlavní verze PHP byste také měli nechat znovu sestavit vygenerovaný kód v generated/ a statické soubory a e-shop projít v testovacím prostředí, než se obnoví ostrý provoz. Jak se restart povede čistě, popisuje článek Restart PHP-FPM a všech workerů.
Co aktualizace Magenta zvládne a co ne
Vydání Magenta nebo bezpečnostní záplata od Adobe uzavře chyby v kódu e-shopu. Nezáplatuje PHP, nerestartuje procesy FPM, neodstraní skripty z databáze a nesmaže cizí účty správců. Pokud už byl kód spuštěn, je nutné šetření. Jak rozpoznat zadní vrátka, vysvětluje článek Jak rozpoznat a odstranit webshelly.
Pro obchodníky s platbami kartou platí navíc: zkontrolujte pravidla svého poskytovatele plateb pro bezpečnostní incidenty a před obnovením klíčů se s ním dohodněte. Zda je nutné oznámení dozorovému úřadu pro ochranu osobních údajů, ujasněte se svým pověřencem pro ochranu osobních údajů nebo s právníkem.
Jak konkrétně pomáhá PHP SOS?
- Ujasníme webové a CLI PHP vašeho serveru s Magentem a necháme si potvrdit záplatu a restart.
- Logy, soubory a databázi zálohujeme dohledatelně, podle potřeby prostřednictvím naší IT forenzní analýzy.
- Kontrolujeme
env.php,pub/, moduly, konfigurační tabulky, bloky CMS a účty správců. - Čistíme, obnovujeme klíče a přístupy a dokumentujeme období možného zasažení pro ochranu osobních údajů a poskytovatele plateb.
Časté dotazy
Uzavře bezpečnostní záplata Magenta i PHP2Shell?
Ne. Záplaty Magenta opravují chyby v kódu e-shopu. PHP2Shell je v interpretu PHP na serveru a uzavře se jen aktualizací PHP nebo potvrzeným backportem s restartem všech procesů.
Kde útočníci v Magentu skrývají skimmery platebních karet?
Často ne v souborech, ale v databázi, například v nastavení doplňkových skriptů v hlavičce stránky nebo v blocích CMS. Po podezření proto vždy patří ke kontrole i databáze.
Kdo záplatuje PHP u Adobe Commerce v cloudu?
Záleží na vaší smlouvě a vašem prostředí. Zeptejte se Adobe nebo svého provozovatele písemně na stav PHP a restart. Vlastní rozšíření a obsah databáze zůstávají ve vaší odpovědnosti.
Proč je app/etc/env.php tak důležitý?
Soubor obsahuje přístup k databázi, šifrovací klíč a cestu do administrace. Kdo jej mohl číst, může dešifrovat šifrované hodnoty a najít administraci. Při podezření by se tyto hodnoty měly obnovit.