El equipo de seguridad de PHP ha anunciado dos vulnerabilidades críticas con una puntuación CVSS v4.0 de 9.2 y ha programado un lanzamiento de seguridad extraordinario para el 21 de octubre de 2026 a las 14:00 UTC. Según los investigadores de watchTowr, ambas vulnerabilidades permiten ejecución remota de código (RCE). Solo cuatro ramas soportadas, de la 8.2 a la 8.5, recibirán parches. Según los cálculos de la empresa Mallory, alrededor de 884 000 hosts accesibles por Internet ejecutan versiones obsoletas de PHP y no recibirán correcciones del proveedor. En el momento de la publicación no se ha observado explotación in the wild, pero el historial de vulnerabilidades similares en PHP muestra que los ataques pueden comenzar en un plazo de 24 horas tras la divulgación de los detalles.
Qué se sabe sobre las vulnerabilidades
El aviso oficial de PHP confirma la existencia de dos vulnerabilidades críticas, pero no revela detalles técnicos, versiones afectadas ni siquiera identificadores CVE. Está previsto que la información completa se publique junto con el lanzamiento. Los identificadores CVE-2026-109618 y CVE-2026-109619 aparecen en publicaciones de investigadores y en una filtración en Hacker News, pero PHP no los menciona en su aviso.
Es importante separar aquí los hechos confirmados de las afirmaciones no verificadas. Oficialmente se ha establecido lo siguiente:
- Ambas vulnerabilidades han sido valoradas por el equipo de seguridad de PHP con CVSS v4.0 9.2 (Critical)
- Se publicarán parches para las ramas PHP 8.2, 8.3, 8.4 y 8.5
- Los detalles técnicos, incluido el componente vulnerable y el vector de ataque, aún no se han revelado
En la filtración en Hacker News del 20 de octubre aparecía una puntuación CVSS de 10.0 y la afirmación de que las vulnerabilidades afectan a todas las versiones desde PHP 5. Sin embargo, la puntuación 10.0 procede de una filtración no verificada y no de una valoración oficial del proveedor. Como señala watchTowr en su FAQ, el alcance declarado de «a partir de PHP 5» no está confirmado por el aviso oficial del proveedor, del mismo modo que tampoco se han establecido aún las causas técnicas de las vulnerabilidades ni los requisitos de configuración para su explotación.
Matriz de versiones afectadas y alcance del problema
Sobre la base de los datos disponibles, la situación se presenta de la siguiente manera:
- Ramas 8.2–8.5: están soportadas y recibirán parches. Según Mallory, las versiones corregidas serán: 8.2.35, 8.3.36, 8.4.27 y 8.5.12 (estos números de versión los indica Mallory, no el aviso oficial de PHP)
- PHP 8.1 y anteriores: ramas que han alcanzado el final de su ciclo de vida (end of life), no recibirán parche del proveedor
- PHP 5 y posteriores: intervalo de versiones afectadas no confirmado y procedente de la filtración
Es precisamente este último punto el que genera la mayor incertidumbre. Si las vulnerabilidades afectan realmente a versiones hasta PHP 5, la magnitud del problema aumenta de forma considerable. Según los cálculos de Mallory, de aproximadamente 1,5 millones de hosts accesibles por Internet que informan de la versión de PHP a través de banners HTTP en Shodan, 883 717 (59%) ejecutan ramas que no recibirán correcciones. Otros 740 000 hosts indican la presencia de PHP sin especificar la versión. Estas cifras reflejan banners, no sistemas confirmadamente vulnerables ni organizaciones únicas, pero apuntan a un impacto potencialmente significativo.
Estado de la explotación
Según watchTowr, a 21 de octubre de 2026 no se ha observado explotación in the wild. Huntress informa de que, a 20 de octubre, no había observado explotación en el entorno de sus socios, no había reproducido un proof of concept y no disponía de información sobre código de exploit público. Las vulnerabilidades no se han incluido en el catálogo CISA Known Exploited Vulnerabilities. En el momento de la publicación tampoco hay indicadores de compromiso (IOC) confirmados.
No obstante, la ausencia de explotación registrada es una valoración limitada en el tiempo. A modo de comparación: cuando en junio de 2024 se reveló CVE-2024-4577 (una vulnerabilidad de PHP en modo CGI en Windows), Akamai registró intentos de explotación en honeypots en un plazo de 24 horas.
Cronología de la filtración y de las reacciones
La situación se desarrolló de forma poco habitual. El 20 de octubre apareció en Hacker News una publicación con información sobre dos vulnerabilidades RCE en PHP, supuestamente con una puntuación CVSS 10.0, indicando los identificadores CVE y una fecha de divulgación: el 22 de octubre (jueves). El autor de la publicación reconoció que su fuente era «trust me, bro». Después de esto, watchTowr confirmó en X que la filtración era real, que las vulnerabilidades estaban bajo embargo y que todos debían esperar hasta el jueves. PHP publicó su propio aviso esa misma tarde, a las 19:33 UTC, fijando el lanzamiento para el miércoles, un día antes de la fecha indicada en la filtración. El aviso incluye una salvedad: el lanzamiento puede adelantarse si los detalles de las vulnerabilidades se hacen públicos o si aparecen indicios de explotación activa.
La filtración reveló el hecho de la existencia de las vulnerabilidades, su puntuación, la fecha y los identificadores CVE, pero no el mecanismo de funcionamiento de las vulnerabilidades. Esta distinción es importante: la filtración no contenía información suficiente para crear un exploit.
Recomendaciones prácticas
PHP no ha publicado soluciones temporales (workaround). Hasta la salida del parche se recomienda el siguiente conjunto de acciones, basado en las recomendaciones de Huntress y CERT-EU:
- Inventario: identifique todas las instalaciones de PHP, incluido el PHP integrado en dispositivos de proveedores, aplicaciones Windows y paneles de control (cPanel, Plesk)
- Preparación para la actualización: prepárese para instalar el parche en cuanto se publique el lanzamiento. Las prioridades deben ser los sistemas expuestos a Internet. Compruebe si su distribución Linux o proveedor de hosting ofrece paquetes con backport
- Versiones obsoletas: los sistemas con PHP 8.1 y anteriores deben actualizarse, retirarse de Internet o situarse detrás de un VPN o un WAF
- Aislamiento: CERT-EU recomienda valorar el aislamiento de las aplicaciones PHP accesibles por Internet de las redes públicas hasta la publicación de la corrección
- Supervisión de procesos: configure alertas cuando php-fpm, php-cgi, httpd o apache2 lancen shells, intérpretes o herramientas de descarga. En servidores Linux sin EDR se puede utilizar process-watcher de Florian Roth: la herramienta registra cada programa que inicia el proceso PHP, junto con su línea de comandos. Importante: registra el proceso después de su inicio y, en palabras del autor, «no previene nada»
- Respuesta a incidentes: si se detecta actividad sospechosa, aisle el servidor, conserve los registros del servidor web y de PHP, compruebe si hay web shells, nuevos archivos en la raíz del sitio, nuevas tareas cron y cuentas de usuario
La priorización del parcheo debe tener en cuenta que los sistemas en ramas obsoletas de PHP (8.1 y anteriores) no recibirán corrección del proveedor. Según Mallory, hay alrededor de 884 000 hosts accesibles por Internet en esta situación. Para estos sistemas, las únicas opciones son actualizar a una rama soportada, restringir el acceso de red o situarlos detrás de un WAF. Las organizaciones que están en ramas soportadas (8.2–8.5) deben instalar el parche en cuanto se publique, empezando por los servidores expuestos a Internet.
El lanzamiento debería aclarar las principales incógnitas: qué versiones concretas están afectadas, qué componente de PHP contiene la vulnerabilidad, si para la explotación se requiere un modo de funcionamiento o configuración específicos de PHP y cómo describe el propio proveedor las vulnerabilidades. Hasta entonces, todas las medidas tienen carácter preventivo, y el paso más crítico es garantizar la preparación para actualizar de inmediato las ramas soportadas y aislar o retirar de producción los sistemas con versiones obsoletas de PHP.
