En resumen: si su tienda online ha sido hackeada o funciona con una versión de PHP sin parchear, hay tres cosas en juego a la vez: los datos de clientes, el proceso de pago y sus ventas. Ponga la tienda en modo de mantenimiento de forma controlada, conserve los registros desde el 20/10/2026 y aclare quién actualiza y reinicia PHP en su servidor.
Qué está en juego en una tienda online
Una tienda es más que un sitio web. Gestiona cuentas de clientes con hashes de contraseñas, direcciones de entrega y de facturación, historiales de pedidos, cupones y, a menudo, también interfaces con la gestión de mercancías, los transportistas y los marketplaces. Quien puede ejecutar código en el servidor suele llegar a la base de datos y a las claves de API almacenadas en ella.
Los datos de tarjeta normalmente no están en su sistema, sino en el proveedor de pagos. Eso tranquiliza solo en parte: un atacante puede introducir JavaScript en el proceso de pedido que lea en el navegador lo que se escribe. Estos scripts de skimming apenas se notan en la operativa de la tienda, porque los pedidos se completan con normalidad.
A ello se suman las interfaces. Una tienda que transmite pedidos a la gestión de mercancías, a los transportistas y a los marketplaces suele guardar las claves de acceso correspondientes en archivos de configuración del servidor. Quien las copia puede generar etiquetas de envío en nombre del comerciante, modificar existencias o abusar de cuentas de marketplace.
Sistemas de tienda habituales y por qué les afecta PHP2Shell
Los sistemas de tienda más extendidos en las pequeñas y medianas empresas funcionan con PHP: Shopware 6, WooCommerce, Magento, OXID, PrestaShop y muchas instalaciones antiguas de Shopware 5. PHP2Shell (CVE-2026-109618 y CVE-2026-109619, ambas con CVSS 9.2) está en el propio PHP. Los atacantes no necesitan una cuenta de cliente ni acceso de administrador.
Para los comerciantes esto significa: la última actualización de la tienda no protege. Lo decisivo es si PHP en el servidor está en 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o si el proveedor de hosting ha aplicado un backport, y si después se reiniciaron todos los procesos de PHP. En las tiendas antiguas con PHP 8.1 o anterior, el proyecto PHP ya no ofrece actualizaciones oficiales. Entonces, además de la emergencia, hay que afrontar una migración que no querrá hacer con prisas en plena temporada alta.
Tienda online hackeada: qué significa un incidente en concreto
Una tienda comprometida causa daños en varios niveles que se refuerzan entre sí:
- Ventas: cada hora en modo de mantenimiento cuesta pedidos. Pero una tienda que sigue funcionando sin que nadie lo note puede salir bastante más cara.
- Datos de clientes: las direcciones y los pedidos filtrados se utilizan para correos de phishing dirigidos que parecen auténticos porque mencionan pedidos reales.
- Visibilidad: si Google detecta código malicioso, aparece una advertencia en los resultados de búsqueda. Cómo eliminarla se explica en la guía Eliminar la advertencia de Google.
- Socios: los proveedores de pagos y los marketplaces tienen sus propias normas para los incidentes de seguridad. Quien avisa tarde se arriesga a problemas en la liquidación.
Quién es responsable: ¿agencia, proveedor de hosting o comerciante?
En muchas tiendas, la cuestión de PHP cae entre todas las sillas. La agencia ha construido la tienda y mantiene los plugins, el proveedor de hosting gestiona el servidor y el comerciante da por hecho que se ocupa uno de los dos. En el hosting gestionado suele parchear el proveedor; en un VPS propio, nadie lo hace automáticamente.
| Tarea | Responsable habitual | Qué comprobar |
|---|---|---|
| Actualizar el paquete de PHP | Proveedor de hosting o administrador del servidor | Confirmación por escrito con el estado del paquete |
| Reiniciar los procesos de PHP | Quien administra el servidor | Momento del reinicio |
| Tienda y plugins | Agencia | Contrato de mantenimiento y accesos |
| Informar al proveedor de pagos | Comerciante | Obligaciones contractuales de notificación |
Un parche de PHP no demuestra que antes no hubiera pasado nada. Si la tienda sufrió un ataque entre el 17/10 y el momento del parche, el código introducido puede seguir ejecutándose. Haga que lo revisen antes de dar la situación por resuelta.
Las primeras horas: orden de actuación para comercios
- Poner la tienda en modo de mantenimiento o, si no es posible, desconectarla temporalmente de la red.
- Conservar los registros del servidor web, de PHP y de la tienda desde el 20/10/2026, antes de que la rotación los elimine.
- Pedir al proveedor de hosting que confirme por escrito el estado del paquete de PHP y el reinicio.
- Renovar las contraseñas de administrador, las claves de API de pago, envío y marketplaces y los accesos a la base de datos, y hacerlo solo después de la limpieza.
- Revisar si hay cambios en el proceso de pago, en los plugins de pago y en los scripts integrados.
Si hay indicios de una fuga de datos, corre el plazo de 72 horas del RGPD. La valoración jurídica debe hacerla con su delegado de protección de datos y, en su caso, con su abogado.
¿Cómo ayuda PHP SOS en concreto?
- Comprobamos en remoto el estado real del paquete de PHP, el modo de ejecución (por ejemplo, mod_php o PHP-FPM) y si se reiniciaron todos los workers.
- Examinamos los archivos de la tienda, la base de datos y el proceso de pago en busca de webshells, código de skimming y nuevas cuentas de administrador, y eliminamos el software malicioso que encontremos.
- Nos coordinamos con su agencia y su proveedor de hosting para que el mantenimiento de la tienda y la operación del servidor no vayan cada uno por su lado.
- Documentamos los hallazgos y las medidas de modo que pueda presentarlos al proveedor de pagos, a la aseguradora y al delegado de protección de datos.
- Después reforzamos el servidor y, si lo desea, asumimos la vigilancia continua.
Preguntas frecuentes
¿Debo desconectar mi tienda de la red por PHP2Shell?
El BSI (Oficina Federal alemana para la Seguridad de la Información) recomienda desconectar temporalmente los servidores web de la red si no es posible actualizar PHP de inmediato. En una tienda, un modo de mantenimiento con página informativa suele ser mejor opción que un mensaje de error. En cuanto PHP esté parcheado y todos los procesos reiniciados, la tienda puede volver a abrir.
¿Están en peligro los datos de tarjetas de crédito de mi tienda?
En la mayoría de las tiendas los datos de tarjeta no están en el servidor propio, sino en el proveedor de pagos. Lo peligroso es el código manipulado en el proceso de pago, que captura los datos introducidos antes de que lleguen al proveedor. Por eso, el proceso de pago forma parte de cualquier revisión tras un ataque.
¿Basta con actualizar Shopware o WooCommerce?
No. PHP2Shell afecta a PHP en sí, no al sistema de tienda. Una actualización de la tienda no cierra la vulnerabilidad, y un parche de PHP no elimina el código malicioso ya introducido.
¿A quién debo informar tras una fuga de datos?
Si hay datos personales, puede proceder la notificación a la autoridad de protección de datos en un plazo de 72 horas y, según el riesgo, también la comunicación a los afectados. A ello se suman las obligaciones contractuales con el proveedor de pagos y la aseguradora. La valoración en cada caso concreto debe hacerla con su delegado de protección de datos y su abogado.