PHP2Shell: el fallo crítico de PHP y qué hacer si tu PrestaShop es antiguo

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.

Qué parche te toca, según tu PrestaShop

PHP solo publica versiones oficiales nuevas para las ramas con soporte (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). Pero por la gravedad del fallo, los paneles de hosting y las distribuciones de Linux han sacado el arreglo también para las ramas antiguas. Así que lo que importa no es si tu PHP es viejo, sino si tu proveedor ya tiene el parche para tu versión, y casi todos lo tienen. Esta tabla cruza tu PrestaShop con su PHP y con quién te da hoy el parche:

«Soporte extendido» es un servicio (normalmente de pago, como TuxCare, o incluido en Ubuntu Pro) que mantiene parcheadas versiones de PHP que ya nadie actualiza. Fuentes: php.net, avisos de Debian, Ubuntu, Red Hat, Sury, cPanel, Plesk y TuxCare (21-24/10/2026), y devdocs.prestashop-project.org para la compatibilidad de PHP por versión.

El propio equipo de PHP publicó además el arreglo para PHP 7.4, 8.0 y 8.1, y en pocos días los grandes proveedores lo han empaquetado para que se instale con normalidad: Red Hat y AlmaLinux (incluso para 7.4 y 8.0), Ubuntu (su PHP 8.1, y el 7.4 y 7.2 con Ubuntu Pro), Debian, el repositorio de Sury (de 5.6 a 8.1) y los paneles cPanel y Plesk. Para la inmensa mayoría de tiendas ya hay un parche listo para aplicar. Solo las webs muy antiguas en PHP 7.3 o anterior sin ningún soporte extendido se quedan sin arreglo; para ellas la salida es el soporte extendido o, mejor, actualizar.

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. Hoy ya está disponible en todas las vías habituales (Debian, Ubuntu, Red Hat, AlmaLinux, Plesk, cPanel). Si tu servidor usa el repositorio de Remi, que tardó un poco más, comprueba que ya tiene la versión corregida. 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

Tranquilo: casi seguro que ya hay un parche para tu versión de PHP. Esto es lo que hay que hacer, por orden de importancia:

1. Aplica el parche de tu PHP (o pide a tu hosting que lo aplique)

   Es lo más importante y, por suerte, hoy suele ser fácil: casi todos los proveedores ya tienen el arreglo para tu versión (lo arreglan ellos mismos en tu versión antigua, aunque PHP ya no la actualice). Si gestionas tu hosting con Plesk o cPanel, actualiza PHP desde el panel. Si va por Debian, Ubuntu, Red Hat o AlmaLinux, con actualizar los paquetes basta. Si no lo gestionas tú, escribe a tu hosting: «aplicadme el parche de CVE-2026-109618 y 109619 en mi versión de PHP» y pide la fecha. Solo si estás en PHP 7.3 o anterior puede que no exista y haya que tirar de soporte extendido.

2. Mientras no esté aplicado el parche, pon la tienda detrás de Cloudflare

   Solo como medida temporal hasta aplicar el arreglo. 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. Si aún no tienes parche, endurece la configuración de PHP

   Es otra medida temporal, no un sustituto del parche. 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, sin prisa pero sin pausa, la migración a PrestaShop 9

   Que ahora haya parche no quita que estés en una versión sin soporte: cada fallo nuevo dependerá de que alguien lo vuelva a backportar. No es una urgencia de hoy, pero sí la recomendación de fondo para dejar de depender de parches ajenos. Cuando quieras darla, te explicamos cómo 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