PHP publica parches de emergencia para dos fallos de CVSS 9.2 que se activan con una sola petición

PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 llegaron el 21 de octubre de 2026 a las 13:30 UTC, un día después de que el proyecto anunciara una versión de seguridad no programada. Las compilaciones incluyen correcciones para dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, ambas con una puntuación de 9.2 según CVSS 4.0. Las dos permiten ejecución remota de código sin autenticación, y el código de prueba de concepto público empezó a circular en cuanto salió la versión.

Lectura relacionada: WordPress parchea Comment2Shell, un fallo en los comentarios que puede llevar a la toma de control del servidor · Check Point parchea dos fallos de VPN de severidad 9.8 que permiten ejecución de código sin autenticación.

La mayoría de los fallos que afectan a la web viven en el código de la aplicación. Estos dos viven en el intérprete. Un exploit demostrado necesita una sola petición de un cliente anónimo, y se dispara antes de que se ejecute una línea de WordPress o Drupal. Un plugin parcheado y una regla bien ajustada de cortafuegos de aplicación web quedan los dos por detrás del punto donde aterriza el ataque.

Dos formas de romper un worker

Los dos errores no tienen relación en su mecanismo y acaban en el mismo sitio.

CVE-2026-109618, registrado como GHSA-w8hw-w9fx-j79w, es una corrupción de memoria durante la gestión de la falta de memoria. PHP aplica memory_limit mediante longjmp(), que puede interrumpir una petición mientras los datos internos de esa petición solo están parcialmente inicializados. La subida de un archivo multipart es el ejemplo del aviso. La ruta de limpieza trata entonces datos inválidos como válidos y libera memoria que nunca se inicializó, memoria que aún puede contener bytes controlados por el atacante, restos de asignaciones anteriores. Resultado: una corrupción de memoria que un atacante puede dirigir hacia la ejecución de código.

CVE-2026-109619, GHSA-6wmf-4rv5-p3rp, es un estado global obsoleto. El estado interno de una petición puede sobrevivir después de que se haya liberado la memoria que lo sustentaba, con un error fatal citado como una de las vías. Una petición posterior atendida por el mismo worker puede leer ese estado obsoleto antes de que la inicialización normal lo sobrescriba. El worker no tiene por qué caerse.

Esa dependencia de la reutilización de workers explica por qué las recomendaciones de mitigación vuelven una y otra vez a los reinicios. Cambiar un ajuste en php.ini no llega a un worker que ya está funcionando con la configuración antigua, ni lo hace cambiar el binario por debajo. Hay que reciclar el pool para que cualquiera de los dos cambios surta efecto.

Ambos errores están valorados con 9.2 y ambos se notificaron al proyecto PHP antes del lanzamiento, por eso los paquetes de las distribuciones y los proveedores de soporte a largo plazo tenían parches listos el primer día. El equipo de PHP publicó además backports mínimos del código fuente para PHP 7.4, 8.0 y 8.1, un parche provisional para ramas que ya no reciben soporte oficial.

Qué configuraciones de servidor conllevan riesgo

Entra en el ámbito toda instalación de PHP que sirva peticiones web. El proyecto PHP enumera PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed, y sitúa mod_php como la configuración de mayor riesgo de las cinco. El aviso no venía acompañado de datos de explotación por configuración, así que la clasificación es una valoración del proveedor y no una tasa de explotación medida.

Lo que da peso a la clasificación es la base instalada. W3Techs, citada por The Verge, sitúa a PHP en el 69,3 por ciento de todos los sitios web en los que puede identificar el lenguaje del lado del servidor, un grupo que incluye Wikipedia y WordPress. El escáner de VirusTotal registra unos 3,8 millones de sitios con PHP y al menos un puerto abierto. La telemetría Cortex Xpanse de Unit 42 arrojó una cifra mayor: más de 22,6 millones de instancias expuestas potencialmente vulnerables.

Ninguna de las dos cifras cuenta hosts con explotación confirmada. «Potencialmente vulnerable» abarca toda dirección que ejecute una versión de PHP anterior a la corrección, incluidas instalaciones detrás de un proxy que bloquea la forma de petición relevante y alojamientos compartidos que quizá ya hayan parcheado el intérprete sin avisar a sus clientes.

The Verge citó 4chan, DeviantArt, Wikipedia y el blog de un bar local entre los sitios afectados. Kotaku informó de que Pokémon Home y Pokémon Champions quedaron fuera de línea. Algunas agencias gubernamentales neerlandesas y finlandesas retiraron sus sitios como precaución, y Unit 42 dijo que al menos un gobierno europeo había hecho lo mismo. El director de tecnología de Cloudflare, John Graham-Cumming, declaró a The Verge que la empresa estaba «viendo surgir los primeros ataques».

Un fallo de hace 20 años que la IA hizo práctico

Wiz Research, que descubrió y notificó las vulnerabilidades junto al proyecto PHP, afirma que el defecto subyacente llevaba unos 20 años en PHP.

Explotar el fallo «requería una cadena de pasos excepcionalmente compleja, en el límite de lo que los investigadores humanos podían lograr en la práctica». — Wiz Research

Un error puede permanecer dos décadas en una base de código sin convertirse en un incidente masivo mientras el coste de construir un exploit funcional siga por encima de lo que la mayoría de los atacantes está dispuesta a pagar. Wiz atribuye el cambio a los modelos de IA, que hicieron mucho más fácil convertir un defecto oscuro de gestión de memoria en una cadena funcional. Google, propietaria de Wiz, publicó su versión el 21 de octubre. OpenAI dijo por separado que un grupo de seguridad con IA llamado Calif identificó una falla crítica de PHP usando GPT-5.6 Sol.

Dos organizaciones que usan investigación asistida por IA llegaron al mismo defecto de nivel de intérprete, y el proyecto PHP y Wiz lo divulgaron juntos. Es un caso, y un caso no zanja cuánto inclina la IA la balanza entre atacantes y defensores.

Qué implica parchear más allá del número de versión

Para la mayoría de los sitios el trabajo es una actualización del intérprete más un reinicio, y el reinicio es donde el alojamiento compartido se complica. Los workers de PHP-FPM de larga vida siguen sirviendo con el binario antiguo hasta que se recicla cada uno. Los contenedores construidos sobre una imagen base antigua siguen vulnerables hasta que se reconstruye y se vuelve a desplegar la imagen. Un panel de control que informa de PHP 8.3 no demuestra que el pool ejecute la 8.3.36 corregida.

GoDaddy dice que cualquier sitio que use PHP debe dar por hecho que está afectado, y eso vale igual para instalaciones de WordPress, Drupal, Joomla y Magento, porque ninguna de esas plataformas incluye su propio intérprete. Actualizar un plugin o un tema cambia archivos dentro del directorio de la aplicación. No toca el binario que analiza la petición.

Dos huecos de soporte alargan la estela. PHP 8.1 y versiones anteriores están al final de su vida útil y no recibirán compilación oficial, así que quien siga en 8.0 o 7.4 necesita actualizar o aceptar un backport del proveedor. Y el repositorio remi, una fuente habitual de paquetes de PHP más recientes en sistemas derivados de Red Hat, no tendría actualizaciones el día del lanzamiento. El consejo del equipo de PHP era pasarse a los paquetes de la distribución o compilar desde el código fuente.

Qué hacer mientras el rebuild espera en la cola

El aviso 2026-018 de CERT-EU expone la prioridad sin rodeos: «CERT-EU recomienda a las organizaciones parchear de inmediato los activos afectados». Si parchear no es viable, indica que se aíslen las aplicaciones expuestas a internet de las redes públicas hasta que se aplique y verifique una corrección. La cuenta de ciberseguridad de la NSA en X y el NCSC británico dieron consejos similares: sacar los sistemas de línea si no es posible una actualización inmediata.

Para las organizaciones que no pueden ir tan rápido, CERT-EU enumera medidas temporales. Reducen la exposición sin cerrar el agujero.

• Para CVE-2026-109618: fijar memory_limit=-1 de forma que las aplicaciones no puedan sobrescribirlo, por ejemplo con php_admin_value en el pool de FPM o en la configuración de Apache. Bajar post_max_size a 8M sin subidas y a 32M con ellas. Aplicar límites de tamaño de petición, de campos y de partes en el proxy, y usar un límite de memoria de contenedor o cgroup.
• Para CVE-2026-109619: fijar session.upload_progress.enabled=0 y reiniciar todos los workers. En PHP 8.5, fijar fatal_error_backtraces=0 y reiniciar. Eliminar ajustes inválidos por petición que emiten diagnósticos antes de la inicialización y corregir los errores fatales y tiempos de espera accesibles desde fuera.
• Para ambos: parchear y después reiniciar. Un binario actualizado en disco con workers que siguen ejecutando el antiguo no es una corrección.

Qué no demuestran las cifras

Las cifras de 22,6 millones y 3,8 millones son estimaciones de exposición extraídas de telemetría de proveedores y de una encuesta. Ninguna cuenta hosts que ejecuten código al que un atacante pueda llegar.

No todos los sitios con PHP son explotables con la misma técnica. Los errores viven en subsistemas distintos, y la forma de petición que activa uno puede no funcionar contra una SAPI concreta o un conjunto de opciones concreto.

En el momento de escribir esto no se había publicado ninguna compromisión masiva confirmada ni atribución a un atacante. Los informes sobre sitios que quedan fuera de línea describen tanto medidas de precaución como incidentes, y las dos cosas son fáciles de confundir en esta fase. La ausencia de una compromisión masiva publicada no prueba que no haya ocurrido, solo que el 21 de octubre no se había hecho público ningún hallazgo de ese tipo.

Qué vigilar

La primera señal es si el código de prueba de concepto se convierte en un exploit listo para usar. Una cadena funcional en manos públicas reduce la habilidad necesaria para usarla, y la base instalada de PHP ofrece a quien escanee un conjunto de objetivos inusualmente grande. Unit 42 dijo que ya circulaba un primer código de prueba de concepto y que la explotación era probable.

La segunda es la larga estela del final de vida útil. PHP 8.1 dejó de recibir correcciones oficiales, y 7.4 y 8.0 están más atrás. Cada sitio que sigue en esas ramas depende de que un mantenedor de la distribución o una empresa de alojamiento haga un backport de una corrección de corrupción de memoria, y que llegue o no depende del proveedor.

Luego está el lado de la investigación. Si el trabajo asistido por IA sigue produciendo errores a nivel de intérprete a este ritmo, la brecha entre que un proyecto publique una corrección y que la larga estela de servidores sin parchear la aplique se convierte en la cifra que importa, no la puntuación CVSS.

Por ahora la secuencia es corta. Parchear el intérprete, reiniciar cada worker, confirmar la versión en ejecución y tratar las estimaciones de exposición como un motivo para darse prisa, no como una medición. Los sitios que no puedan hacerlo hoy deberían salir de la internet pública, que es lo que ya eligieron varios operadores.

Imagen de portada: «Custom-software-developement-php-net» de Ron23545, CC BY-SA 4.0, vía Wikimedia Commons.