PHP2Shell: dos fallos críticos de PHP que obligan a actualizar hoy

El proyecto PHP ha publicado hoy, 21 de octubre de 2026, PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Corrigen dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, con una nota de 9,2 sobre 10 cada una, que permiten ejecutar código en el servidor sin estar identificado. El aviso oficial pide a todos los usuarios de PHP que actualicen de inmediato y deja claro que no hay ningún ajuste que proteja del todo: actualizar es la única opción segura.

Los investigadores que las encontraron, Calif y Wiz Research, las han bautizado PHP2Shell. Los detalles se filtraron un día antes de lo previsto y, según recoge BleepingComputer, Cloudflare dice que ya está viendo los primeros ataques. Es de los avisos que hay que atender hoy, no la semana que viene.

Por qué esta vez no basta con tener la web al día

Casi todos los avisos de seguridad que vemos en una web de empresa son de un plugin, de un tema o del propio WordPress, y se arreglan actualizando la web. Este no. El fallo está en PHP, el lenguaje que ejecuta la web en el servidor, y en concreto en cómo gestiona la memoria y su estado interno cuando una petición se interrumpe a medias, por ejemplo al quedarse sin memoria. Con una petición bien preparada, un atacante aprovecha ese desorden para ejecutar sus propias órdenes.

Tres consecuencias para una empresa:

• Da igual que WordPress, los plugins y el tema estén actualizados. Wiz y Calif han demostrado el ataque, sin usuario, contra instalaciones de WordPress y Drupal recién instaladas.
• No hace falta que la web tenga un formulario de subida de archivos ni ningún fallo propio. En la configuración donde está demostrado de principio a fin (Apache con mod_php), el ataque ocurre antes de que la web ejecute una sola línea.
• Afecta a todas las formas de servir PHP: PHP-FPM (lo habitual con nginx y en la mayoría de alojamientos), mod_php, php-cgi, FrankenPHP y LiteSpeed.

En las redes ha circulado estos días que es «histórica» y que afecta «de PHP 5 a PHP 8». Con matices, no va desencaminado: el camino vulnerable más antiguo que han encontrado los investigadores es de PHP 5.4, de 2012. La nota oficial es 9,2, no el 10 que corría antes del parche, pero eso no cambia lo que hay que hacer.

Qué tiene que comprobar una empresa

La versión de PHP que sirve la web. En WordPress se ve en Herramientas → Salud del sitio → Información → Servidor; en Plesk o cPanel, en la configuración de PHP de cada dominio. Tiene que ser 8.2.35, 8.3.36, 8.4.27, 8.5.12 o posterior. Si el servidor usa los paquetes de una distribución Linux, el número será otro, porque Ubuntu, Debian o Red Hat aplican el parche sobre su propia versión, sin adoptar necesariamente la numeración de php.net: ahí manda el aviso de seguridad de la distribución.

A quién le toca actualizar. Es la pregunta que más webs deja sin parchear, porque cada uno cree que es cosa del otro:

• Hosting compartido o gestionado: al proveedor. Conviene preguntarle hoy, por escrito, cuándo aplica el parche.
• Servidor propio o VPS, con o sin Plesk o cPanel: a quien lo administre. Y después de instalar hay que reiniciar PHP, porque los procesos que ya estaban en marcha siguen con el PHP viejo.
• Contenedores Docker: a quien mantenga la imagen. Una imagen construida la semana pasada lleva el PHP de la semana pasada.

Si el servidor no se puede actualizar hoy, el aviso de PHP da una lista de ajustes que reducen la exposición mientras tanto (desactivar session.upload_progress.enabled, entre otros). Son cambios de configuración del servidor, para quien lo administra, y PHP insiste en que no sustituyen al parche. Si la web está detrás de Cloudflare, sus reglas de cortafuegos ayudan, también en el plan gratuito, pero tampoco son la solución.

Si tu web sigue en PHP 8.1 o anterior

Aquí está el problema de fondo. PHP 8.1 y anteriores ya no reciben versiones nuevas del proyecto PHP. Esta vez el equipo de seguridad ha dejado el arreglo para 7.4, 8.0 y 8.1 como código fuente, para quien compila su propio PHP y para los proveedores que siguen dando soporte a esas versiones. Algunas distribuciones ya lo han aplicado (Ubuntu 22.04, por ejemplo, en su PHP 8.1), pero no se puede dar por hecho: hay que confirmar con el proveedor si mantiene esa rama y ha aplicado la corrección.

Y no es solo la 8.1: el proyecto PHP deja de dar soporte a PHP 8.2 el 31 de diciembre de 2026. Una web en 8.2 recibe hoy el parche, pero dentro de diez semanas estará en la misma situación.

Muchas webs siguen en versiones antiguas no por descuido, sino porque subir de versión puede provocar incompatibilidades: un plugin abandonado, un tema hecho a medida hace años o una aplicación interna que usa funciones que PHP ya ha retirado. Por eso se va aplazando, hasta que un día como hoy esa actualización pendiente se convierte en una urgencia. El parche resuelve la urgencia; si la rama ya no tiene mantenimiento, también hay que planificar la migración: adaptar la web a una versión con soporte y dejarla preparada para la siguiente.

Lo que estamos haciendo nosotros

Trabajamos con PHP todos los días: esta misma web, las aplicaciones a medida que desarrollamos y las webs en WordPress que mantenemos funcionan sobre PHP. Desde que se ha publicado el aviso estamos actualizando los servidores y las webs que llevamos, reiniciando PHP y comprobando después, una por una, que cada web sirve ya la versión corregida y sigue funcionando.

Si tu empresa tiene una web en PHP y no sabe en qué situación está, podemos ayudarte en todo el proceso:

• Diagnóstico: qué versión de PHP sirve de verdad cada web, dónde está alojada y a quién le toca actualizarla.
• Actualización: aplicar el parche o, si tiene que esperar, la contención, y verificar que la web sigue funcionando.
• Adaptación a una versión nueva de PHP: para las webs que se han quedado en 8.1 o anteriores, o en la 8.2 que caduca en diciembre. Revisamos el código, el tema y los plugins, corregimos lo que la versión nueva no admite y hacemos el cambio con pruebas y vuelta atrás preparada.

Para webs en WordPress, ofrecemos soporte técnico de WordPress. Para otras webs o aplicaciones en PHP, contacta con nosotros.

Esteban lo cuenta con más detalle técnico en su blog: PHP2Shell: los dos fallos de PHP que hay que parchear hoy.