🌐 También en: English · Deutsch · Français
El 21 de octubre de 2026 el proyecto PHP publicó cuatro versiones a la vez – 8.5.12, 8.4.27, 8.3.36 y 8.2.35 – sin la charla habitual de «versión de corrección de errores». Dos vulnerabilidades críticas, CVSS 9.2 cada una, ejecución remota de código sin autenticación, y una frase que todo administrador debería leer dos veces: «There are no complete mitigations, updating is the only safe choice.»
Los fallos llevan mucho tiempo en PHP; lo interesante no es una línea de código mala, sino cómo PHP recoge detrás de sí. Aquí va la versión corta y friki.
🧨 Fallo 1: el paracaídas de memoria que se abre demasiado pronto
CVE-2026-109618. Cuando a una petición se le acaba la memoria, PHP no se retira con educación: salta directamente fuera con longjmp(). Si eso ocurre cuando los datos de la petición solo están inicializados a medias, la limpieza al final de la petición trata esas estructuras a medio construir como válidas y trabaja con basura. Con la basura adecuada, eso es ejecución de código como el usuario del servidor web.
Lo retorcido: se puede llegar a quedarse sin memoria sin salirse de los límites que PHP cree estar aplicando. Las subidas multipart sin una longitud utilizable esquivan post_max_size, las partes multipart pueden llevar cabeceras ilimitadas que cuestan mucha más memoria dentro de PHP que en la red, y los campos de fichero vacíos no cuentan para max_file_uploads. La corrección elimina por completo longjmp() ante falta de memoria.
👻 Fallo 2: el estado de la petición anterior persigue a la siguiente
CVE-2026-109619. Un worker de PHP atiende muchas peticiones seguidas. Parte del estado global – errores, sesiones, datos de extensiones – puede seguir apuntando a la memoria de la petición anterior después de liberarse. Si la siguiente petición lo toca antes de que PHP lo reinicie, aparece un use-after-free de manual. Desencadenantes confirmados: los backtraces de errores fatales, nuevos en PHP 8.5, y el progreso de subida de sesiones.
🎯 A quién afecta
- A todo lo que atiende peticiones web: PHP-FPM, Apache con
mod_php(exploit confirmado, el mayor riesgo), php-cgi, FrankenPHP, LiteSpeed. - En PHP-FPM se validó como RCE el camino del progreso de subida de sesiones; el camino de falta de memoria es «vulnerable según el análisis del código».
- Las ramas 8.2 a 8.5. PHP 8.1 y anteriores no reciben ninguna corrección: si aún lo usas, esta es tu señal. El propio PHP 8.2 llega al final de su vida el 31 de diciembre de 2026.
🩹 Parches de emergencia si de verdad no puedes actualizar hoy
session.upload_progress.enabled = 0(y dejarlo desactivado después si no lo usas), además defatal_error_backtraces = 0en PHP 8.5; reiniciar todos los workers.- Limitar el tamaño de las peticiones, las partes multipart y las cabeceras en el proxy inverso; bloquear multipart por completo donde la aplicación no necesite subidas.
- Un límite de memoria por contenedor o cgroup, no
RLIMIT_AS/RLIMIT_DATA, que activan justo el camino vulnerable. - Todo esto reduce el riesgo. Nada de esto cierra el agujero. Lo dicen los propios avisos.
🐳 La trampa de los contenedores – el precio de las capas
Los contenedores tienen una desventaja que un día como este deja dolorosamente a la vista. Una imagen oficial no se construye de una pieza; es una pila de capas, y cada capa es de otra persona: abajo una base Debian, encima la imagen oficial php, y encima la imagen wordpress o nextcloud. Una corrección de PHP tiene que subir por esa cadena, piso a piso:
- El proyecto PHP publica la versión (aquí: el 21 de octubre por la tarde, hora europea).
- Los mantenedores de la imagen oficial
phpactualizan sus ficheros de build, un revisor los fusiona y la granja de builds reconstruye cada variante – fpm, apache, cli, alpine, debian, para cada arquitectura. Eso ocurrió aproximadamente una hora después de la publicación. - Solo entonces se pueden reconstruir las imágenes
wordpressynextcloudsobre la nueva base, otra vez para cada etiqueta y cada arquitectura, con la misma etiqueta que antes. Ese paso llegó horas después, no minutos. - Y solo entonces mi ejecución de actualización puede descargar la imagen nueva y reiniciar los pods.
En un servidor clásico escribirías apt upgrade en cuanto tu distribución publicara el paquete; las distribuciones reciben los parches por adelantado y suelen publicarlos en pocas horas. Con contenedores no puedes actualizar PHP sin más dentro de la imagen: el contenedor está pensado para sustituirse, no para remendarse, y lo que cambias a mano desaparece en el siguiente reinicio. Esperas a quienes construyen las capas. Casi siempre eso es una ventaja: imágenes reproducibles y probadas, una actualización es un cambio de imagen, una vuelta atrás es la etiqueta anterior. En un día con una RCE crítica, es una sala de espera.
Dos consecuencias prácticas. Primera: la etiqueta no dice nada. wordpress:7.1.3-php8.4-fpm era la misma etiqueta antes y después de la corrección, así que comprueba la versión de PHP dentro de la imagen: docker exec … php -v o kubectl exec … -- php -r "echo PHP_VERSION;" debe mostrar 8.4.27 / 8.5.12 (o 8.3.36 / 8.2.35); después vuelve a descargar la imagen y reinicia el pod. Segunda: ten un plan para la espera. Para eso están los parches de emergencia de arriba.
🏠 ¿Y en mis propios servidores?
Sí, afectados, los tres. El blog ejecuta WordPress en la imagen oficial wordpress:…-php8.4-fpm, los dos servidores Nextcloud la imagen oficial nextcloud:…-fpm con PHP 8.5: PHP-FPM en todas partes, detrás de nginx. Y los dos caminos confirmados estaban abiertos: el progreso de subida de sesiones está activado por defecto, y en PHP 8.5 también los backtraces de errores fatales. El resto de la instalación pone más difícil un ataque – sin mod_php, límites de tamaño en el ingress, un límite de memoria en cada pod, SELinux alrededor de cada contenedor –, pero más difícil no es imposible, y nada de eso es una corrección.
La espera. El PHP corregido ya estaba publicado, las imágenes corregidas no (ver la trampa de los contenedores más arriba). Así que durante esas horas tomé el camino suave de la lista de parches de emergencia: session.upload_progress.enabled = Off en los tres servidores y, en los dos Nextcloud con PHP 8.5, además fatal_error_backtraces = Off. Eso cierra exactamente los dos caminos que los avisos confirmaron como explotables con PHP-FPM, y ninguna de las dos aplicaciones usa esas funciones: WordPress no usa el progreso de subida en absoluto y Nextcloud sube los ficheros grandes a trozos mediante JavaScript. Los sitios siguieron en línea. No es una corrección: el camino de la falta de memoria sigue teóricamente abierto hasta que corra el PHP corregido. Los dos ajustes siguen desactivados también después de la actualización: el aviso recomienda dejar el progreso de subida apagado donde no se necesita – una función que nadie usa no puede abrir el próximo agujero –, y los backtraces de errores fatales aportan poco aquí, porque Nextcloud escribe de todos modos sus errores con la traza de llamadas en su propio log.
Estado: todo limpio. La imagen reconstruida de WordPress con PHP 8.4.27 estuvo disponible a las 20:06 (hora de Europa central, 18:06 UTC), unas cuatro horas después de la publicación de PHP; la imagen reconstruida de Nextcloud con PHP 8.5.12 llegó a las 20:25 (18:25 UTC). El blog funciona con el PHP corregido desde las 20:26 y los dos servidores Nextcloud desde las 20:31 y las 20:36, comprobado dentro de cada contenedor, no mirando la etiqueta, junto con los dos ajustes de emergencia, que siguen desactivados. De la publicación al último servidor corregido: unas cuatro horas y media, casi todas esperando las imágenes. Ninguna huella de ataque en los logs, y las comprobaciones de integridad de WordPress (núcleo y todos los plugins) y de Nextcloud salieron limpias. Estoy a salvo. 🐘✅
⏱️ TL;DR
Dos RCE críticas sin autenticación en el propio PHP, todas las SAPI web, ningún apaño real. Actualiza ya a 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35: paquetes de la distribución, imágenes de contenedor, panel del hosting, lo que uses. Y si tu proveedor gestiona PHP por ti: pregúntale hoy si ya lo ha hecho. apt upgrade nunca fue tan literal. 🐘🔐
Sin garantía: este artículo describe lo que encontré e hice en mis propios servidores, según mi mejor conocimiento el día en que lo escribí. No asumo ninguna responsabilidad por tus sistemas, ni por la actualización ni por los parches de emergencia descritos aquí, que explícitamente no protegen por completo. La única corrección real es la versión parcheada de PHP; consulta los avisos oficiales para tu instalación.
Fuentes: aviso de seguridad de PHP del 21/10/2026, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp.
