En resumen: la vulnerabilidad de Shopware 6 que muchos comerciantes buscan ahora es en realidad una vulnerabilidad de PHP. Las actualizaciones de Shopware no la cierran. Necesita un PHP parcheado con reinicio de todos los procesos y, después, debería revisar .env, custom/plugins, el directorio public y las integraciones de API.
Qué significa PHP2Shell para Shopware 6
Shopware 6 se basa en el framework PHP Symfony y suele ejecutarse con PHP-FPM detrás de Nginx o Apache. Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 afectan precisamente a este modo de funcionamiento. Según el equipo de PHP, permiten ejecutar código malicioso de forma remota, sin autenticarse en la tienda.
Un atacante con ejecución de código en el servidor alcanza todo aquello a lo que accede la propia tienda: datos de clientes, pedidos, documentos de facturación, credenciales de la gestión de mercancías y de los proveedores de pago. Explicamos el contexto técnico en ¿Qué es PHP2Shell?.
Comprobar la vulnerabilidad de Shopware 6: ¿qué PHP se ejecuta realmente?
Shopware 6 se mantiene mucho desde la línea de comandos, por ejemplo con bin/console. Aquí es fácil equivocarse: php -v muestra la versión del PHP de la línea de comandos, no necesariamente la de PHP-FPM, que atiende las peticiones de la tienda. En muchos servidores hay varias versiones de PHP instaladas en paralelo.
Son fiables la indicación del panel de hosting para el dominio concreto y la confirmación del proveedor sobre el estado de los paquetes. Las versiones corregidas de origen son 8.5.12, 8.4.27, 8.3.36 y 8.2.35; los backports pueden llevar números más antiguos. Qué versiones de PHP admite su versión de Shopware puede consultarlo, según los requisitos del sistema, en la documentación de shopware.com. Cómo comprobarlo usted mismo se explica en Cómo comprobar correctamente la versión de PHP y el nivel de parcheo.
En Shopware 6 se pasa por alto a menudo un punto: muchas tiendas procesan la cola de mensajes y las tareas programadas mediante procesos en segundo plano de ejecución continua, por ejemplo bin/console messenger:consume bajo un gestor de procesos. Estos procesos cargan PHP una sola vez al arrancar. Por eso, tras la actualización no solo hay que reiniciar PHP-FPM, sino también estos workers. De lo contrario, una parte de la tienda sigue trabajando con el PHP antiguo y vulnerable en memoria.
Directorios y archivos que debería conocer
| Lugar | Contenido | Por qué es relevante |
|---|---|---|
.env, .env.local |
Acceso a la base de datos, APP_SECRET, otras claves |
Renovar ante una sospecha |
public/ |
Raíz de documentos con index.php, medios, archivos del tema |
Los archivos PHP adicionales son sospechosos |
public/theme/ |
Archivos JavaScript y CSS compilados de la tienda | Lugar para skimmers introducidos |
custom/plugins/, custom/apps/ |
Extensiones | Código de plugin modificado |
files/ |
Archivos privados como facturas y albaranes | Datos personales |
var/log/ |
Registros de la tienda | Conservar los rastros |
Primeras comprobaciones inofensivas:
# Mostrar los plugins instalados con versión y estado
bin/console plugin:list
# Listar los archivos PHP del directorio público
find public -type f -name "*.php"
# Mostrar vulnerabilidades conocidas en las dependencias de Composer
composer audit
En la carpeta public/ solo deberían estar unos pocos archivos PHP conocidos. Todo lo desconocido debe guardarse e investigarse, no borrarse de inmediato.
En la administración, en Ajustes > Sistema, revise las áreas «Usuarios y permisos» e «Integraciones». Los usuarios o integraciones de API desconocidos son una puerta trasera que escapa a cualquier análisis de archivos.
Acceso de administración, plugins y apps como riesgo
La administración está por defecto en /admin. Protéjala con cuentas personales, un inicio de sesión robusto y, si es posible, una restricción de acceso a redes conocidas. Las integraciones para la gestión de mercancías, los marketplaces o los servicios de envío solo deberían tener los permisos que realmente necesitan.
Los plugins de la tienda de extensiones y los desarrollos propios aportan código PHP propio, y las apps, además, webhooks hacia servidores externos. Cuantas más extensiones, mayor es la superficie de ataque y más laboriosa es cada actualización de PHP. Elimine por completo los plugins que ya no se usen.
Lo que puede y no puede hacer una actualización de Shopware
Una actualización de Shopware o de un plugin cierra errores conocidos en ese código. No puede:
- parchear PHP en el servidor,
- reiniciar procesos antiguos de PHP-FPM,
- eliminar con seguridad archivos ajenos en
public/ni archivos de tema manipulados, - borrar usuarios o integraciones ajenos,
- demostrar que antes del parche no ha ocurrido nada.
Tras una actualización de PHP a una nueva versión principal, debería regenerar la caché y el tema y probar la tienda en un entorno de pruebas. Si lo desea, nuestro servicio de parcheo de PHP se encarga del cambio de PHP con su justificante.
En los comerciantes más grandes, Shopware 6 suele ejecutarse en varios servidores de aplicaciones. Entonces cada servidor debe estar parcheado y reiniciado, incluso los que solo procesan tareas en segundo plano. Si un proveedor de servicios gestiona la tienda como plataforma administrada, debería confirmarle el estado de todos los nodos.
¿Cómo ayuda PHP SOS en concreto?
- Determinamos qué PHP utiliza realmente su tienda a través de FPM y aclaramos el parche y el reinicio con el proveedor de hosting o la agencia.
- Guardamos los registros a partir del 20/10/2026, la base de datos y los archivos.
- Revisamos
public/, los archivos de tema compilados, los plugins, los usuarios y las integraciones en busca de anomalías. - Si encontramos algo, limpiamos la tienda junto con su agencia y renovamos claves y accesos de forma ordenada.
Preguntas frecuentes
¿Está afectado el propio Shopware 6 por PHP2Shell?
Las vulnerabilidades están en PHP, no en el código de Shopware. Por eso, cualquier tienda Shopware 6 sobre un PHP sin parchear es potencialmente vulnerable, con independencia de la versión de Shopware. Una actualización de Shopware no cambia nada al respecto.
¿Qué archivo de Shopware 6 es especialmente crítico tras un ataque?
El archivo .env o .env.local, con el acceso a la base de datos y APP_SECRET. Quien haya podido leerlo conoce sus credenciales. Ante una sospecha, estos valores deberían renovarse, de acuerdo con su agencia.
¿Qué son las integraciones en Shopware 6 y por qué hay que revisarlas?
Las integraciones son accesos de API para sistemas externos, como la gestión de mercancías o los marketplaces. Una integración ajena con derechos de administrador permite el acceso completo a la tienda a través de la API sin que haya ningún archivo en el servidor.