PHP2Shell: qué es la vulnerabilidad crítica de PHP y qué hacer con su WordPress o PrestaShop

PHP2Shell es el nombre con el que se conocen dos vulnerabilidades críticas de PHP, el lenguaje con el que funcionan WordPress, WooCommerce y PrestaShop, que se corrigieron el 21 de octubre de 2026. Permiten a un atacante ejecutar su propio código en el servidor de la web sin usuario ni contraseña, y según el INCIBE-CERT se notificaron ataques antes de que saliera la corrección. No se arregla actualizando WordPress, PrestaShop ni sus plugins: hay que pasar el PHP del servidor a la versión 8.2.35, 8.3.36, 8.4.27 u 8.5.12. Y si su web funciona con PHP 8.1 o anterior, no hay versión corregida oficial.

Le contamos qué es, a qué webs afecta, cómo saber en dos minutos si la suya está corregida, qué hacer si funciona con un PHP antiguo y qué no la protege, con lo que se sabe a 23 de octubre. No es una guía para actualizar un servidor: es lo que necesita saber para pedírselo a quien corresponde.

Qué es PHP2Shell y por qué es tan grave

PHP es el programa del servidor que prepara cada página de su web antes de enviarla al navegador. WordPress, PrestaShop, sus plugins y sus módulos están escritos en PHP, así que un fallo en PHP no es el fallo de una web: es el fallo de todas las webs que funcionan con él a la vez, se hayan hecho con lo que se hayan hecho.

El aviso de seguridad de PHP describe dos fallos distintos, cada uno con una gravedad de 9,2 sobre 10:

• CVE-2026-109618: cuando PHP se queda sin memoria a mitad de una visita, puede dejar datos a medio preparar que después trata como buenos. Se provoca enviando formularios preparados para agotar la memoria.
• CVE-2026-109619: restos de una visita anterior que siguen en la memoria de PHP y que la siguiente visita, atendida por el mismo proceso, usa antes de que se limpien.

Según los avisos técnicos de PHP (el del primero y el del segundo), el resultado confirmado es el peor posible en una web: ejecutar código en el servidor con los permisos de la propia web, sin entrar con ningún usuario. Con eso, un atacante puede hacer lo mismo que en cualquier hackeo: cambiar la web, esconder redirecciones, crear páginas de spam o llevarse los datos de sus clientes. Las señales de un ataque así las contamos en cómo saber si su WordPress ha sido hackeado.

PHP2Shell, día a día, hasta el 23 de octubre de 2026

Fecha	Qué pasó
20 de octubre	PHP anuncia una actualización de seguridad crítica para el día siguiente y pide prepararse para instalarla en cuanto salga.
21 de octubre	Salen PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12, con los dos fallos corregidos. El INCIBE-CERT publica su aviso, de importancia crítica, y WordPress.org y PrestaShop explican a sus usuarios qué hacer.
22 de octubre	Según la empresa de seguridad Rapid7, ya circulan pruebas de concepto públicas del ataque, que de momento solo funcionan en combinaciones concretas de servidor y versión.
23 de octubre	PHP avisa de un tercer fallo (CVE-2026-115560), que solo se da con una configuración poco habitual, y recomienda desactivar el progreso de subida de las sesiones hasta su próxima versión.

A qué webs afecta PHP2Shell: WordPress, WooCommerce, PrestaShop y cualquier web en PHP

Según PHP, están en riesgo todas las instalaciones de PHP que sirven páginas web, con cualquiera de las formas habituales de montarlo en un servidor: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo más alto, con mod_php: ahí el ataque puede funcionar antes de que se ejecute una sola línea de la web.

Por eso los dos proyectos lo dijeron claro el mismo día 21. WordPress.org: el fallo no es de WordPress, afecta a cualquier servidor con una aplicación en PHP, y no hace falta ni está prevista ninguna actualización de WordPress. PrestaShop: no está en PrestaShop ni en ningún módulo, y actualizar la tienda o sus módulos no lo arregla.

Lo que importa, entonces, es qué versión de PHP tiene su web, y ahí está el problema de fondo: muchas webs funcionan con versiones que ya no reciben correcciones. Según las estadísticas de WordPress.org, en octubre de 2026 una de cada tres webs WordPress, el 34 %, funciona con PHP 8.1 o anterior, para las que PHP ya no publica versiones corregidas; casi la mitad de ellas, con PHP 7.4, sin parches desde 2022.

En las tiendas PrestaShop es todavía más claro, por las versiones de PHP que admite cada una, que repasamos en actualizar PrestaShop: la 1.7 llega como mucho a PHP 7.4, y la 8, a PHP 8.1. Una tienda en PrestaShop 1.7 u 8 no puede funcionar con ninguna versión corregida oficial de PHP; solo la 9 las admite.

Cómo saber si su web está protegida frente a PHP2Shell

Se tarda dos minutos y no hace falta tocar nada:

1. Mire la versión de PHP de su web. En WordPress, en Herramientas › Salud del sitio › Información › Servidor; en PrestaShop, en Parámetros avanzados › Información. Muchos hostings la enseñan también en su panel.
2. Compare el número completo, con sus tres partes: están corregidas la 8.2.35, la 8.3.36, la 8.4.27, la 8.5.12 y las posteriores de cada rama. Una 8.3.30, por ejemplo, no lo está.
3. Si sale un número más bajo, pregunte a su hosting. PrestaShop propone la pregunta exacta: si se ha aplicado la corrección de CVE-2026-109618 y CVE-2026-109619 a la versión de PHP con la que funciona su web. Y pida la respuesta por escrito.
4. Repítalo con cada web que tenga: en el mismo hosting, cada una puede funcionar con un PHP distinto.

Un número más bajo no siempre significa que la web esté expuesta: algunas distribuciones de Linux y algunos proveedores aplican la corrección sin cambiar el número, como advierte PrestaShop. Ante la duda, la respuesta la tiene quien gestiona el servidor.

Si su web funciona con PHP 8.1 o anterior

PHP solo mantiene las ramas 8.2 a 8.5. Para las anteriores, su aviso dice que no habrá versión nueva: algunas distribuciones y proveedores de soporte extendido ofrecen la corrección adaptada, y el propio equipo de PHP ha publicado, por la gravedad del caso, unos parches mínimos en código fuente para PHP 7.4, 8.0 y 8.1, pensados para quien compila PHP por su cuenta. Para PHP 7.3 y anteriores no hay ni eso.

En un hosting compartido, aplicar esos parches no está en su mano: depende de su hosting. Y si gestiona su propio servidor y no puede ponerlo al día, WordPress.org recuerda que varias agencias nacionales de ciberseguridad recomiendan desconectarlo mientras prepara el cambio; el aviso del INCIBE-CERT pide aislar de las redes públicas los sistemas que no se puedan actualizar.

A partir de ahí, el trabajo va en dos tiempos:

• Ahora: que su web funcione con un PHP que tenga la corrección, aunque sea la del proveedor para su versión actual. PrestaShop lo dice así: lo inmediato es tener PHP corregido, no precipitarse con una actualización grande de la tienda.
• En las próximas semanas: pasar a una rama mantenida, probándolo antes en una copia de la web. Mejor PHP 8.3 u 8.4 que la 8.2, que deja de recibir parches el 31 de diciembre de 2026: subir ahora a la 8.2 solo da diez semanas. En PrestaShop 1.7 u 8, eso significa pasar a la 9.

Las medidas temporales del hosting

Mientras tanto, PHP propone ajustes que el hosting puede aplicar en el servidor: quitar el límite de memoria de PHP (memory_limit), bajar el tamaño máximo de los formularios (post_max_size) o desactivar el progreso de subida de las sesiones (session.upload_progress.enabled). Reducen algunos caminos del ataque, pero PHP lo deja claro: no hacen segura una instalación. Y tienen que ir en la configuración del servidor: PHP advierte de que no sirve ponerlos desde la propia aplicación ni en un archivo .user.ini.

Cómo se trabaja un aviso como PHP2Shell en un mantenimiento web

Un fallo de PHP cae en tierra de nadie: la web es del cliente, el servidor es del hosting y nadie mira el PHP hasta que algo se rompe. En nuestro mantenimiento web, el PHP de cada web es parte del trabajo:

1. Comprobar qué PHP tiene cada web, con su número exacto, y si lleva la corrección.
2. Pedírselo al hosting cuando es cosa suya, o decirle al cliente qué tiene que pedir y a quién, sin que tenga que cambiar de hosting.
3. Revisar la web: hubo ataques antes de la corrección, así que se buscan usuarios que nadie ha creado, archivos nuevos y cambios que nadie ha hecho.
4. Preparar el cambio de rama cuando hace falta: el tema, los plugins o los módulos, probados antes con el PHP nuevo en una copia de la web.
5. Hacer el cambio con una copia de seguridad recién hecha y revisar después los formularios, las compras y los errores.

Lo hacemos igual en el mantenimiento WordPress y en el mantenimiento PrestaShop. Y si encuentra señales de que alguien ya ha entrado, para eso está la reparación web urgente.

Lo que no protege su web de PHP2Shell

• Actualizar WordPress, PrestaShop, los plugins o los módulos: conviene tenerlos al día, pero este fallo está debajo de todos ellos.
• Un plugin de seguridad: funciona dentro de la web, y con mod_php el ataque puede ocurrir antes de que la web llegue a ejecutarse. Los cortafuegos del hosting o de servicios externos pueden frenar parte de los ataques, pero no sustituyen a actualizar PHP.
• Ocultar los errores de la web: según PHP, esconder los avisos no evita el fallo.
• Pasar a la 8.2 y olvidarse: la 8.2.35 está corregida, pero la rama se queda sin parches el 31 de diciembre.
• Esperar a ver si atacan: los ataques empezaron antes de la corrección y ya circulan pruebas de concepto públicas.

Cuánto cuesta proteger su web de PHP2Shell

Si su web ya funciona con PHP 8.2 a 8.5, lo normal es que el hosting la ponga al día dentro de la misma rama sin que usted note nada. Lo que lleva trabajo es cambiar de rama: depende de cuántos plugins o módulos tenga, de si el tema es antiguo o está modificado y, en PrestaShop, de si hay que pasar de la 1.7 o la 8 a la 9. Por eso no trabajamos con tarifas cerradas: en nuestra página de precios de mantenimiento web le explicamos cómo lo calculamos y, si quiere que miremos su web, escríbanos.

Preguntas frecuentes sobre PHP2Shell