PHP2Shell: protege tu tienda online ante vulnerabilidad crítica de PHP

Si tu tienda online funciona con WooCommerce, PrestaShop, Magento o cualquier otra plataforma basada en PHP, tienes una tarea urgente: confirmar con tu hosting, sysadmin o tu agencia que el servidor ya está parcheado contra PHP2Shell. No necesitas tocar nada técnico tú mismo, pero sí hacer las preguntas correctas.

Resumen en 30 segundos:

• PHP2Shell son dos fallos graves en PHP, el «motor» sobre el que funcionan la mayoría de sitios en Internet. Incluido tiendas online.
• Permiten a un atacante tomar el control del servidor sin usuario ni contraseña.
• Ya hay ataques en marcha a escala mundial.
• La solución no está en tu panel de la tienda, sino en el servidor: lo tiene que aplicar tu hosting o tu técnico.
• Si tu tienda usa versiones antiguas de PHP, el riesgo es mayor y conviene plantear ya una migración.

Qué es PHP2Shell

PHP2Shell es el nombre popular de dos vulnerabilidades críticas en PHP, registradas como CVE-2026-109618 y CVE-2026-109619. Ambas tienen una gravedad de 9,2 sobre 10, y alguna firma de seguridad la ha llegado a puntuar con un 10.

Para entenderlo, piensa en tu tienda como un coche. WooCommerce, Magento o PrestaShop son la carrocería y el salpicadero (lo que ves). PHP es el motor que hay debajo y que hace que todo funcione. El fallo no está en tu tienda, está en el motor.

En la práctica, un atacante puede enviar una petición web manipulada a tu servidor y conseguir ejecutar sus propias órdenes en él. Sin usuario, sin contraseña y sin que tu tienda tenga ningún error de programación. Por eso se llama «2Shell»: le da al atacante sin permiso una «consola» dentro de tu servidor.

Hay un detalle importante: actualizar WooCommerce, Magento, los plugins o el tema no soluciona el problema. Una tienda que aparece «todo al día» en su panel de administración puede seguir expuesta si el PHP del servidor no se ha actualizado.

A quién afecta

Afecta a cualquier web que funcione sobre PHP desde la versión 5.4, es decir, prácticamente todo lo publicado en la última década. PHP está detrás de cerca del 70% de las webs del mundo cuyo lenguaje de servidor se conoce.

Si tu tienda funciona con…	¿Está afectada?
WooCommerce (WordPress)	Sí, si el PHP del servidor no está parcheado
Magento 2 / Adobe Commerce	Sí, si el PHP del servidor no está parcheado
Magento 1 / OpenMage	Sí, y con más riesgo si usa PHP 5.6 o 7.x
PrestaShop, OpenCart, Joomla, Drupal	Sí, si el PHP del servidor no está parcheado
Desarrollo a medida en PHP	Sí
Shopify	No directamente: no usa PHP y la plataforma la gestiona Shopify

Si vendes en Shopify, no tienes nada que tocar en la tienda. Pero revisa todo lo que tengas fuera de Shopify con tu dominio: un blog en WordPress, landings, apps o conectores propios que corran en un servidor con PHP.

Shopify: a salvo de PHP2Shell, pero no de sustos

Que Shopify no esté afectado por PHP2Shell no significa que esté libre de riesgos. Justo estas semanas ha sufrido otro tipo de ataque, y conviene conocerlo.

Desde el 10 de octubre, varias tiendas Shopify han mostrado a sus clientes un checkout falso. Al pulsar «Finalizar compra», el cliente llegaba a una página idéntica a la de Shopify, pero en otro dominio. Allí introducía su tarjeta, los datos se enviaban a los atacantes y después se le redirigía al checkout real para pagar con normalidad. El pedido entraba sin problemas, así que la tienda no notaba nada.

Shopify en sí no fue hackeado. El código malicioso llegó a través de apps de terceros instaladas en las tiendas, como Hulk Product Options, Selleasy o Swym Wishlist Plus, cuyos fabricantes confirmaron que alguien había manipulado lo que sus apps cargaban. Swym llegó a desactivar su app para todos sus clientes el 18 de octubre.

La lección es la misma que con PHP2Shell: cada pieza de tu tienda que no controlas es una puerta posible.

Si tu tienda es WooCommerce

WooCommerce funciona sobre WordPress, que este año ha acumulado sustos propios. En julio se publicó wp2shell, un fallo crítico en el propio núcleo de WordPress que permitía tomar el control de la web sin contraseña. Y en septiembre se detectaron más de 100.000 intentos de ataque contra un plugin de WooCommerce para tiendas mayoristas, cuatro meses después de que existiera el parche: los atacantes van a por las tiendas que no actualizan.

Por eso, además del PHP del servidor, revisa que WordPress, WooCommerce y todos los plugins estén al día, y desinstala los que no uses. Un plugin abandonado es una puerta abierta, aunque PHP esté parcheado.

Si tu tienda es PrestaShop

PrestaShop también ha tenido este año una vulnerabilidad crítica en un módulo oficial muy extendido, el buscador por filtros (ps_facetedsearch), que permitía colar código malicioso en el servidor a través de los filtros de precio o peso. Si tu tienda lo usa, comprueba que está actualizado.

Además, muchas tiendas siguen en PrestaShop 1.6 o 1.7, que no están preparadas para PHP 8. Eso las obliga a funcionar con PHP 7.x, justo las versiones sin parche oficial de PHP2Shell. Si es tu caso, la situación es parecida a la de Magento 1: parche de emergencia ahora y plan para actualizar a una versión actual de PrestaShop.

El riesgo también depende de cómo esté configurado el servidor. Los servidores con Apache y el módulo mod_php son los más expuestos, porque ahí el ataque se ha demostrado de forma completa. Los que usan PHP-FPM (lo habitual en muchos hostings actuales) también son vulnerables. No es algo que tengas que saber tú: es una de las preguntas que debes hacer a tu proveedor.

Cómo se descubrió

Los fallos los encontraron en agosto investigadores de las firmas de seguridad Calif y Wiz, con apoyo de herramientas de inteligencia artificial y del proyecto de OpenAI para buscar fallos en software de código abierto. Según varios análisis, el error llevaba años en el código de PHP sin que nadie lo hubiera aprovechado como vía de ataque.

Lo normal en estos casos es avisar en privado a los responsables de PHP, preparar el parche y publicarlo todo a la vez para que nadie tenga ventaja. Esta vez el plan se torció: el 20 de octubre se filtró información en un foro público antes de que el parche estuviera listo, y eso obligó a adelantar la publicación.

Fecha	Qué pasó
21 oct 2026	PHP publica las versiones corregidas y empiezan los ataques masivos
20 oct 2026	Se filtra información del fallo antes del parche
17 oct 2026	Amazon detecta un primer intento de ataque en sus sistemas trampa
Agosto 2026	Calif y Wiz descubren los fallos y avisan a PHP

¿Ya hay webs atacadas?

Sí hay ataques en marcha, y a gran escala. Lo que todavía no está claro es cuántos han tenido éxito.

• Amazon detectó un primer intento el 17 de octubre, cuatro días antes de que el fallo fuera público, y advierte de que ahora se está explotando de forma generalizada.
• Cloudflare pasó de miles de intentos antes del anuncio a millones pocas horas después.
• Patchstack, especializada en seguridad WordPress, informó de varios incidentes de explotación confirmados antes incluso del parche.
• Ya circulan en Internet herramientas de ataque listas para usar, lo que facilita que cualquiera lance ataques automáticos contra miles de webs.

La gravedad se nota en la reacción: administraciones públicas francesas, el centro nacional de ciberseguridad de Países Bajos o la Universidad de Viena desconectaron sus webs de forma preventiva mientras aplicaban los parches.

Para una tienda online pequeña o mediana esto es lo relevante: los atacantes no eligen víctimas a mano. Lanzan robots que recorren Internet buscando cualquier servidor sin parchear. Que tu tienda sea pequeña no te protege.

Y esto va a ir a más: el efecto de la inteligencia artificial

PHP2Shell no es un caso aislado. El fallo se encontró con ayuda de inteligencia artificial, igual que wp2shell, la vulnerabilidad crítica de WordPress publicada en julio. Las herramientas de IA están sacando a la luz fallos que llevaban años escondidos en el código, y lo hacen cada vez más rápido.

Esa misma tecnología la usan también los atacantes, para entender un parche en horas y convertirlo en un ataque automático. El tiempo entre que se publica un fallo y empiezan los ataques es cada vez más corto.

La conclusión a la que lleva todo esto es clara: cada versión antigua, de Magento o de un plugin sin mantenimiento es una papeleta más en ese sorteo. Puede que no te toque pero vas a estar más expuesto a otro que está más o menos al día. Las versiones con soporte reciben parche en horas; las antiguas pueden quedarse sin él.

Síntomas: señales de que algo va mal

Un ataque con éxito puede no notarse durante semanas. Aun así, hay señales que cualquier gestor de tienda puede detectar sin acceder al servidor:

• Caídas o errores raros: la web se cae a ratos, aparecen páginas de «Error 500» o va mucho más lenta sin motivo.
• Usuarios administradores que no conoces en el panel de tu tienda.
• Redirecciones extrañas: al entrar desde Google o desde el móvil, tu web lleva a otra página.
• Avisos de Google: mensajes en Search Console sobre seguridad o el aviso «Este sitio puede haber sido pirateado» en los resultados.
• Páginas que no has creado indexadas en Google, a menudo de casinos, farmacia o productos falsificados.
• Quejas de clientes por cargos fraudulentos en su tarjeta después de comprar en tu tienda.
• Cambios en el checkout: un formulario de pago distinto, un paso nuevo o campos que no reconoces.
• Correos rebotados o avisos de spam: tu servidor puede estar enviando correo basura.
• Avisos de tu hosting sobre consumo anómalo de recursos o archivos sospechosos.

Tu técnico o hosting puede revisar además otras pistas que tú no ves: archivos PHP nuevos o modificados, tareas programadas desconocidas, conexiones salientes extrañas o picos de errores de memoria en los registros del servidor.

Qué implica que te infecten

Si un atacante entra en el servidor, tiene el mismo poder que tu técnico. Para una tienda online eso se traduce en problemas muy concretos:

• Robo de datos de clientes: nombres, direcciones, teléfonos, emails e historial de pedidos.
• Robo de tarjetas: pueden inyectar código en el checkout que copia los datos de pago mientras el cliente compra, sin que el pedido falle.
• Robo de claves: los investigadores han demostrado que el fallo también permite leer la memoria del servidor, donde pueden estar contraseñas y claves de tu pasarela de pago, ERP, transportistas o marketplaces.
• Puertas traseras: el atacante suele dejar archivos ocultos para volver a entrar aunque luego parchees.
• Daño SEO y de reputación: páginas de spam en tu dominio, penalizaciones de Google y avisos de «sitio peligroso» en el navegador.
• Paradas de venta: tienda caída, secuestro de datos (ransomware) o chantajes.
• Obligaciones legales: si hay datos personales comprometidos, el RGPD obliga a notificarlo a la Agencia Española de Protección de Datos en un plazo de 72 horas y, en algunos casos, a avisar a los clientes afectados.

Por eso no basta con parchear: si hay sospecha de que alguien entró antes del parche, hay que revisar y limpiar el servidor y cambiar contraseñas y claves.

¿Hay solución? Depende de tu versión de PHP

La solución definitiva es actualizar PHP. Cuánto cuesta hacerlo depende de la versión que use tu tienda.

Versión de PHP de tu tienda	Situación	Qué hacer
8.2, 8.3, 8.4 u 8.5	Parche oficial publicado el 21 de octubre	Actualizar a 8.2.35, 8.3.36, 8.4.27 u 8.5.12
7.4, 8.0 u 8.1	Sin versión oficial nueva, pero hay parches adaptados	Aplicar el parche de tu panel o proveedor y planificar migración
7.3 o anterior (incluida 5.6)	Sin parche oficial; solo soluciones de terceros	Parche de terceros o migrar con urgencia

Versiones actuales (8.2 en adelante). Es el caso sencillo. Tu hosting solo tiene que instalar la versión corregida y reiniciar los servicios de PHP. Muchos proveedores ya lo han hecho de forma automática, pero conviene confirmarlo.

Ojo al cambiar de versión de PHP. Actualizar dentro de tu misma versión (por ejemplo, de 8.3.x a 8.3.36) es seguro y no afecta a tu tienda. Pero si estás en PHP 8.1 o anterior y tu proveedor te propone saltar a una versión nueva, comprueba antes que tu versión de Magento, WooCommerce o PrestaShop, tu tema y tus extensiones la soportan. Un salto de versión sin revisar puede romper la tienda y generar cientos de errores.

Plesk. Plesk ha publicado parches para las versiones 8.2 a 8.5 y también para las antiguas 7.4, 8.0 y 8.1. Ojo con un detalle: en estas versiones antiguas el número no cambia (por ejemplo, sigue siendo 7.4.33). Lo que cambia es la fecha de compilación, que debe ser del 21 de octubre de 2026 o posterior. Por debajo de 7.4, Plesk no ofrece parche de momento.

Hostings con PHP o sistemas operativos antiguos. Aquí está el mayor problema. Muchos servidores con CentOS 7 u otros sistemas sin soporte siguen ejecutando PHP 5.6 o 7.x. El equipo de PHP ha publicado el arreglo para 7.4, 8.0 y 8.1, pero solo como código fuente: cada hosting tiene que compilarlo e instalarlo por su cuenta. Para versiones anteriores a 7.4 no hay arreglo oficial. Varios proveedores están preparando sus propios parches: algunas empresas han anunciado que trabajan en versiones para PHP 5.6 a 7.3, y distribuciones como CloudLinux ofrecen parches para versiones antiguas. Son una solución de emergencia, no definitiva.

Medidas temporales. Mientras llega el parche, tu técnico puede reducir el riesgo con ajustes de configuración o con un cortafuegos web (WAF). Cloudflare, por ejemplo, ha activado reglas de protección incluso en su plan gratuito. Ayudan, pero no sustituyen al parche.

Caso especial: si tu tienda sigue en Magento 1

Si tu tienda funciona todavía con Magento 1 sobre PHP 5.6 o PHP 7, estás en el grupo de mayor riesgo. Magento 1 dejó de recibir soporte oficial en junio de 2020, y esas versiones de PHP no tienen parche oficial para PHP2Shell.

Un parche de emergencia de tu hosting puede sacarte del apuro esta semana. Pero el problema de fondo sigue ahí: cada nuevo fallo de seguridad te volverá a pillar sin solución oficial. Hay dos caminos:

1. Migrar a Magento 2 (Adobe Commerce / Magento Open Source). Es la opción más completa y con más recorrido. Supone rehacer la tienda: tema, extensiones e integraciones, y migrar productos, clientes y pedidos. Es un proyecto extensa y una inversión importante, pero te deja en una plataforma actual y mantenida.

2. Pasar a OpenMage. OpenMage es una continuación de Magento 1 mantenida por la comunidad, compatible con PHP 8. Mantiene la misma estructura que ya conoces, así que el desembolso es mucho menor. El trabajo principal es adaptar el tema y las extensiones a PHP 8. Es la vía recomendable si ahora no puedes asumir una migración completa por tiempo/presupuesto/otras causas internas.

En ambos casos, el primer paso es el mismo: una auditoría de las extensiones y personalizaciones que tiene tu tienda, para saber cuánto trabajo real supone cada opción.

Qué hacer hoy: pasos para el gestor de la tienda

No tienes que entrar en el servidor. Tu trabajo es asegurarte de que quien lo gestiona lo ha hecho, y dejarlo por escrito.

1. Identifica quién gestiona tu servidor. Puede ser tu hosting, tu agencia, un freelance o tu equipo interno. Si no lo tienes claro, mira quién te factura el alojamiento.
2. Pregunta por escrito. Envíales este mensaje (puedes copiarlo tal cual):»Hola, por la vulnerabilidad PHP2Shell (CVE-2026-109618 y CVE-2026-109619): ¿qué versión de PHP usa nuestra tienda en producción? ¿Está ya parcheada?»
3. Exige que el parche se aplique ya. No es algo para la próxima ventana de mantenimiento. Pide que te confirmen fecha y versión instalada. Si tienes hosting gestionado, pide que te confirmen que tu servidor está en su lista de actualizaciones.
4. Revisa tú lo que sí puedes ver. Usuarios administradores de la tienda, Search Console, el proceso de compra y los avisos de clientes.
5. Cambia contraseñas y claves si hay dudas. Accesos de administrador, base de datos, FTP y claves de la pasarela de pago, ERP o transportistas. Activa la verificación en dos pasos donde se pueda.
6. Comprueba las copias de seguridad. Que existan, que sean recientes y que se puedan restaurar. Idealmente, guardadas fuera del propio servidor.
7. Prueba la tienda tras el parche. Haz un pedido de prueba completo: pago, email de confirmación, envío e integraciones.
8. Planifica la migración si usas PHP antiguo. Un parche de emergencia es un parche, no una solución para los próximos años.

PHP2Shell es uno de los fallos más graves de los últimos años en Internet, porque afecta al motor de casi todos los sitios y ya se está explotando. La buena noticia es que tiene solución: si tu servidor usa PHP 8.2 o superior, basta con actualizar. Si usas versiones antiguas, hay parches de emergencia, pero es el momento de plantear en serio la actualización de tu plataforma.

La seguridad del servidor ya no es algo que deba meterse en el cajón que algún día se hará: es parte directa de la continuidad de tu negocio.