PHP2Shell: si tu PrestaShop es anterior a la 9, te quedas fuera del parche oficial de PHP

Qué se sabe de CVE-2026-109618 y CVE-2026-109619

El 20 de octubre el equipo de seguridad de PHP publicó un aviso poco habitual: adelantaba una versión de seguridad urgente para el día siguiente. Los detalles se filtraron ese mismo día en Hacker News y en redes sociales, junto con la captura de una herramienta de ataque llamada PHP2Shell («shell» es la consola desde la que se dan órdenes a un servidor, así que el nombre ya dice para qué sirve: para tomar el control). La mañana del 21 Cloudflare (una empresa que se coloca entre tu web y los visitantes para filtrar el tráfico malicioso, y que usan millones de webs) informó de que ya veía los primeros ataques. A las 16:00, hora de Madrid, PHP publicó las versiones corregidas.

Los dos fallos tienen una puntuación CVSS v4.0 de 9,2 (CVSS es la escala con la que se mide lo grave que es un fallo de seguridad, del 0 al 10; a partir de 9 se considera crítico) y permiten ejecución remota de código sin autenticación (que alguien, desde cualquier parte del mundo, puede hacer que tu servidor haga lo que él quiera). Los códigos CVE son como la matrícula de cada fallo: un número único para que en todo el mundo se sepa de cuál se está hablando.

Según el aviso oficial, están expuestas todas las instalaciones de PHP que sirven páginas web, sea cual sea la forma de ejecutarlo (PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed). El riesgo es máximo con mod_php, donde ya se ha demostrado que una sola petición, sin usuario ni contraseña, dispara el ataque antes de que se ejecute ni una línea del código de tu tienda. Da igual lo bien programada que esté tu PrestaShop o los módulos de seguridad que tengas: el fallo está por debajo de todo eso.

Por qué tu PrestaShop anterior a la 9 se queda fuera del parche oficial

PHP solo da soporte a cada versión durante unos cuatro años. Pasado ese plazo, deja de publicar arreglos de seguridad. Hoy los reciben las ramas 8.2, 8.3, 8.4 y 8.5 (una «rama» es cada familia de versiones: la 8.1.2 y la 8.1.31 son de la misma rama, la 8.1), y ninguna PrestaShop anterior a la 9 es compatible con ellas. Esta es la tabla de compatibilidad PHP oficial de PrestaShop, cruzada con las fechas de fin de soporte de php.net:

«Sin parche oficial» quiere decir que PHP no publica nada para esa versión; puede haber arreglos de terceros, como el soporte extendido de pago. Fuentes: devdocs.prestashop-project.org (requisitos de sistema de 1.7, 8 y 9), php.net/eol.php y aviso de seguridad de PHP del 21/10/2026.

Por la gravedad del fallo, el equipo de PHP ha hecho una excepción: ha publicado arreglos mínimos para PHP 7.4, 8.0 y 8.1. No son versiones normales: son cambios en el código fuente (el «código fuente» es la receta de PHP: hay que fabricar con ella tu propia versión, un trabajo de técnico de sistemas) que tu proveedor tiene que empaquetar o compilar. Algunos ya lo han hecho: el repositorio de Sury, muy usado en Debian y Ubuntu, lo lleva en PHP 7.4, y Ubuntu 22.04 en su PHP 8.1. Para PHP 7.3 o anteriores, que es lo que usan la 1.6 y casi toda la 1.7, PHP no publica nada: solo hay arreglos de terceros, como el soporte extendido de pago, que dependen de ellos y no de PHP.

Dicho de forma sencilla: si tu tienda es una 1.6, una 1.7 o una 8, no puedes pasar a un PHP con el parche oficial sin que la tienda deje de funcionar. Lo explicamos con más detalle en nuestra página de referencia de PrestaShop 9, con qué PHP pide cada rama.

Ojo: tener PrestaShop 9 tampoco es garantía

PrestaShop 9.0 admite PHP 8.1. Si migraste a la 9 y tu hosting te dejó en PHP 8.1, estás casi en el mismo caso que una 1.7.8. Y si estás en PHP 8.2, actualiza hoy a la 8.2.35, pero recuerda que esa rama deja de tener soporte el 31 de diciembre de 2026, dentro de diez semanas. Lo recomendable es PHP 8.3 o 8.4.

Qué podría hacer un atacante en tu tienda si no actualizas

Ejecutar código en tu servidor equivale a tener las llaves de la tienda. Todo lo que sigue lo hemos visto en tiendas PrestaShop comprometidas por otras vías, como módulos vulnerables o contraseñas robadas. Este fallo da el mismo acceso y no necesita ni un módulo vulnerable ni una contraseña.

Sansec, la firma especializada en seguridad de tiendas online, calculaba que los ataques masivos empezarían unos 15 minutos después de publicarse el parche. Los atacantes comparan la versión corregida con la anterior, localizan el fallo (el propio arreglo, sin querer, señala dónde estaba el agujero) y lanzan escaneos automáticos contra todo internet. No eligen tu tienda: les sale en un barrido.

Cómo saber qué versión de PHP tiene tu PrestaShop

1. Desde el back office

   En PrestaShop 1.7, 8 y 9: «Parámetros avanzados › Información». En PrestaShop 1.6: «Parámetros avanzados › Información de configuración». Ahí aparecen la versión de PrestaShop y la de PHP.

2. Desde el panel de tu hosting

   Plesk, cPanel o similar (la web desde la que gestionas tu dominio y tu correo), en la configuración PHP del dominio.

3. Preguntándolo por escrito

   A tu proveedor de hosting o a quien te mantenga la tienda. Lo vas a necesitar igualmente para el paso siguiente.

Si para comprobarlo creas un fichero con phpinfo(), bórralo en cuanto lo mires (es un truco técnico; si no sabes qué es, no lo necesitas): deja a la vista de cualquiera la configuración completa de tu servidor.

Qué hacer hoy, según tu caso

Si tienes PrestaShop 9 sobre PHP 8.2 o superior

Actualiza PHP hoy mismo a 8.2.35, 8.3.36, 8.4.27 u 8.5.12, según tu rama, o pide a tu hosting que lo haga hoy, no la semana que viene. Las distribuciones de Linux recibieron el parche por adelantado. Un aviso práctico: el repositorio de Remi, muy usado en servidores CentOS, AlmaLinux y Rocky, no publicó paquetes el mismo día del parche; si tu servidor depende de él, comprueba que ya tiene la versión corregida antes de darlo por resuelto. Si esto te suena a chino, no te preocupes: es cosa de tu hosting. Basta con que le reenvíes este párrafo.

Si tienes PrestaShop 1.6, 1.7 u 8

No hay un parche oficial para ti, pero sí cosas que reducen mucho el riesgo mientras preparas la salida. Por orden:

1. Pregunta a tu hosting, por escrito, si parchea tu versión de PHP

   Es la primera pregunta útil. Algunos proveedores ya tienen paquetes con el arreglo para versiones antiguas (arreglan ellos mismos el fallo en tu versión antigua, aunque PHP ya no lo haga). Pregúntales qué usan (el repositorio de Sury, cPanel, Plesk, DirectAdmin, CloudLinux o un soporte extendido como TuxCare) y si tu versión ya está corregida. Pide la versión exacta del paquete y la fecha. Ojo: aunque te digan que sí, sigue siendo un arreglo mínimo, así que el resto de pasos sigue haciendo falta.

2. Pon la tienda detrás de Cloudflare

   Aunque sea con el plan gratuito, con el DNS en modo «proxy» y el servidor aceptando solo tráfico de Cloudflare (en la práctica: todo el que entra en tu tienda pasa antes por su filtro, y nadie llega a tu servidor saltándoselo). Ha desplegado reglas contra estos ataques, aunque su propio director técnico avisa de que es provisional. Solo protege si el atacante no conoce la IP real de tu servidor. Contamos cómo lo gestionamos en nuestra experiencia con Cloudflare.

3. Endurece la configuración de PHP

   Con las medidas del propio aviso de PHP, en php.ini o en la configuración del servidor (no sirven ini_set() ni .user.ini), y reiniciando PHP después. Lo hace tu hosting o tu técnico en pocos minutos: pásale este bloque tal cual.

   ; Contra CVE-2026-109619
   session.upload_progress.enabled = 0
   
   ; Contra CVE-2026-109618
   memory_limit = -1         ; con php_admin_value y un tope de memoria del contenedor o cgroup
   post_max_size = 32M       ; 8M si la tienda no necesita subir ficheros
   upload_max_filesize = 24M ; siempre por debajo de post_max_size

   PHP avisa de que esto reduce la exposición pero no hace la instalación segura. Y quitar el límite de memoria sin poner un tope en el servidor puede dejar que una sola petición se coma toda la memoria: no lo apliques sin tu técnico.

4. Comprueba que tienes copias fuera del servidor

   Y que se pueden restaurar. Si lo peor pasa, es la diferencia entre perder un día o perder la tienda.

5. Planifica la migración a PrestaShop 9 sobre PHP 8.3 u 8.4

   Es lo único que cierra el problema de verdad, y también los que vendrán: PHP seguirá publicando fallos y tu versión no recibirá los arreglos. Te explicamos cómo lo hacemos en migrar a PrestaShop 9: instalación limpia (una tienda nueva, montada desde cero, a la que pasamos tus datos en vez de remendar la vieja), datos traspasados y módulos revisados uno a uno.

Lo que no te protege

Y después de parchear: comprueba que no hayan entrado antes

Los ataques empezaron antes del parche. Si tu tienda estuvo expuesta, revisa si hay ficheros modificados, administradores que no conoces o código raro en el proceso de pago. Tienes la lista completa de síntomas en PrestaShop hackeado: qué está pasando aunque no lo veas, y más medidas de fondo en cómo reforzar la seguridad de PrestaShop.

Este fallo no será el último

Lo que deja al descubierto PHP2Shell no es un fallo concreto, sino una situación: miles de tiendas funcionan sobre software que ya nadie arregla, y cada vulnerabilidad nueva de PHP será otra alerta en la que tu tienda se queda fuera. Si quieres entender todo lo que implica seguir en una versión antigua, lo explicamos en los riesgos de no actualizar PrestaShop.

Si prefieres que alguien se encargue de forma continuada, con PHP y PrestaShop al día, copias comprobadas y alguien pendiente de estas alertas, eso es nuestro mantenimiento mensual de PrestaShop. Y si el problema de fondo es un hosting en el que no controlas la versión de PHP, mira nuestro alojamiento orientado a seguridad.

Preguntas frecuentes