Накратко: Ако Вашият онлайн магазин е хакнат или работи с непачната версия на PHP, става дума за три неща едновременно: клиентски данни, страницата за плащане и Вашия оборот. Преведете магазина контролирано в режим на поддръжка, запазете логовете от 20.10.2026 г. и изяснете кой актуализира и рестартира PHP на Вашия сървър.
Какво е заложено в един онлайн магазин
Магазинът е нещо повече от уебсайт. Той управлява клиентски акаунти с хешове на паролите, адреси за доставка и фактуриране, история на поръчките, ваучери, а често и интерфейси към системата за управление на стоките, към куриерските услуги и към пазарите. Който може да изпълнява код на сървъра, по правило достига до базата данни и до съхранените в нея API ключове.
Данните от картите обикновено не са при Вас, а при платежния доставчик. Това успокоява само отчасти: атакуващият може да внедри JavaScript в процеса на поръчка, който прочита въведеното в браузъра. Такива скриптове за скимване почти не се забелязват в работата на магазина, защото поръчките минават съвсем нормално.
Към това се добавят интерфейсите. Магазин, който предава поръчки на системата за управление на стоките, на куриерските услуги и на пазарите, съхранява ключовете за достъп до тях най-често в конфигурационни файлове на сървъра. Който ги копира, може от името на търговеца да създава товарителници, да променя наличностите или да злоупотребява с акаунти на пазари.
Типични магазинни системи и защо PHP2Shell ги засяга
Разпространените магазинни системи в средния бизнес в Европа работят на PHP: Shopware 6, WooCommerce, Magento, OXID, PrestaShop и много по-стари инсталации на Shopware 5. PHP2Shell (CVE-2026-109618 и CVE-2026-109619, по CVSS 9,2) е в самия PHP. Атакуващите не се нуждаят от клиентски акаунт, нито от администраторски достъп.
За търговците това означава: най-новата актуализация на магазина не защитава. Решаващо е дали PHP на сървъра е на 8.5.12, 8.4.27, 8.3.36 или 8.2.35, или хостинг доставчикът е внесъл backport, и дали след това всички PHP процеси са рестартирани. При стари магазини с PHP 8.1 или по-стар проектът PHP вече не предоставя официални актуализации. Тогава освен спешния случай предстои и миграция, която не искате да извършвате под натиск в разгара на сезона.
Хакнат онлайн магазин: какво означава конкретно инцидентът
Компрометираният магазин причинява щети на няколко равнища, които се усилват взаимно:
- Оборот: Всеки час в режим на поддръжка струва поръчки. Магазин, който продължава незабелязано да работи, обаче може да излезе значително по-скъпо.
- Клиентски данни: Изтеклите адреси и поръчки се използват за целенасочени фишинг имейли, които изглеждат истински, защото назовават истински поръчки.
- Видимост: Ако Google разпознае злонамерен код, в резултатите от търсенето се появява предупреждение. Как да се отървете от него, е описано в наръчника Премахване на предупреждението на Google.
- Партньори: Платежните доставчици и пазарите имат собствени правила за инциденти със сигурността. Който уведоми твърде късно, рискува неприятности при разплащането.
Кой отговаря: агенция, хостинг доставчик или търговец?
В много магазини въпросът за PHP пада между всички. Агенцията е изградила магазина и поддържа добавките, хостинг доставчикът управлява сървъра, а търговецът приема, че някой от двамата се грижи. При управляван хостинг пачва най-често хостинг доставчикът, а при собствен vServer – никой автоматично.
| Задача | Обикновено отговаря | Проверете |
|---|---|---|
| Актуализиране на PHP пакета | Хостинг доставчик или поддържащ сървъра | Писмено потвърждение със състоянието на пакета |
| Рестартиране на PHP процесите | Който управлява сървъра | Час на рестартирането |
| Магазин и добавки | Агенция | Договор за поддръжка и достъпи |
| Информиране на платежния доставчик | Търговец | Договорни задължения за уведомяване |
Пачът за PHP не доказва, че преди това нищо не се е случило. Ако магазинът е бил атакуван между 17.10. и момента на пача, внедреният код може да продължава да работи. Накарайте да се провери това, преди да обявите, че опасността е отминала.
Първите часове: ред на действие за търговци
- Преведете магазина в режим на поддръжка или, ако това не е възможно, го изключете временно от мрежата.
- Запазете логовете на уеб сървъра, на PHP и на магазина от 20.10.2026 г., преди ротацията да ги изтрие.
- Поискайте от хостинг доставчика писмено потвърждение на състоянието на PHP пакета и на рестартирането.
- Подновете администраторските пароли, API ключовете за плащане, доставка и пазари, както и достъпите до базата данни, и то едва след почистването.
- Проверете страницата за плащане, добавките за плащане и вградените скриптове за промени.
Ако има признаци за изтичане на данни, тече 72-часовият срок по ОРЗД. Правната оценка правите със своето длъжностно лице по защита на данните и при нужда с Вашия адвокат.
Как помага PHP SOS конкретно?
- Проверяваме отдалечено реалното състояние на PHP пакета, режима на работа (например mod_php или PHP-FPM) и дали всички worker процеси са рестартирани.
- Проучваме файловете на магазина, базата данни и страницата за плащане за уеб шелове, код за скимване и нови администраторски акаунти и премахваме намерения зловреден софтуер.
- Съгласуваме се с Вашата агенция и с Вашия хостинг доставчик, за да не се разминават поддръжката на магазина и експлоатацията на сървъра.
- Документираме находките и мерките така, че да можете да ги представите на платежния доставчик, на застрахователя и на длъжностното лице по защита на данните.
- След това заздравяваме сървъра и по желание поемаме текущото наблюдение.
Често задавани въпроси
Трябва ли да изключа магазина от мрежата заради PHP2Shell?
BSI (Федералната служба за информационна сигурност на Германия) препоръчва уеб сървърите да се изключват временно от мрежата, когато актуализацията на PHP не е възможна веднага. За един магазин режимът на поддръжка със страница с обяснение често е по-добрият път от съобщение за грешка. Щом PHP е пачнат и всички процеси са рестартирани, магазинът може да отвори отново.
Застрашени ли са данните от кредитни карти в моя магазин?
В повечето магазини данните от картите не се съхраняват на собствения сървър, а при платежния доставчик. Опасен обаче е манипулиран код в страницата за плащане, който прихваща въведеното, преди да стигне до доставчика. Затова страницата за плащане е част от всяка проверка след атака.
Достатъчно ли е да актуализирам Shopware или WooCommerce?
Не. PHP2Shell засяга самия PHP, а не магазинната система. Актуализацията на магазина не затваря уязвимостта, а пачът за PHP не премахва вече внедрен злонамерен код.
Кого трябва да информирам след изтичане на данни?
При лични данни е възможно уведомяване на надзорния орган по защита на данните в рамките на 72 часа, а според риска и информиране на засегнатите лица. Към това се добавят договорни задължения към платежния доставчик и към застрахователя. Оценката в конкретния случай правите заедно с длъжностното лице по защита на данните и адвокат.