Накратко: Актуалната уязвимост на Magento се казва PHP2Shell и не е в Magento, а в PHP. Пач на Magento не я затваря. След актуализацията на PHP с рестартиране проверете app/etc/env.php, базата данни за скимъри и списъка с админ акаунти.
Какво означава PHP2Shell за магазини на Magento
Magento Open Source и Adobe Commerce са големи PHP приложения, които най-често работят с PHP-FPM. Уязвимостите CVE-2026-109618 и CVE-2026-109619 позволяват според екипа на PHP изпълнение на злонамерен код без вход в системата. Дали самият магазин е актуален, няма значение за това.
Магазините на Magento са от години предпочитана цел на скимване на кредитни карти, при което въведеното на касата се чете. PHP2Shell отваря за това още един път. Palo Alto Networks преброи повече от 22,6 милиона изложени, потенциално уязвими PHP инстанции; кои магазини са сред тях, не е известно.
Уязвимост на Magento: как да установите правилно състоянието на PHP
Magento не показва версията на PHP на видно място в администрацията. Проверете състоянието затова в хостинг панела за домейна или го поискайте като потвърждение от хостинг доставчика. php -v в командния ред показва само PHP за командния ред, с който работят bin/magento и cron задачите. Уеб PHP през FPM може да е друга версия и двете трябва да са пачнати.
Поправените версии на оригиналния проект са 8.5.12, 8.4.27, 8.3.36 и 8.2.35, backport-овете на дистрибуциите могат да носят по-стари номера. Кои версии на PHP поддържа Вашата версия на Magento, проверете според системните изисквания в документацията на Adobe (experienceleague.adobe.com). При Adobe Commerce на инфраструктурата на Adobe питайте Adobe или Вашия оператор за състоянието. Ръководство стъпка по стъпка предлага страницата Как да проверите правилно PHP версията и състоянието на пача.
Къде седи злонамереният код в Magento
| Място | Съдържание | Какво да проверите |
|---|---|---|
app/etc/env.php |
база данни, ключ за криптиране, път до администрацията | дата на промяна, при подозрение сменете стойностите |
pub/ |
коренова директория, pub/media, pub/static |
PHP файлове в папките за медия и статични файлове |
app/code/ |
собствени модули | непознати модули, променени файлове |
vendor/ |
пакети на Composer, и разширения | отклонения от Lockfile |
generated/, var/ |
генериран код, кеш, логове | запазете логовете, генерирайте кода наново |
| База данни | конфигурация, CMS блокове, админ потребители | чужди скриптове, нови админи |
Скимърите в Magento често лежат в базата данни, например в настройките за допълнителни скриптове в заглавната или долната част на страницата и в CMS блокове. Обикновено сканиране на файлове ги пропуска. Безопасни достъпи само за четене помагат за първия поглед (префиксът на таблиците зависи от инсталацията):
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%';
Почистената каса не означава, че не са изтекли данни. Запазете логовете от 20.10.2026 г. нататък и изгребванията от базата данни, преди да премахнете скриптове. Само така по-късно може да се установи от кога и кои поръчки са засегнати.
Административна зона и разширения
Административният път в Magento се избира свободно и е записан в env.php. Труден за налучкване път е разумен, но не заменя двуфакторното удостоверяване и ограничаването до познати мрежи. Проверявайте редовно админ потребителите и техните роли, както и интеграциите и API токените.
Разширенията от трети доставчици са при Magento многобройни: начини на плащане, ERP интеграции, модули за търсене и маркетинг. Всяко носи код, който трябва да се проверява при надграждане на PHP. Ползвайте composer audit редовно и премахвайте напълно изключените модули.
Мислете и за фоновите процеси. Magento работи с cron задачи и често с consumer-и на опашки, които тичат като отделни PHP процеси през командния ред. След актуализацията на PHP те трябва да се рестартират също като PHP-FPM. След смяна на основната версия на PHP трябва освен това да изградите наново генерирания код в generated/ и статичните файлове и да изпробвате магазина в тестова среда, преди да възобновите работата на живо. Как рестартирането се прави чисто, описва Рестартиране на PHP-FPM и на всички worker процеси.
Какво може актуализацията на Magento и какво не
Издание на Magento или пач за сигурност от Adobe затваря грешки в кода на магазина. Той не пачва PHP, не рестартира FPM процеси, не премахва скриптове от базата данни и не изтрива чужди админ акаунти. Ако вече е изпълняван код, е нужно проучване. Как да разпознаете задни вратички, обяснява Разпознаване и премахване на уеб шелове.
За търговци с плащане с карта важи допълнително: проверете изискванията на Вашия платежен доставчик за инциденти със сигурността и се съгласувайте с него, преди да подновявате ключове. Дали е нужно уведомяване на надзорния орган по защита на данните, изяснете с Вашето длъжностно лице по защита на данните или с адвокат.
Как помага PHP SOS конкретно?
- Изясняваме уеб PHP и PHP за командния ред на Вашия сървър на Magento и получаваме потвърждение за пача и рестартирането.
- Запазваме логове, файлове и база данни проследимо, при нужда чрез нашата ИТ форензика.
- Проверяваме
env.php,pub/, модулите, таблиците с конфигурация, CMS блоковете и админ акаунтите. - Почистваме, подновяваме ключовете и достъпите и документираме периода на възможно засягане за защитата на данните и за платежните доставчици.
Често задавани въпроси
Затваря ли пач за сигурност на Magento и PHP2Shell?
Не. Пачовете на Magento отстраняват грешки в кода на магазина. PHP2Shell е в интерпретатора на PHP на сървъра и се затваря само чрез актуализация на PHP или потвърден backport с рестартиране на всички процеси.
Къде нападателите крият скимъри за кредитни карти в Magento?
Често не във файлове, а в базата данни, например в настройките за допълнителни скриптове в заглавната част на страницата или в CMS блокове. Затова при подозрение винаги е нужна и проверка на базата данни.
Кой пачва PHP при Adobe Commerce в облака?
Зависи от Вашия договор и от Вашата среда. Питайте писмено Adobe или Вашия оператор за състоянието на PHP и за рестартирането. Собствените разширения и съдържанието на базата данни остават във Ваша отговорност.
Защо app/etc/env.php е толкова важен?
Файлът съдържа достъпа до базата данни, ключа за криптиране и пътя до административната зона. Който е могъл да го прочете, може да декриптира шифровани стойности и да намери администрацията. При подозрение тези стойности трябва да се сменят.