Si tu web funciona con WordPress, WooCommerce, Drupal, Joomla, Magento o cualquier otro desarrollo en PHP, esta semana te toca revisar el servidor. Actualizar los plugins no basta. PHP2Shell es un fallo del propio PHP que permite a un atacante ejecutar código en tu servidor sin contraseña. Y ya hay ataques en marcha.
En resumen: qué hacer con PHP2Shell
- Qué es: dos vulnerabilidades críticas en el núcleo de PHP, CVE-2026-109618 y CVE-2026-109619, las dos con una nota de 9,2 sobre 10 (CVSS 4.0). Permiten ejecutar código en el servidor sin iniciar sesión.
- A quién afecta: a cualquier instalación de PHP que atienda peticiones web, con independencia de la aplicación que corra encima.
- La solución: actualizar PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, publicadas el 21 de octubre de 2026. Es la única corrección completa.
- Lo que no lo arregla: actualizar WordPress, el tema o los plugins. El fallo está por debajo, en el intérprete.
- Si tienes PHP 8.1 o anterior: no hay versión oficial corregida. Toca migrar de rama o pedir a tu proveedor un paquete con el parche aplicado.
¿Qué es PHP2Shell?
PHP2Shell es el nombre que recibe una cadena de explotación que combina dos vulnerabilidades del núcleo de PHP. Un atacante puede enviar una petición web manipulada y ejecutar código en el servidor con los permisos del usuario del servidor web. No necesita usuario ni contraseña, y tampoco depende de un plugin mal programado.
Las dos piezas son distintas:
- CVE-2026-109618, corrupción por falta de memoria. Cuando PHP se queda sin memoria mientras todavía está leyendo los datos de una petición, la limpieza posterior trata esos datos a medio preparar como si fueran válidos.
- CVE-2026-109619, estado residual entre peticiones. Es un fallo de tipo use-after-free: una petición deja apuntada una zona de memoria ya liberada y la siguiente petición que atiende ese mismo proceso puede usarla. El equipo de PHP confirma que este fallo, como mínimo, permite leer memoria del proceso, y ahí pueden aparecer contraseñas, tokens o claves de API.
El hallazgo se atribuye a los investigadores de Calif. La PHP Foundation reconoce también a OpenAI y a Wiz, entre otros, y tanto Calif como Wiz han dicho que usaron modelos de inteligencia artificial en la investigación.
¿Por qué es tan grave?
Hay muchas vulnerabilidades críticas al año, pero esta junta cuatro rasgos que rara vez coinciden:
- No hace falta autenticarse. Basta con poder enviar una petición HTTP a la web, y eso puede hacerlo cualquiera.
- No depende de tu código. En la configuración más expuesta, Apache con
mod_php, el ataque se dispara antes de que se ejecute una sola línea de tu aplicación. Según Datadog, cualquier script PHP expone el camino vulnerable, incluso uno que solo devuelve un «Hola mundo». - Afecta a una década de versiones. Calif sitúa el código afectado más antiguo en PHP 5.4.0, publicado en 2012.
- Hay ataques en marcha. Lo explicamos con detalle más abajo.
Calif asegura haber confirmado la ejecución remota de código sin autenticación contra versiones concretas de WordPress, Drupal, Joomla y Magento. No son fallos de esos gestores: son el ejemplo de lo que ocurre cuando el intérprete que tienen debajo está roto.
Durante el anuncio circularon identificadores con una nota de 10 sobre 10. La PHP Foundation aclaró que era un error: la puntuación oficial es 9,2. No cambia nada en la práctica, porque sigue siendo crítica.
¿Se está explotando ya?
Sí, aunque no todas las fuentes coinciden en la magnitud. Así quedó la cronología:
- 17 de octubre de 2026. Amazon Threat Intelligence registra en MadPot, su red de servidores trampa, un intento de explotación. Fue cuatro días antes de que se hiciera público el fallo, y AWS reconoce que no sabe cómo consiguió el atacante esa información.
- 20 de octubre. Los identificadores de las CVE se filtran en Hacker News y redes sociales. El equipo de PHP publica un aviso previo y CERT-EU emite su alerta.
- 21 de octubre. PHP adelanta un día las versiones corregidas, previstas para el 22, por culpa de la filtración. Ese mismo día AWS detecta varios exploits de prueba y Cloudflare informa de «primeros ataques».
- Después del parche. AWS describe PHP2Shell como «ampliamente explotado» y HKCERT da por explotadas las dos CVE. Bitdefender, en cambio, decía el 22 de octubre que su telemetría no mostraba intentos, y la CISA no lo había incluido aún en su catálogo de vulnerabilidades explotadas.
Nuestra lectura: cuando hay exploits públicos y escaneos masivos que no eligen víctima, esperar a que el consenso sea unánime es esperar demasiado. Para una web pequeña, el riesgo no es que alguien la elija como objetivo, sino que un robot la encuentre en un barrido.
¿Qué versiones de PHP están afectadas y cuáles lo arreglan?
Está afectada cualquier versión anterior a las corregidas, y también da igual cómo se ejecute PHP: mod_php de Apache, PHP-FPM, php-cgi, FrankenPHP o LiteSpeed. El equipo de PHP considera mod_php la variante de mayor riesgo. En PHP-FPM la explotación se ha validado bajo ciertas condiciones de la aplicación, que es una forma técnica de decir «también, pero no siempre».
| Rama de PHP | Versión corregida | Qué hacer |
|---|---|---|
| 8.5 | 8.5.12 | Actualizar. |
| 8.4 | 8.4.27 | Actualizar. |
| 8.3 | 8.3.36 | Actualizar. |
| 8.2 | 8.2.35 | Actualizar. |
| 7.4 a 8.1 | Sin versión oficial | Paquete parcheado de tu distribución o proveedor, o migrar a 8.2 o superior. |
| 5.4 a 7.3 | Sin corrección | Migrar. Mientras tanto, la CISA recomienda sacar el sistema de internet. |
Ojo con un detalle que confunde a mucha gente: algunas distribuciones de Linux aplican el parche sin cambiar el número de versión. Si tu proveedor dice que ya está corregido aunque veas, por ejemplo, 8.1.2, puede ser verdad. Pide que te lo confirmen por escrito.
Cómo saber si tu web es vulnerable
La pregunta no es qué PHP tiene instalado el servidor, sino qué PHP está sirviendo tu web. No siempre coinciden: el comando php -v de la consola puede corresponder a otra instalación distinta de la que atiende las visitas.
- Si usas WordPress: entra en Herramientas → Salud del sitio → Información → Servidor. La versión de PHP que aparece ahí es la que está ejecutando tu web.
- Si tienes hosting compartido: busca en el panel (cPanel, hPanel, Plesk) el selector de versión de PHP. Si no ves la subversión completa, por ejemplo 8.3.36 y no solo 8.3, escribe a soporte y pregunta literalmente si su PHP ya incluye las correcciones de CVE-2026-109618 y CVE-2026-109619.
- Si administras tu propio servidor: revisa todas las instalaciones de PHP, no solo la principal. Ten en cuenta las ramas paralelas, los contenedores Docker que traen su propio intérprete y los paquetes del panel de control.
- Comprueba que el cambio se aplicó de verdad. Después de actualizar, reinicia todos los procesos de PHP (Apache o PHP-FPM) y vuelve a mirar la versión desde la web, no desde la consola.
Qué hacer hoy si tu web usa PHP
- Actualiza PHP a la versión corregida de tu rama, o pide a tu hosting que lo haga. Es la única solución completa.
- Si no puedes actualizar ya, reduce la exposición mientras tanto. El equipo de PHP propone dos ajustes en la configuración del servidor, no desde la aplicación:
session.upload_progress.enabled=0, que solo frena CVE-2026-109619, y en PHP 8.5 ademásfatal_error_backtraces=0. Para CVE-2026-109618 sugiere limitar el tamaño de las peticiones en el proxy o el servidor web. Ninguno de estos ajustes deja el sistema a salvo. - Si estás detrás de Cloudflare, ya tienes reglas de cortafuegos para los vectores conocidos. Cloudflare las define como un parche provisional, no como un sustituto de la actualización.
- Busca señales de que alguien ya entró. Desde el 17 de octubre en adelante, revisa los registros del servidor en busca de peticiones POST con datos de formulario que contengan
PHP_SESSION_UPLOAD_PROGRESS, errores «Allowed memory size… exhausted» en «Unknown on line 0», procesos de PHP que lanzan una terminal y archivos modificados que nadie reconoce. - Si encuentras indicios, cambia las credenciales. Como el fallo permite leer memoria, rota las contraseñas de la base de datos, las claves de API y las sales de WordPress, y cierra todas las sesiones abiertas.
Si llegas tarde, no te angusties: actualizar hoy sigue siendo mucho mejor que actualizar la semana que viene. Y si la web es la de un negocio con datos de clientes, la revisión de registros no es opcional.
Cómo actuamos en Caverna Tecnológica
Cuando sale un fallo de este calibre, nuestro protocolo con los proyectos que mantenemos es siempre el mismo, y lo contamos porque es el que recomendaríamos a cualquiera:
- Inventario primero. Antes de tocar nada, listamos cada servidor, contenedor y hosting donde corre PHP, con la versión que de verdad sirve la web. Es más fácil olvidar una instalación que equivocarse al parchear.
- Parcheamos de lo más expuesto a lo menos. Empezamos por las tiendas online y las webs con formularios o zona de clientes. Cuando el servidor no es nuestro, abrimos una incidencia con el proveedor y le hacemos seguimiento hasta tener la confirmación.
- Verificamos, no damos por hecho. Comprobamos la versión desde la propia web después de reiniciar los procesos, porque «ya está actualizado» y «ya está funcionando la versión nueva» no son la misma frase.
- Revisamos los registros desde la fecha del primer ataque conocido, no desde el día del anuncio.
- Avisamos al cliente en un lenguaje claro: qué ha pasado, si le afectaba, qué hemos hecho y si tiene que hacer algo él, como cambiar una contraseña.
Y hay una lección de fondo que va más allá de este parche. Una web estática, como la que estás leyendo, no ejecuta PHP al servir sus páginas, así que PHP2Shell no tiene por dónde entrar en ella. No significa que WordPress sea mala idea: para muchos proyectos sigue siendo la opción sensata. Pero si tu web es sobre todo escaparate, cada capa que no necesitas es una capa más que vigilar cada vez que aparece un fallo como este.
Preguntas frecuentes sobre PHP2Shell
¿Actualizar WordPress o los plugins me protege de PHP2Shell?
No. PHP2Shell es un fallo del intérprete de PHP, no de WordPress ni de sus plugins. La única corrección completa es actualizar PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o instalar un paquete del proveedor que incluya el parche.
¿Mi hosting compartido ya lo ha corregido?
Depende del proveedor. Revisa en tu panel la versión completa de PHP y, si no aparece o es anterior a las corregidas, pregunta a soporte si su PHP incluye las correcciones de CVE-2026-109618 y CVE-2026-109619. Pide la respuesta por escrito.
Tengo PHP 7.4 u 8.1, ¿qué hago?
No hay versión oficial corregida para esas ramas. Las opciones son instalar un paquete parcheado de tu distribución o proveedor, o migrar a PHP 8.2 o superior. Mientras tanto, aplica las mitigaciones temporales y limita al máximo la exposición del servidor.
¿Basta con desactivar session.upload_progress?
No. Ese ajuste solo reduce el riesgo de CVE-2026-109619 y no toca CVE-2026-109618. Sirve para ganar tiempo hasta poder actualizar, pero el equipo de PHP deja claro que ninguna mitigación por configuración deja el sistema a salvo.
¿Una web estática es vulnerable a PHP2Shell?
Si el servidor solo entrega archivos HTML, CSS e imágenes y no ejecuta PHP para atender las visitas, PHP2Shell no tiene por dónde entrar. Conviene confirmar, eso sí, que en ese mismo servidor no haya otras aplicaciones PHP expuestas.
Fuentes
Este artículo recoge lo publicado hasta el 23 de octubre de 2026. Lo actualizaremos si cambia el estado de la explotación o salen nuevas versiones.