PHP2Shell: la vulnerabilidad crítica de PHP y cómo afecta a PrestaShop

Actualización: 21 de octubre de 2026, 16:00. PHP ha publicado el parche y ha confirmado las dos vulnerabilidades. Lo más importante:

• Las versiones corregidas son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. PHP pide actualizar de inmediato.
• Hay arreglo también para versiones antiguas. El equipo de PHP ha publicado el código de la corrección para PHP 7.4, 8.0 y 8.1, y en los paquetes de Ondřej Surý, los más usados en Ubuntu y Debian, ya están llegando versiones corregidas para todas las versiones de PHP que mantiene, de la 5.6 a la 8.5.
• Desactivar la barra de progreso de subida solo frena uno de los dos fallos, y no del todo. Ya no basta con eso: hay que actualizar.

Hemos reescrito la entrada con la información oficial. La primera versión, de las 08:00, se basaba en lo que se había filtrado.

Seguiremos actualizando esta entrada según haya novedades.

---

Si tienes una tienda en PrestaShop, hoy toca prestar atención al servidor. PHP, el lenguaje sobre el que funciona PrestaShop (y también WordPress, WooCommerce, Magento o Drupal), acaba de corregir dos fallos de seguridad con una puntuación de 9,2 sobre 10. Ambos permiten a un atacante ejecutar código en el servidor sin necesidad de usuario ni contraseña.

La información se filtró ayer, antes de lo previsto, y desde las 16:00 los detalles técnicos son públicos. Se esperan ataques masivos en las próximas horas, así que no conviene dejarlo para mañana.

¿Qué ha confirmado PHP?

	Qué dice el aviso oficial
Versiones corregidas	PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12.
Gravedad	Dos vulnerabilidades críticas, ambas con 9,2 sobre 10: CVE-2026-109618 y CVE-2026-109619.
Quién está en riesgo	Cualquier instalación de PHP que sirva páginas web: PHP-FPM, Apache con mod_php, CGI, LiteSpeed o FrankenPHP. El riesgo es mayor con mod_php, donde ya se ha demostrado el ataque.
PHP 8.1 y anteriores	PHP ya no publica versiones para ellas, pero ha liberado la corrección para PHP 7.4, 8.0 y 8.1. Hay que obtenerla del proveedor o de la distribución.
Medidas temporales	Solo reducen el riesgo. PHP insiste en que actualizar es la única opción segura.

¿Dónde está el problema?

PHP ha confirmado dos fallos distintos. Los dos ocurren antes de que se ejecute el código de tu tienda, mientras PHP prepara la petición. Por eso no se pueden arreglar desde PrestaShop ni con un módulo: la corrección tiene que llegar al servidor.

El primero (CVE-2026-109618) aparece cuando PHP se queda sin memoria a mitad de procesar una petición. En ese momento algunos datos internos quedan a medio preparar, y al limpiar PHP los trata como si fueran válidos. Un atacante puede provocar esa situación a propósito con una petición preparada.

El segundo (CVE-2026-109619) tiene que ver con restos de una petición anterior. Cuando PHP termina de atender a un visitante, algunos datos internos pueden quedarse «colgando» aunque la memoria que usaban ya se haya liberado. Si la siguiente petición que atiende ese mismo proceso es la del atacante, puede aprovechar esos restos. Una de las vías confirmadas para provocarlo es la función que informa del progreso de subida de ficheros, la que se filtró ayer. No es la única.

Con cualquiera de los dos, un atacante podría leer la base de datos (clientes, pedidos), instalar código malicioso en el checkout o usar tu servidor para atacar a otros.

¿Hay PHP corregido para tu versión de PrestaShop?

PHP da soporte a cada versión durante cuatro años. Hoy solo tienen soporte 8.2, 8.3, 8.4 y 8.5, y son las únicas con versión oficial corregida. Por la gravedad del caso, PHP ha hecho una excepción y ha publicado también el código de la corrección para 7.4, 8.0 y 8.1. Aun así, no hay versión oficial para esas ramas: el PHP corregido tiene que llegarte a través de tu proveedor o de la distribución de Linux.

Si cruzamos esto con las versiones de PHP que admite oficialmente cada PrestaShop, el resultado es este:

Versión de PrestaShop	PHP compatible	Versión oficial corregida	Otras vías
9.1	8.1 a 8.5	Sí, en PHP 8.2 o superior	No hacen falta
9.0	8.1 a 8.4	Sí, en PHP 8.2 o superior	No hacen falta
8.0, 8.1 y 8.2	7.2 a 8.1	No	Paquetes corregidos de Ondřej Surý para PHP 7.2 a 8.1; tu proveedor
1.7.8	7.1 a 7.4	No	Paquetes corregidos de Ondřej Surý para PHP 7.1 a 7.4; tu proveedor
1.7.7	7.1 a 7.3	No	Paquetes corregidos de Ondřej Surý para PHP 7.1 a 7.3; tu proveedor
1.7.0 a 1.7.6	5.4 a 7.2	No	Paquetes corregidos de Ondřej Surý para PHP 5.6 a 7.2; tu proveedor
1.6.1.x	5.2 a 7.1	No	Paquetes corregidos de Ondřej Surý para PHP 5.6 a 7.1; tu proveedor

Fuente: documentación oficial de requisitos de PrestaShop 9, PrestaShop 8 y PrestaShop 1.7, y aviso de seguridad de PHP.

Esta mañana parecía que las tiendas en PrestaShop 1.6, 1.7 y 8 se quedaban sin solución. Ya no es así: casi todas pueden tener PHP corregido sin migrar, siempre que su proveedor o su servidor lo instale. La diferencia con PrestaShop 9 es que dependen de terceros, y que la próxima vez puede no haber excepción.

¿No sabes qué versión de PHP tienes? En el panel de PrestaShop la verás en Parámetros avanzados > Información, en el apartado de configuración del servidor.

Qué hacer ahora

Lo primero: actualizar PHP

Si tu tienda está en un hosting compartido o gestionado, escribe hoy a tu proveedor y pídele que confirme que ha instalado PHP corregido. Si usas PHP 8.2 o superior, la versión debe ser 8.2.35, 8.3.36, 8.4.27 o 8.5.12. Si usas una versión anterior, pregunta expresamente si su PHP incluye la corrección de CVE-2026-109618 y CVE-2026-109619.

Un detalle que despista: en los paquetes de Ubuntu y Debian el número de versión a veces no cambia, porque solo se aplica la corrección. Por eso es mejor preguntar por los CVE que fiarse del número.

Si administras tu propio servidor con Ubuntu o Debian y usas los paquetes de Ondřej Surý (ppa:ondrej/php o packages.sury.org), ya hay paquetes corregidos para todas las versiones de PHP que mantiene, de la 5.6 a la 8.5, según confirman usuarios que ya los han recibido. Actualiza solo los paquetes de PHP y reinicia. Por ejemplo, para PHP 7.4:

sudo apt update
sudo apt install --only-upgrade 'php7.4-*'
sudo systemctl restart php7.4-fpm

Cambia 7.4 por tu versión, y reinicia Apache en lugar de PHP-FPM si usas mod_php. Con apt-cache policy php7.4-fpm puedes comprobar que se ha instalado el paquete nuevo. Si no aparece todavía, vuelve a intentarlo en unas horas: los paquetes se están publicando a lo largo del día.

Si usas el repositorio de Remi (habitual en CentOS, AlmaLinux o Rocky), PHP avisa de que hoy no tendrá actualización y recomienda pasar a los paquetes de la distribución. En servidores con CloudLinux, sus paquetes alt-php corregidos están en preparación.

Si no puedes actualizar hoy: reduce el riesgo

PHP propone varias medidas temporales. Ninguna hace el servidor seguro; solo cierran algunos caminos de ataque mientras llega la actualización.

Desactiva la barra de progreso de subida. Es la medida que ya circulaba esta mañana, y PHP la confirma para el segundo fallo. Las subidas de imágenes, CSV o módulos siguen funcionando igual; solo deja de verse la barra de progreso que pinta PHP.

Atención a dónde se pone, porque PHP ha sido claro: tiene que ir en el php.ini, en el pool de PHP-FPM o en la configuración del servidor web. No sirve ponerlo en el código de la tienda (ini_set()) ni en un fichero .user.ini. Si estás en un hosting compartido y no tienes acceso a esa configuración, pídeselo a tu proveedor.

Si administras el servidor, crea un fichero de configuración propio para que no se pierda al actualizar PHP, por ejemplo /etc/php/8.x/fpm/conf.d/99-no-upload-progress.ini:

session.upload_progress.enabled = Off

Y en el pool de PHP-FPM, para que ningún dominio pueda volver a activarlo:

php_admin_flag[session.upload_progress.enabled] = off

Es la configuración que compartió esta mañana DMNTR Network Solutions. Después, reinicia PHP-FPM (o Apache si usas mod_php) para que se apliquen en todos los procesos.

Si usas PHP 8.5, añade también fatal_error_backtraces = Off.

Limita el tamaño de las peticiones. PHP recomienda bajar post_max_size para dificultar el primer fallo. Como PrestaShop necesita subir ficheros, el valor que propone es 32M, con upload_max_filesize por debajo. Si importas CSV muy grandes, puede que tengas que partirlos mientras dure esta medida.

PHP también menciona quitar el límite de memoria (memory_limit = -1). En una tienda no lo aplicaríamos sin más: un proceso descontrolado podría comerse toda la memoria del servidor. Solo tiene sentido si el servidor ya tiene otro límite por encima, como un contenedor.

Comprueba que se ha aplicado. Crea un fichero con solo <?php phpinfo(); en la raíz, ábrelo en el navegador y busca session.upload_progress.enabled: debe aparecer como Off. Borra ese fichero en cuanto termines, porque muestra mucha información de tu servidor. No te fíes de php -i en la terminal: muestra la configuración de la línea de comandos, que no es la que usa la web.

Una capa extra si usas Cloudflare

El mismo 21 de octubre, Cloudflare publicó actualizaciones de emergencia en sus reglas gestionadas, tanto para planes de pago como para el plan gratuito. Añaden reglas nuevas que bloquean peticiones anómalas. Cloudflare no las vincula expresamente a estos fallos de PHP, pero coinciden en fecha.

Para que te protejan, las reglas administradas tienen que estar activadas. Compruébalo en Seguridad > WAF > Reglas administradas:

• En el plan gratuito, el Cloudflare Free Managed Ruleset.
• En los planes Pro, Business o Enterprise, el Cloudflare Managed Ruleset.

Si tu plan permite reglas personalizadas que lean el cuerpo de la petición, puedes añadir además una regla propia que bloquee las peticiones que intenten usar la barra de progreso de subida. En Seguridad > WAF > Reglas personalizadas, crea una regla con acción Bloquear y esta expresión:

any(http.request.body.form.names[*] == "PHP_SESSION_UPLOAD_PROGRESS") or http.request.body.raw contains "PHP_SESSION_UPLOAD_PROGRESS"

Ayuda, pero no basta: si alguien llega al servidor sin pasar por Cloudflare, ninguna de estas reglas sirve.

Plan de acción según tu versión de PrestaShop

Si tu tienda está en PrestaShop 9

1. Actualiza hoy PHP a 8.2.35, 8.3.36, 8.4.27 o 8.5.12, o pide a tu hosting que lo haga y te lo confirme.
2. Si tu servidor sigue en PHP 8.1, aprovecha para subir a 8.2 o superior. PrestaShop recomienda PHP 8.4 para la versión 9.0 y PHP 8.5 para la 9.1.
3. Hasta que esté actualizado, aplica las medidas temporales y activa las reglas de Cloudflare si lo usas.

Si tu tienda está en PrestaShop 1.6, 1.7 u 8

No puedes subir a PHP 8.2 sin migrar PrestaShop, porque la tienda dejaría de funcionar. Pero sí puedes tener tu versión actual de PHP corregida.

Hoy:

1. Pregunta a tu proveedor si su PHP ya incluye la corrección de CVE-2026-109618 y CVE-2026-109619 para tu versión. Si administras el servidor y usas los paquetes de Ondřej Surý, actualiza como explicamos arriba.
2. Mientras no lo tengas, aplica las medidas temporales y activa las reglas de Cloudflare si lo usas.
3. Si tu proveedor no va a ofrecer PHP corregido para tu versión, tómatelo como una urgencia: o cambias de proveedor o adelantas la migración.
4. Vigila la tienda en los próximos días: ficheros PHP nuevos que no reconozcas, cambios en el checkout o administradores que nadie ha creado.

En las próximas semanas:

• Planifica la migración a PrestaShop 9 con PHP 8.4 u 8.5. Esta vez ha habido corrección para versiones antiguas porque el fallo era muy grave; la próxima puede no haberla. Además, PHP 8.2 deja de tener soporte el 31 de diciembre de 2026.
• Antes de migrar, revisa que tus módulos y tu tema sean compatibles con PrestaShop 9. Es el paso que más tiempo suele llevar.

No queremos ser alarmistas, pero una tienda online que procesa pagos y datos de clientes no debería depender de que alguien haga una excepción para recibir parches de seguridad.

Conclusión

En Amarillo Limón te recomendamos comprobar hoy mismo que tu servidor tiene PHP corregido, sea cual sea tu versión de PrestaShop. Si quieres que lo revisemos por ti o que planifiquemos contigo la migración a PrestaShop 9, contacta con nosotros.

Fuentes

• PHP: aviso de seguridad y versiones corregidas (21/10/2026)
• PHP: aviso técnico de CVE-2026-109618
• PHP: aviso técnico de CVE-2026-109619
• PHP: aviso previo de la actualización de seguridad (20/10/2026)
• ma.ttias.be: cómo aplicar el parche en Ubuntu, Debian y RHEL
• Cloudflare: actualización de emergencia del WAF, planes de pago (21/10/2026)
• Cloudflare: actualización de emergencia del WAF, plan gratuito (21/10/2026)
• PrestaShop: requisitos del sistema (9, 8 y 1.7)
• Sansec: Critical PHP RCE CVE-2026-109618 y CVE-2026-109619
• Roots Discourse: mitigación en php.ini y regla de Cloudflare
• DMNTR Network Solutions: aviso a clientes y configuración de PHP-FPM (X)
• deb.sury.org: seguimiento de la actualización de los paquetes de Ondřej Surý