Alerta PHP urgente: el verdadero peligro es el 59% en versiones
Dos fallos críticos RCE han desencadenado una alerta de emergencia, pero el riesgo real está en el 59 % de las instalaciones PHP con soporte finalizado que nunca recibirán parche.
La filtración que quebró el embargo
El 20 de octubre, una publicación en Hacker News afirmaba que se revelarían dos fallas de ejecución remota de código (RCE) en PHP, calificadas con CVSS 10.0, al jueves siguiente. El autor no ofrecía otra prueba más que «fuente: confía, hermano». Esa misma noche, PHP publicó su propio aviso, adelantando el lanzamiento un día y rebajando la puntuación oficial a 9.2 en la escala CVSS v4.0. watchTowr confirmó que la información filtrada era real y que el embargo ya había sido quebrado.
El patrón resulta familiar e irritante. Los investigadores descubren una falla crítica. Los fabricantes preparan un anuncio coordinado. Alguien filtra los detalles. El reloj se acelera. Lo que importa ahora no es el espectáculo, sino el panorama que la filtración puso al descubierto: dos vulnerabilidades RCE en PHP sin parche, con puntuación CVSS superior a 9.0, sin solución alternativa conocida y con explotación activa aún no reportada —pero que difícilmente permanecerá ausente por mucho tiempo.
Quiénes reciben parche y quiénes no
PHP incluirá un lanzamiento de seguridad fuera de ciclo para sus cuatro ramas soportadas: 8.2, 8.3, 8.4 y 8.5. Ahí va el parche. Todo lo demás queda en manos de cada cual.
Las versiones 8.1, 8.0, 7.x y 5.x están en fin de vida. No reciben arreglo alguno de PHP. Si las vulnerabilidades llegan a esas ramas —y el FAQ de watchTowr señala que el alcance aún no ha sido confirmado oficialmente—, las instalaciones sobre ellas permanecerán expuestas de forma indefinida.
Este no es un vacío hipotético. La empresa de seguridad Mallory contabilizó aproximadamente 884.000 hosts visibles en internet cuyo banner HTTP reportaba una versión de PHP 8.1 o anterior a Shodan el 20 de octubre. Esto representa el 59 % de los aproximadamente 1,5 millones de hosts que reportaron cualquier versión de PHP. Otros 740.000 hosts mostraban PHP sin cadena de versión. Se trata de banners, no de sistemas afectados confirmados, pero pintan un cuadro claro: la mayoría de las instalaciones de PHP visibles ejecutan ramas que nunca recibirán un parche del fabricante.
El ecosistema WordPress es la superficie de exposición más evidente. Millones de sitios WordPress ejecutan PHP como backend, y una proporción significativa de esos sitios no ha migrado a una versión de PHP soportada. Para esos operadores, la alerta de emergencia no es un llamado a parchear. Es un llamado a decidir si aíslan, migran o aceptan el riesgo.
Por qué esto trasciende el ecosistema PHP
En los círculos de ciberseguridad, PHP suele tratarse como una tecnología heredada. Esa suposición es precisamente lo que hace peligrosa esta alerta. La infraestructura crítica, los portales gubernamentales y las aplicaciones de pequeñas empresas siguen ejecutando versiones antiguas de PHP porque la migración es costosa, la documentación es escasa y el incentivo para actualizar es bajo hasta que algo se rompe.
Los CVE en cuestión —CVE-2026-109618 y CVE-2026-109619, identificadores que ya aparecían en el mensaje filtrado— no son arbitrarios. Una falla RCE de CVSS 9.2 en un lenguaje que sostiene una fracción importante de la web constituye un evento de alto impacto. El hecho de que PHP aún no haya descrito los detalles técnicos es a la vez una protección y una desventaja: frena a los atacantes, pero también deja a los defensores operando a ciegas mientras se preparan.
El cronograma de explotación es el verdadero riesgo
Huntress reportó que, al 20 de octubre, no había explotación de estas fallas en sus entornos de socios. El FAQ de watchTowr listaba, al 21 de octubre, ningún reporte de explotación. Las fallas aún no aparecen en el catálogo de Vulnerabilidades Explotadas Conocidas de CISA.
Pero la historia habla en contra de la complacencia. Cuando el CVE-2024-4577, una vulnerabilidad del modo CGI de PHP en Windows, se hizo pública en junio de 2024, Akamai vio intentos de explotación contra sus servidores honeypot en menos de 24 horas. No hay razón para creer que un RCE en PHP de CVSS 9.2 sea tratado con más delicadeza por los actores de amenaza.
La ventana entre la divulgación pública y la explotación generalizada es el momento que castiga a las organizaciones que no se prepararon. Aplicar parches es lento en entornos complejos. Las verificaciones de dependencias toman tiempo. Los reversiones conllevan riesgos. Cada hora de demora es una hora en la que la brecha entre la capacidad del atacante y la preparación del defensor se amplía.
Cómo se ve la defensa en este momento
PHP no ha publicado ninguna solución alternativa. Hasta que llegue el lanzamiento, la orientación es operativa, no técnica. Huntress y el CERT-EU han convergido en un conjunto práctico de pasos.
Primero, inventoría cada instalación de PHP. Esto incluye PHP empaquetado en appliances de proveedores, software para Windows y paneles de control como cPanel y Plesk. Muchas organizaciones administran PHP sin saberlo. La actualización relámpago dentro de una aplicación propietaria o el intérprete incrustado en un appliance de hardware pasan fácilmente desapercibidos y son difíciles de parchear.
Segundo, prepárate para actualizar en el momento del lanzamiento. Prioriza los sistemas visibles desde internet. Revisa los repositorios de distribuciones Linux y de proveedores de hosting en busca de paquetes retrotraídos, que pueden llegar antes que el lanzamiento oficial de PHP.
Tercero, para las ramas en fin de vida, las opciones son actualizar, aislar o restringir. El CERT-EU recomienda aislar las aplicaciones visibles desde internet de las redes públicas hasta que esté disponible una solución. Una VPN o un firewall de aplicaciones web puede ganar tiempo. Ninguno es una solución permanente, pero ambos reducen la superficie de ataque mientras los operadores planifican la migración.
Cuarto, monitorea el comportamiento de los procesos PHP. En servidores Linux sin detección en endpoint, el process watcher de Florian Roth registra cada programa que inicia un proceso PHP, junto con su línea de comandos. No previene la ejecución. La registra. Las señales a vigilar son php-fpm, php-cgi, httpd o apache2 lanzando shells, intérpretes o herramientas de descarga.
Quinto, si encuentras algo, aísla el servidor de inmediato. Conserva los registros del servidor web y de PHP. Busca web shells, archivos nuevos en la raíz web, nuevas tareas cron, tareas programadas y cuentas inesperadas. El abuso de RCE deja rastros. La velocidad de la respuesta determina si esos rastros respaldan elContainment o se convierten en evidencia de pérdida.
Qué aclarará el lanzamiento
El próximo lanzamiento de PHP debería responder las preguntas que el aviso dejó sobre la mesa: qué versiones están afectadas, qué componente de PHP está involucrado, si la falla requiere un modo de ejecución, configuración o inicio de sesión particulares, y cómo describe PHP mismas las vulnerabilidades.
Hasta entonces, el boletín es direccional, no específico. Eso es estándar en investigaciones bajo embargo. También es el punto en el que el costo de la inacción se vuelve visible. Las organizaciones en ramas soportadas pueden prepararse para un parche. Las organizaciones en ramas en fin de vida deben prepararse para el aislamiento, la migración o la aceptación del riesgo. El 59 % no es una estadística. Es una cuenta regresiva.
La alerta de emergencia es real. El lanzamiento cerrará la brecha técnica para las versiones soportadas. La brecha estructural —las instalaciones que nunca recibirán parche— persistirá cuando se apague el ruido de la nota de prensa. Ese es el problema más profundo, y el que esta alerta debería obligar a las organizaciones a enfrentar.