Blog › Problemas y soluciones

Vulnerabilidad crítica en PHP (octubre 2026): qué hacer si tienes PrestaShop

Dos fallos críticos de PHP permiten ejecutar código en el servidor sin contraseña. No se arreglan actualizando PrestaShop: qué comprobar, qué pedirle a tu hosting y qué hacer mientras tanto.

Jose Rosado · 23 de octubre de 2026 · 8 min de lectura

El equipo de PHP ha publicado parches de seguridad urgentes para resolver dos fallos críticos que permiten a un atacante ejecutar código en el servidor sin necesidad de contraseñas. Si gestionas una tienda online, este problema no se soluciona actualizando módulos ni esperando un parche del núcleo de tu tienda: la corrección hay que aplicarla en el PHP de tu servidor, y eso normalmente lo hace tu hosting.

A continuación explicamos qué ha ocurrido exactamente, por qué quienes trabajamos con PrestaShop nos encontramos en una situación particular con las versiones compatibles y qué pasos conviene dar hoy mismo para proteger el negocio sin provocar una caída de la web.

Qué ha pasado con PHP y por qué afecta a cualquier tienda online

Los avisos oficiales publicados por php.net entre el 20 y el 23 de octubre de 2026 detallan dos fallos catalogados con una gravedad de 9,2 sobre 10 (CVSS v4.0). El primero de ellos, identificado como CVE-2026-109618, se produce cuando el servidor se queda sin memoria en el instante exacto en que está procesando una petición entrante; al intentar limpiar esa memoria, el sistema puede dar por válidos datos que estaban incompletos. El segundo problema, CVE-2026-109619, permite que información interna de una petición anterior permanezca en la memoria y sea leída o utilizada por la siguiente petición que atienda ese mismo proceso.

Esto afecta a los entornos habituales donde corre PHP: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Además, php.net ha señalado que el riesgo es especialmente alto en configuraciones con mod_php, donde han demostrado que una petición externa puede activar el fallo antes de que el código de la tienda llegue a intervenir. El 23 de octubre se añadió otro aviso (CVE-2026-115560) sobre el gestor de sesiones en ejecución, aunque su probabilidad real es baja y queda cubierto con las mismas pautas de contención.

Conviene dejar algo muy claro: no es un fallo de PrestaShop ni de ninguno de tus módulos. Da igual que tengas la tienda actualizada a la última versión disponible; si el intérprete de PHP que ejecuta tu servidor no está corregido, el riesgo sigue existiendo.

La encrucijada de versiones: PrestaShop 8 y el soporte de PHP

Aquí es donde la situación se vuelve delicada para los comerciantes. La solución natural ante un fallo de seguridad en un programa informático suele ser subir de versión. Sin embargo, php.net publicó las correcciones oficiales en las ramas que aún mantienen soporte activo: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

Si miras la documentación oficial sobre cómo actualizar PHP en PrestaShop, comprobarás que PrestaShop 8.0, 8.1 y 8.2 están diseñados para funcionar con versiones comprendidas entre PHP 7.2 y PHP 8.1. Las versiones superiores, como PHP 8.2 o PHP 8.3, no están soportadas en PrestaShop 8. Si intentas cambiar el selector de tu hosting directamente a PHP 8.2 para obtener el parche oficial de php.net, te arriesgas a un error 500 o la pantalla en blanco: es una combinación que PrestaShop no soporta y nadie sabe cómo responderán tu tema y tus módulos.

Por su parte, PHP 8.1 ya no recibe versiones empaquetadas oficiales desde php.net. Para las versiones 7.4, 8.0 y 8.1, el equipo de PHP únicamente facilitó parches mínimos en código fuente. Esto significa que si tienes PrestaShop 8, dependes de que tu empresa de hosting o tu distribución de Linux haya aplicado ese parche sobre su propio paquete de PHP 8.1.

PrestaShop 9 ya está disponible y admite PHP moderno, pero dar ese salto requiere comprobar plantillas, adaptaciones a medida y módulos uno a uno. En nuestra propia tienda revisamos cada cambio a fondo antes de plantear una subida de versión del gestor, porque un cambio de rama mayor en plena temporada comercial puede costar muchas ventas si algo falla. No es momento de hacer migraciones apresuradas empujados por el miedo.

Cómo comprobar qué versión tienes y qué preguntar a tu hosting

Para saber en qué punto se encuentra tu comercio, entra en el panel de administración de PrestaShop y dirígete a Parámetros avanzados > Información. En el bloque de comprobaciones verás reflejada la versión exacta de PHP que está procesando las visitas.

Si ves que tu tienda utiliza PHP 8.1, no des por hecho que estás desprotegido, pero tampoco asumas que estás a salvo. En muchas distribuciones de Linux para servidores y en proveedores de hosting con soporte extendido, los administradores incorporan las correcciones de seguridad manteniendo el mismo número de versión (lo que técnicamente se conoce como un backport). Tu panel puede seguir marcando PHP 8.1 y tener el parche aplicado en el sistema operativo del servidor.

La única forma de salir de dudas es escribir una consulta al soporte técnico de tu alojamiento web con preguntas concretas:

• Pregunta si han aplicado en sus servidores los parches para las incidencias de seguridad de PHP anunciadas el 21 de octubre de 2026.
• Indica que tu tienda necesita mantenerse en PHP 8.1 por compatibilidad y consulta si disponen de paquetes parcheados para esa rama.
• Pídeles confirmación de si se han reiniciado los procesos de PHP tras la intervención, ya que un parche aplicado en disco no protege hasta que el servicio se reinicia.

Medidas provisionales mientras esperas la respuesta del servidor

El equipo de php.net subraya que no existe un sustituto definitivo para el parche de seguridad. Un cortafuegos para aplicaciones web (WAF) ayuda a frenar intentos genéricos, pero no garantiza la protección completa. Del mismo modo, ocultar los mensajes de fallo mediante directivas como display_errors o error_reporting no mitiga la vulnerabilidad en absoluto.

No obstante, si tu hosting todavía no ha confirmado la actualización o necesitas ganar tiempo, las notas técnicas oficiales proponen algunos ajustes temporales de configuración que reducen la superficie de ataque:

• Desactivar el progreso de subida en sesiones: Establecer la directiva session.upload_progress.enabled=0. Este cambio debe realizarse obligatoriamente en el archivo principal php.ini o en la configuración del grupo de procesos (pool) de PHP-FPM. Los avisos advierten de que no sirve de nada intentar modificarlo mediante la función ini_set() en el código ni a través de un archivo local .user.ini.
• Acotar el tamaño máximo de las peticiones: Limitar el parámetro post_max_size a 32M (tamaño suficiente para que puedas seguir subiendo imágenes de producto desde el catálogo) y asegurarte de que upload_max_filesize mantenga un valor inferior a post_max_size. Si tu web no admitiera subida de ficheros de ningún tipo, el límite aconsejado por php.net desciende a 8M.
• Reiniciar los servicios: Cualquier ajuste en estos archivos requiere reiniciar los procesos de PHP (bien sea PHP-FPM o el servidor Apache) para que surta efecto. Si la infraestructura corre bajo contenedores Docker, es necesario reconstruir la imagen.

Qué errores debes evitar cometer con las prisas

Cuando salta una alerta de este calibre en los medios técnicos, la tentación de tocar opciones sin medir las consecuencias es enorme. Si te equivocas de camino, el coste de dejar la tienda inaccesible suele ser mayor que el propio riesgo inicial.

El primer error es entrar al panel del hosting y cambiar la versión a PHP 8.2 o PHP 8.3 creyendo que así se soluciona todo de un clic. PrestaShop 8 no está soportado en esas versiones y puedes acabar con la tienda caída. El segundo error es intentar actualizar a PrestaShop 9 a toda prisa sobre la tienda en producción: cambiar de versión principal exige comprobar si tus temas y módulos son compatibles, algo que siempre debe hacerse con calma en un entorno de pruebas.

Antes de aplicar cualquier modificación o pedir cambios de configuración drásticos a tu proveedor, recuerda la regla de oro: hacer una copia de seguridad completa, guardando tanto la base de datos como los archivos de la tienda, prestando especial atención a las carpetas /modules/, /themes/, /override/ e /img/.

El orden exacto de lo que conviene hacer hoy

Para resolver esta situación con método y sin poner en peligro las ventas, este es el orden de trabajo que te recomendamos seguir hoy mismo:

1. Comprueba tu punto de partida: Entra en Parámetros avanzados > Información y anota qué versión de PHP muestra tu PrestaShop.
2. Contacta con tu soporte técnico: Pregunta directamente a tu hosting si los servicios de PHP de tu servidor cuentan con el parche para las vulnerabilidades de octubre de 2026. Si estás en PHP 8.1, pide confirmación explícita sobre si su paquete incluye las correcciones adaptadas.
3. Aplica las directivas de contención: Si el proveedor tarda en responder o te indica que tardará unos días en actualizar sus sistemas, solicita o configura en el php.ini el parámetro session.upload_progress.enabled=0 y los límites moderados en post_max_size.
4. Exige o realiza el reinicio: Verifica que se reinicien los procesos de PHP-FPM o Apache tras tocar la configuración o aplicar el parche.
5. Limpia la caché de la tienda: Cada vez que se modifica la configuración del entorno, entra en Parámetros avanzados > Rendimiento y pulsa en "Borrar caché" para evitar incoherencias en páginas cacheadas.
6. Comprueba el proceso de compra: Navega por la web como si fueras un cliente, añade un producto a la cesta y llega hasta la pasarela de pago para confirmar que todo responde con normalidad.

La seguridad de una tienda consiste en aplicar las medidas correctas en el lugar adecuado, sin precipitarse y entendiendo qué pieza del servidor se está tocando en cada momento.