PHP2Shell: los dos fallos de PHP que hay que parchear hoy

Esta mañana circulaba por las redes un mensaje con todos los ingredientes del pánico: «¡Vulnerabilidad crítica histórica de PHP!», parche urgente a las 16:00, ejecución de código remoto «en cualquier servidor», afecta «de PHP 5 hasta la 8» y ya hay un exploit dando vueltas. Debajo, la captura del aviso que la PHP Foundation había publicado ayer, mucho más sobrio: versión de seguridad el miércoles 21 de octubre a las 14:00 UTC, dos vulnerabilidades críticas, las dos con un 9,2 en CVSS v4.

Las 14:00 UTC son las 16:00 en la España peninsular, así que la hora estaba bien. Y esta tarde ha salido lo prometido: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. El aviso oficial de php.net no se anda con rodeos: corrigen «dos vulnerabilidades críticas que pueden permitir la ejecución remota de código sin autenticación», y «todos los usuarios de PHP» deben actualizar «inmediatamente».

Ilustración generada con IA para este artículo; no representa ningún servidor ni sistema real.

Esto sí es de los que hay que atender hoy. Pero el mensaje que ha corrido por las redes mezcla cosas ciertas con cosas exageradas, y para decidir qué hacer conviene separarlas.

Qué ha pasado, en orden

El embargo existía para que el parche y la explicación salieran a la vez, y que quien administra un servidor tuviera la solución en la mano el mismo minuto en que los atacantes tenían el mapa. La filtración se lo saltó, y por eso PHP ya había avisado de que adelantaría la publicación «si los detalles se hacen públicos o hay indicios de explotación activa».

Qué es, sin jerga

Los dos fallos tienen nombre oficial, CVE-2026-109618 y CVE-2026-109619, y los dos tienen que ver con lo que hace PHP cuando una petición se interrumpe a medias.

El ejemplo más claro es la memoria. Cada script de PHP tiene un tope, el famoso memory_limit, y cuando una petición lo supera PHP no termina con orden: aborta de golpe lo que estaba haciendo y salta al final. Si ese salto le pilla preparando la petición, hay estructuras internas que se quedan a medio construir. Ese es el primer fallo.

El segundo va un paso más allá. PHP guarda cierto estado interno que debería vivir lo que dura una petición, y que en algunos casos sobrevive a ella y sigue apuntando a memoria que ya se ha liberado. No hace falta quedarse sin memoria para llegar ahí: el aviso habla también de otros errores fatales, de tiempos agotados e incluso de avisos de diagnóstico que no detienen nada. Y como el mismo proceso de PHP atiende después otras peticiones, esa basura puede acabar usándose como si fuera buena.

En resumen: PHP gestiona mal su memoria y su estado interno cuando una petición se corta a medias, y con la petición adecuada un atacante puede aprovechar ese desorden para ejecutar sus propias órdenes en el servidor.

Lo que lo hace grave es que no depende de tu código. El fallo está en el motor, no en lo que corre encima, y no hace falta usuario ni contraseña. En el caso más claro, el que está demostrado con Apache y mod_php, basta un formulario con archivos adjuntos de los de toda la vida (multipart/form-data) preparado para agotar la memoria, y el ataque se produce antes de que la aplicación ejecute una sola línea: no hace falta un plugin vulnerable ni que tu web tenga un formulario de subida. En otras configuraciones el camino es distinto y puede depender de lo que haga la aplicación, pero el aviso no deja fuera ninguna: incluye PHP-FPM, mod_php, php-cgi, FrankenPHP y LiteSpeed.

Hay un detalle histórico que tiene su gracia. Calif empieza su cronología en 2004, con un fallo muy parecido —ejecución remota a partir del límite de memoria— que encontró entonces Stefan Esser. Veintidós años después, la misma esquina del motor. Y esta vez quien la ha vuelto a mirar no ha ido solo: tanto Calif como Wiz cuentan que buena parte del trabajo de búsqueda y de construcción del exploit lo hicieron con modelos de IA. Los créditos del aviso de PHP incluyen además a investigadores de OpenAI.

Lo que decía el mensaje y lo que hay

Así que el mensaje exageraba en la forma y acertaba en lo que importa: hay que actualizar, y hoy.

Qué tienes que comprobar

Primero, qué PHP sirve tu web. En WordPress está en Herramientas → Salud del sitio → Información → Servidor. En un panel tipo Plesk o cPanel, en la configuración de PHP de cada dominio. En un servidor propio, php -v en la consola. Ojo: el PHP de la consola y el que sirve la web pueden no ser el mismo, sobre todo en servidores con varias versiones instaladas; si dudas, mira el de la web con un phpinfo() temporal, y bórralo después.

Segundo, a quién le toca actualizarlo. Esta es la pregunta que más webs deja sin parchear, porque cada uno cree que es cosa del otro:

Y reiniciar PHP. Instalar el paquete no cambia nada mientras sigan vivos los procesos antiguos: hay que reiniciar PHP-FPM o Apache.

Si hoy no puedes actualizar

Hay medidas de contención, pero el aviso de PHP es tajante: «No hay mitigaciones completas; actualizar es la única opción segura». Lo que sigue es para ganar unas horas, no para quedarse así, y son cambios de configuración del servidor: si no administras tú el servidor, no son para ti, y lo que toca es la pregunta al proveedor de la tabla anterior.

• session.upload_progress.enabled = 0, puesto en php.ini, en el pool de FPM o en la configuración del servidor, porque tiene que aplicarse antes de que PHP lea la petición. No vale hacerlo con ini_set() desde la aplicación, ni en un .user.ini.
• memory_limit = -1, solo si controlas los límites que hay por fuera. Quitar el tope de PHP significa que una petición puede comerse toda la memoria, así que el aviso lo acompaña de un post_max_size bajo —8M si no subes archivos, 32M si sí—, de un límite de memoria en el contenedor o mediante cgroups —no con RLIMIT_AS ni RLIMIT_DATA, que según el aviso pueden provocar justo el fallo de asignación vulnerable—, y de fijarlo de forma que la aplicación no pueda cambiarlo (php_admin_value). Sin eso, cambias un problema por otro.
• En PHP 8.5, además, fatal_error_backtraces = 0.
• Si la web está detrás de Cloudflare, ya ha desplegado reglas en su cortafuegos, también en el plan gratuito. Eso reduce la exposición, y solo si el servidor no acepta tráfico que no venga de Cloudflare, pero no sustituye al parche.

Después de cambiar la configuración, otra vez: reiniciar PHP, y comprobar con phpinfo() que los valores nuevos son los que se están aplicando.

Si tu PHP es 8.1 o anterior

Aquí está la parte incómoda. PHP 8.1 y anteriores no reciben versiones nuevas del proyecto PHP. El proyecto ha publicado los arreglos adaptados a las ramas 7.4, 8.0 y 8.1 como código fuente, pero eso no es una actualización que se instale con un clic: es material para quien compila su propio PHP y para los proveedores que siguen manteniendo esas ramas. Algunos ya lo han aplicado; Ubuntu 22.04, por ejemplo, tiene corregido su PHP 8.1 en el paquete 8.1.2-1ubuntu2.28.

Así que la pregunta, si estás ahí, es si tu proveedor o tu distribución sigue manteniendo esa rama. Si la respuesta es sí, actualiza su paquete y listo por hoy. Si no lo sabes, confírmalo con tu proveedor. Y si nadie mantiene esa rama, tu web lleva tiempo sin parches de seguridad y hoy simplemente se ha notado: necesitas planificar la actualización. Subir de versión a veces arrastra cambios en la aplicación, en los plugins o en el tema. Mientras tanto, la contención de arriba y, si la web no puede esperar, sacarla de internet.

Ojo también a PHP 8.2: hoy ha recibido el parche, pero el proyecto deja de darle soporte el 31 de diciembre de 2026. Dentro de diez semanas estará en la misma situación que la 8.1.

Esto es justo de lo que hablaba en «No necesito mantenimiento web»: una web no se estropea un día concreto, se va quedando atrás, y un día como hoy esa deuda se cobra entera.

En casa

Lo primero que he hecho al leer el aviso ha sido mirar lo mío. Esta web está escrita en PHP, y el contenedor en el que la desarrollo llevaba PHP 8.3.35, construido el 25 de septiembre, con session.upload_progress.enabled activado, que es el valor por defecto. Vulnerable, por tanto, aunque ese contenedor no esté expuesto a internet.

Si necesitas una mano

Si al leer esto no tienes claro qué versión de PHP sirve tu web, a quién le toca actualizarla o si la actualización va a romper algo, puedo ayudarte. Llevo más de veinte años desarrollando y manteniendo webs en PHP, WordPress incluido, y un día como hoy suele haber dos trabajos distintos:

• El del servidor. Comprobar qué versión sirve de verdad cada web, actualizar PHP —en el panel, en los paquetes de la distribución o en la imagen de Docker—, aplicar la contención si la actualización tiene que esperar y verificar después que todo sigue funcionando.
• El del código. Cuando la web está en PHP 7 o en un 8.0 o 8.1 sin mantenimiento, actualizar el servidor no basta: la aplicación tiene que funcionar en una versión actual. Revisar si aparecen incompatibilidades al subir, adaptar el desarrollo propio, los plugins o el tema, y dejarlo funcionando en una versión de PHP con soporte y parches de seguridad.

Puedes necesitar uno, el otro o los dos. Escríbeme contándome dónde está alojada tu web y qué versión de PHP crees que tiene (si no lo sabes, también vale) y te digo qué hay que hacer, lo hagas tú, tu proveedor o yo.