Накратко: Уязвимостта в Shopware 6, която много търговци търсят в момента, всъщност е уязвимост в PHP. Актуализациите на Shopware не я затварят. Нужен Ви е пачнат PHP с рестартиране на всички процеси, а след това трябва да проверите .env, custom/plugins, директорията public и API интеграциите.
Какво означава PHP2Shell за Shopware 6
Shopware 6 е изграден върху PHP фреймуърка Symfony и най-често работи с PHP-FPM зад Nginx или Apache. Уязвимостите CVE-2026-109618 и CVE-2026-109619 засягат точно този режим на работа. Според екипа на PHP те позволяват изпълнение на злонамерен код от разстояние, без вход в магазина.
Нападател с изпълнение на код на сървъра достига всичко, до което има достъп самият магазин: данни на клиенти, поръчки, фактури, данни за достъп до складово стопанство и платежни доставчици. Техническия контекст обясняваме на страницата Какво е PHP2Shell?.
Проверка на уязвимостта в Shopware 6: кой PHP наистина работи?
Shopware 6 се поддържа много през командния ред, например с bin/console. Тук лесно се греши: php -v показва версията на PHP за командния ред, а не непременно тази на PHP-FPM, който обработва заявките към магазина. На много сървъри са инсталирани няколко версии на PHP паралелно.
Надеждни са данните в хостинг панела за конкретния домейн и потвърждението на хостинг доставчика за състоянието на пакета. Поправените версии на оригиналния проект са 8.5.12, 8.4.27, 8.3.36 и 8.2.35; backport-овете могат да носят по-стари номера. Кои версии на PHP поддържа Вашата версия на Shopware, проверете според системните изисквания в документацията на shopware.com. Как да проверите сами, пише в Как да проверите правилно PHP версията и състоянието на пача.
При Shopware 6 често се пропуска една точка: много магазини обработват опашката със съобщения и планираните задачи чрез постоянно работещи фонови процеси, например bin/console messenger:consume под мениджър на процеси. Тези процеси зареждат PHP веднъж при стартиране. След актуализацията затова трябва да се рестартират не само PHP-FPM, но и тези worker процеси. Иначе част от магазина продължава да работи със стария, уязвим PHP в паметта.
Директории и файлове, които трябва да познавате
| Място | Съдържание | Защо е важно |
|---|---|---|
.env, .env.local |
достъп до базата данни, APP_SECRET, други ключове |
При подозрение се сменят |
public/ |
коренова директория с index.php, медия, файлове на темата |
Допълнителните PHP файлове са подозрителни |
public/theme/ |
компилирани JavaScript и CSS файлове на витрината | Място за внедрени скимъри |
custom/plugins/, custom/apps/ |
разширения | Променен код на плъгини |
files/ |
частни файлове като фактури и товарителници | Лични данни |
var/log/ |
протоколи на магазина | Запазете следите |
Безопасни първи проверки:
# Показване на инсталираните плъгини с версия и състояние
bin/console plugin:list
# Списък на PHP файловете в публичната директория
find public -type f -name "*.php"
# Показване на известни уязвимости в зависимостите на Composer
composer audit
В папката public/ трябва да има само малко, познати PHP файлове. Всичко непознато се запазва и проучва, не се изтрива веднага.
Проверете в администрацията под Настройки > Система разделите „Потребители и права“ и „Интеграции“. Непознати потребители или API интеграции са задна вратичка, която всяко сканиране на файлове пропуска.
Административен достъп, плъгини и приложения като риск
Администрацията е по подразбиране на /admin. Защитете я с лични акаунти, силен вход и, ако е възможно, с ограничаване на достъпа до познати мрежи. Интеграциите за складово стопанство, пазари или куриерски доставчици трябва да имат само правата, от които наистина се нуждаят.
Плъгините от магазина и собствените разработки носят собствен PHP код, а приложенията допълнително webhooks към външни сървъри. Колкото повече разширения, толкова по-голяма повърхност за атака и толкова по-трудно всяко надграждане на PHP. Премахнете напълно плъгините, които вече не се ползват.
Какво може актуализацията на Shopware и какво не
Актуализацията на Shopware или на плъгин затваря известни грешки в този код. Тя не може:
- да пачне PHP на сървъра,
- да рестартира стари PHP-FPM процеси,
- да премахне сигурно чужди файлове в
public/или манипулирани файлове на темата, - да изтрие чужди потребители или интеграции,
- да докаже, че преди пача нищо не се е случило.
След актуализация на PHP до нова основна версия трябва да изградите наново кеша и темата и да проверите магазина в тестова среда. Смяната на PHP с доказателство поема при желание нашата услуга за пач на PHP.
Shopware 6 при по-големи търговци често работи на няколко сървъра за приложения. Тогава всеки сървър трябва да е пачнат и рестартиран, дори и такива, които обработват само фонови задачи. Ако доставчик експлоатира магазина като управлявана платформа, той трябва да Ви потвърди състоянието за всички възли.
Как помага PHP SOS конкретно?
- Установяваме кой PHP Вашият магазин реално ползва през FPM и изясняваме пача и рестартирането с хостинг доставчика или агенцията.
- Запазваме логове от 20.10.2026 г. нататък, базата данни и файловете.
- Проверяваме
public/, компилираните файлове на темата, плъгините, потребителите и интеграциите за нередности. - При находка почистваме магазина заедно с Вашата агенция и подновяваме ключовете и достъпите по ред.
Често задавани въпроси
Засегнат ли е самият Shopware 6 от PHP2Shell?
Уязвимостите са в PHP, а не в кода на Shopware. Всеки магазин на Shopware 6 с непачнат PHP е затова потенциално уязвим, независимо от версията на Shopware. Актуализацията на Shopware не променя това.
Кой файл в Shopware 6 е особено критичен след атака?
Файлът .env или .env.local с достъпа до базата данни и APP_SECRET. Който е могъл да го прочете, познава Вашите данни за достъп. При подозрение тези стойности трябва да се сменят, съгласувано с Вашата агенция.
Какво са интеграциите в Shopware 6 и защо да ги проверя?
Интеграциите са API достъпи за външни системи, например за складово стопанство или пазари. Чужда интеграция с администраторски права позволява пълен достъп до магазина през API, без на сървъра да лежи какъвто и да е файл.