El 20 de octubre saltó un aviso que puso en vilo a medio internet: dos vulnerabilidades graves en PHP, el lenguaje con el que funciona tu tienda PrestaShop, que permiten a un desconocido tomar el control del servidor sin usuario ni contraseña. Se les conoce como PHP2Shell. PHP publicó el arreglo el 21 de octubre, y lo que tienes que hacer depende de una sola cosa: la versión de PHP en la que corre tu tienda.
Te lo contamos sin tecnicismos: qué ha pasado, cómo saber si te afecta, qué hacer hoy y cómo saber si tu hosting ya ha puesto el arreglo.
¿Sin tiempo para leerlo entero? Por 45 € revisamos tu tienda hoy: si está expuesta a PHP2Shell y qué hay que hacer. Es una hora de soporte a precio cerrado; si hiciera falta más, te lo decimos antes de seguir. Te respondemos en menos de 12 horas, también en fin de semana.
PHP es el motor que hay debajo de PrestaShop, WordPress, Magento y la mayoría de tiendas y webs del mundo. Los dos fallos, registrados como CVE-2026-109618 y CVE-2026-109619, tienen una nota de gravedad de 9,2 sobre 10. En la práctica, quien sepa aprovecharlos puede ejecutar lo que quiera en tu servidor: dejar una puerta trasera, robar los datos de tus clientes o meter en tu tienda un falso captcha como el de ClickFix.
Lo que lo hace distinto de otros avisos es que el ataque no pasa por PrestaShop ni por ningún módulo. Ocurre en PHP, antes de que tu tienda llegue a leer la visita. Da igual lo bien cuidada que esté: si el PHP del servidor es vulnerable, la tienda también.
Y la información se filtró antes de tiempo. La empresa de seguridad Sansec cuenta que junto al aviso apareció la captura de una herramienta de ataque ya preparada, y esperaba ataques masivos en cuanto se publicara el arreglo. Según la misma fuente, Cloudflare ya había visto los primeros intentos y puso reglas para frenarlos.
Lo más probable es que sí. En su aviso de seguridad, PHP considera en riesgo cualquier instalación que sirva páginas web, sea cual sea la forma en que el servidor la ejecuta, y el riesgo más alto en los servidores Apache con mod_php, donde ya hay un ataque demostrado que funciona sin usuario ni contraseña. Sansec habla de cualquier servidor con PHP 5.4 o posterior, que en la práctica es cualquier tienda PrestaShop en marcha hoy.
La pregunta que de verdad importa es otra: ¿te llega el arreglo? PHP lo ha corregido en las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Para las versiones antiguas, que ya no tienen soporte oficial, PHP publicó el parche sin sacar versión nueva, y en uno o dos días los paneles y sistemas que usan los hostings lo convirtieron en una actualización normal: cPanel y CloudLinux, desde PHP 5.2 hasta 8.1; DirectAdmin, Ubuntu, Red Hat, AlmaLinux y el repositorio de Remi, en las versiones de 7.4 a 8.1 que todavía mantienen. Y cada versión de PrestaShop solo funciona con unas versiones concretas de PHP:
Dicho de otra forma: casi cualquier tienda puede tener hoy un PHP sin este fallo. Pero si no es PrestaShop 9, depende de que tu hosting haya instalado el parche, y como el número de versión no cambia, no se ve a simple vista: hay que preguntárselo. Además es un parche de urgencia: PHP 8.1 y anteriores no tienen soporte oficial, así que con el próximo fallo volverás a depender de que alguien lo arregle por su cuenta.
Entra en el panel de tu tienda y abre Parámetros Avanzados → Información. Ahí verás la versión de PrestaShop y, un poco más abajo, la de PHP. Con esos dos números ya sabes en qué caso estás.
Poner la tienda en mantenimiento desde el panel no te protege esta vez: PHP lee la visita antes de que PrestaShop decida enseñar la página de mantenimiento.
¿Prefieres que se encargue alguien? Con el mantenimiento de PrestaShop nos ocupamos nosotros: actualizamos PHP, PrestaShop y módulos después de probarlos, hacemos las copias y vigilamos tu tienda, para que el próximo aviso no te toque a ti.
PHP propone unos ajustes del servidor que cierran algunos caminos del ataque, y avisa de que no dejan la tienda segura: solo la actualización lo hace. Sansec añade otra medida de urgencia: bloquear en el servidor el tipo de envío con el que viajan los archivos que se suben a una web. Tiene un precio: mientras esté puesta, nadie puede subir archivos a tu tienda. Ni tú las fotos de un producto nuevo, ni tus clientes un adjunto en el formulario de contacto. La tienda sigue vendiendo con normalidad.
Sirve para ganar unos días, no para quedarse así: o tu hosting instala el parche, o te cambias a uno que lo tenga. Y la próxima vez que salga un fallo en PHP —y saldrán—, tu tienda volverá a depender de eso, porque PHP 8.1 y anteriores ya no tienen soporte oficial.
Qué PHP admite cada versión de PrestaShop y hasta cuándo recibe parches lo tienes en una tabla en qué versión de PHP necesita PrestaShop.
Es la pregunta que siempre se aplaza porque la tienda funciona. PHP2Shell es lo que pasa cuando se aplaza demasiado: el día que llega el problema no lo eliges tú, y que te llegue el arreglo depende de otros.
Pasar a PrestaShop 9 te deja en un PHP que recibe parches durante años. Se hace sin cerrar la tienda, te llevas productos, clientes, pedidos y posiciones en Google, y una tienda pequeña cuesta desde 690 €. Lo contamos entero en actualizar PrestaShop 1.7 o 1.6 a 9, y en nuestra página de migración de PrestaShop 1.6 y 1.7 a 9.
Y si prefieres no estar pendiente de estos avisos, para eso está el mantenimiento PrestaShop: vigilamos tu tienda, mantenemos sus módulos al día y, si está en un servidor de BK Modules, también PHP, para que un aviso así no te pille desprevenido.
Si no sabes en qué caso estás, si tu hosting no te contesta o si tu tienda es 1.6, 1.7 u 8 y quieres salir de ahí, cuéntanos tu versión de PrestaShop y la de PHP. Te decimos qué hacer hoy y, si hace falta, te damos precio cerrado para pasar a PrestaShop 9.
Versiones corregidas: 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Para 7.4, 8.0 y 8.1, PHP publica el arreglo mínimo en código fuente, enlazado desde su aviso, sin versión nueva. Los paquetes con el parche conservan el número de versión, así que php -v no lo distingue: hay que mirar la revisión del paquete (rpm -q, dpkg -l). Revisiones corregidas: cPanel EasyApache 4 ea-php74 7.4.33-19, ea-php80 8.0.30-12, ea-php81 8.1.34-5; CloudLinux ea-php / alt-php 5.2–8.5 (21–22/10); Remi 7.4.33-31, 8.0.30-21, 8.1.34-6; Ubuntu 22.04 8.1.2-1ubuntu2.28. Las medidas parciales que da PHP, en el php.ini, en el pool de PHP-FPM (php_admin_value) o en la configuración del servidor, nunca con ini_set() ni .user.ini, y reiniciando todos los procesos:
; CVE-2026-109618
memory_limit = -1
post_max_size = 32M ; 8M si no se suben archivos
; CVE-2026-109619
session.upload_progress.enabled = 0
; solo en PHP 8.5
fatal_error_backtraces = 0PHP pide no sustituir memory_limit por límites del sistema (RLIMIT_AS, RLIMIT_DATA). La medida de Sansec, bloquear multipart/form-data (rompe todas las subidas de archivos, panel incluido), en Apache:
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]En Nginx:
if ($http_content_type ~* "multipart/form-data") {
return 403;
}Con Cloudflare, limitar el puerto 443 del origen a sus rangos de IP; si no, el ataque llega directo a la IP del servidor.
¿Prefieres que lo montemos nosotros? Lo dejamos funcionando en tu tienda, con seguimiento y soporte.
Nadie entra desde internet solo con este fallo, pero quien ya esté dentro puede quedarse con el servidor. Qué hacer hoy…
El PHP que admite cada versión de PrestaShop, hasta cuándo recibe parches cada PHP y qué hacer antes de que PHP 8.2…
El Black Friday 2026 es el 27 de noviembre. Lo que tu tienda online tiene que tener listo para vender en toda Europa…
Un módulo, una app, un servidor que da guerra o algo urgente. Te respondemos en menos de 24 horas, con un presupuesto cerrado con precio y fecha.
