Dos fallos críticos de PHP con CVSS 9,2 se filtraron un día antes del parche y ya circulan exploits

El proyecto PHP ha publicado parches para dos fallos que permiten a un atacante sin autenticar ejecutar código en un servidor. La filtración de los identificadores CVE y un vídeo publicado por error dieron ventaja a los atacantes, y ahora los administradores compiten contra exploits que ya funcionan.

Los parches salieron un día antes porque se filtraron los CVE

El 21 de octubre el proyecto PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Corrigen dos fallos críticos con una puntuación CVSS v4.0 de 9,2. El primero (CVE-2026-109618) aparece cuando una petición alcanza memory_limit en el momento menos oportuno. PHP trata entonces datos a medio inicializar como válidos y corrompe la memoria. El segundo (CVE-2026-109619) deja, tras un error fatal, una referencia a memoria que una petición anterior ya había liberado.

Los parches debían salir el 22 de octubre a las 14:00 UTC. Un día antes, hacia las 15:00 UTC, ambos identificadores CVE aparecieron en foros y redes sociales, además con una puntuación errónea de 10,0. Según la PHP Foundation, no se filtraron detalles técnicos. El proyecto adelantó la publicación un día. Esa noche la empresa de seguridad Calif publicó por error un vídeo en el que su proof of concept funcionaba contra varios objetivos. Lo borró, pero las copias siguieron circulando y, según la fundación, aceleraron la aparición de nuevos exploits.

Lo peor lo tiene Apache con mod_php. Ahí basta una petición sin autenticar que lanza el ataque antes de que se ejecute el código de la aplicación, y con la configuración por defecto. Pero están afectadas todas las instalaciones que sirven peticiones web, incluidas PHP-FPM, php-cgi, FrankenPHP y LiteSpeed. Wiz Research, una de las empresas que reportaron los fallos, demostró ataques sin autenticación contra WordPress, Drupal y Joomla. Según Wiz, todas las versiones de PHP desde la 5.4 están afectadas. La misma empresa afirma que PHP mueve el 70 % de las webs.

El fallo llevaba dos años en PHP hasta que los modelos frontier lo abrieron

Lo más interesante es la cronología. Un desarrollador pagado por la PHP Foundation encontró las primeras señales del problema de memoria ya en 2024. Fue durante una auditoría externa financiada por la Sovereign Tech Agency y realizada por Quarkslab. Entonces nadie conocía una vía hacia la ejecución de código. El equipo barajó varias correcciones y cada una rompía algo: la compatibilidad, el rendimiento o las extensiones de terceros. La propia fundación califica el retraso de fallo estructural de un equipo pequeño que decidía por consenso.

El punto de inflexión llegó en agosto de 2026. El 11 de agosto Calif reportó una ejecución de código sin condiciones con la misma causa raíz. Wiz y OpenAI añadieron otras vías de ataque. Wiz afirma que encontró el primer fallo con su herramienta Wiz Atlas y los modelos Gemini 4 Argon y GPT-5.6 Sol. Según la empresa, el exploit exige encadenar varios fallos y ajustarlos a la disposición de memoria de cada objetivo. Los modelos frontier redujeron ese trabajo a horas.

Aquí está la segunda lectura. La complejidad del exploit funcionó durante años como una protección silenciosa: el fallo se conocía, pero nadie tenía tiempo para rematarlo. Si un modelo puede hacer ese trabajo, un fallo teórico ya no espera años. Los administradores tienen menos margen entre el aviso y el ataque, y los proyectos open source cargan con más trabajo y poca gente. Desde el 1 de julio el equipo de PHP ha publicado 15 CVE y ha revisado más de 100 informes que resultaron inválidos, duplicados o imposibles de reproducir.

Ninguna configuración protege del todo el servidor

El proyecto PHP describe medidas temporales, como desactivar session.upload_progress o cambiar el manejo de memory_limit. Pero admite que ninguna de ellas hace segura una instalación. Solo la actualización protege por completo. Las versiones anteriores a la 8.2 no recibirán parche del proyecto. Quien las use depende de backports de su distribución o de un proveedor de soporte a largo plazo. El repositorio de paquetes mantenido por voluntarios, del que dependen muchos servidores, no tenía actualización el día de la publicación.

Para las webs europeas la pregunta clave es para el proveedor de hosting. En un hosting compartido el cliente a menudo no puede cambiar la versión de PHP, así que el riesgo depende de la rapidez del proveedor. Los contenedores e imágenes propios no se arreglan solos. Hay que reconstruirlos y reiniciar todos los workers.

La rapidez de los hostings dirá cuántas webs siguen expuestas

La primera señal vendrá de hostings y distribuciones. Las distribuciones Linux y los proveedores LTS recibieron los parches por adelantado, así que deberían tener paquetes de inmediato. Las webs de proveedores lentos serán las primeras de la cola para atacantes que ya tienen un exploit funcional.

La segunda señal es a largo plazo. La PHP Foundation pide a las empresas que dependen de PHP que ayuden a financiar su trabajo de seguridad. Si la IA sigue acelerando tanto la búsqueda de fallos como su explotación, el dinero para mantenimiento se convierte en una cuestión de seguridad operativa. Además, la versión 8.2 deja de tener soporte el 31 de diciembre de 2026, así que el próximo parche de este tipo ya no le llegará.

El veredicto de Lilith

Un fallo de 2024 pasó dos años en las notas de un equipo pequeño hasta que los modelos frontier lo convirtieron en exploit. Después bastó un vídeo publicado por error para que los atacantes salieran la misma noche que los administradores de servidores.