Dos fallos críticos y cuatro versiones corregidas
El proyecto PHP publicó este 21 de octubre una actualización de seguridad urgente para dos vulnerabilidades capaces de permitir la ejecución remota de código sin autenticación. Los arreglos llegan en PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12, las nuevas versiones que el equipo recomienda instalar de inmediato.
Los identificadores son CVE-2026-109618 y CVE-2026-109619. Ambos recibieron una valoración crítica de 9,2 sobre 10 en CVSS 4.0 durante el aviso previo. El primero afecta al tratamiento de condiciones de memoria agotada; el segundo, a estado interno que puede sobrevivir de forma incorrecta cuando un proceso atiende varias peticiones.
Por qué el aviso afecta a más que una aplicación concreta
No se trata de un fallo de WordPress, Drupal, Joomla, una tienda o un complemento específico. La vulnerabilidad está en el intérprete PHP que ejecuta el código en el servidor, de modo que la pregunta relevante es qué versión real usa cada web y quién mantiene ese componente.
El aviso oficial incluye instalaciones que atienden peticiones mediante PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo sitúa el riesgo demostrado más alto en mod_php, donde una petición sin autenticar puede alcanzar la ruta vulnerable antes de que se ejecute el código de la propia aplicación.
La búsqueda se dispara en España tras la publicación del parche
A las 08:52 CEST del 22 de octubre, Google Trends España mostraba 'php vulnerabilidad' con 2.000+ búsquedas, una subida del 600 %, inicio hacía once horas y tendencia activa dentro de Tecnología en las últimas 24 horas. La consulta relacionada en inglés 'php vulnerability' registraba otras 2.000+ búsquedas, +400 % y también seguía activa tras diecinueve horas.
Google News España devolvía 80 resultados visibles no vacíos y 78 titulares únicos para 'PHP vulnerabilidad' durante el último día. La cobertura incluía a RTVE, Xataka, DW y EL PAÍS, entre otros medios. Es una señal de búsquedas y de propagación mediática; no representa clics reales, tráfico de AUTOINTELLIA, servidores afectados ni ataques confirmados en España.
Qué cambia para una web alojada en España
Quien gestiona su propio servidor debe comprobar el paquete instalado y la versión que atiende tráfico web, no solo la que devuelve una consola distinta o un entorno de desarrollo. En distribuciones Linux, el número corregido puede no coincidir con el de php.net porque el proveedor aplica el parche a su propio paquete; Ubuntu, por ejemplo, publicó el mismo día versiones actualizadas para sus ediciones compatibles.
En un alojamiento administrado, la actualización depende normalmente del proveedor. El propietario de la web debe pedir una confirmación verificable de la versión o del paquete corregido. Actualizar el CMS o sus extensiones no sustituye el parche del intérprete si la plataforma continúa ejecutándose sobre un PHP vulnerable.
Las ramas antiguas complican la respuesta
PHP 8.1 y versiones anteriores ya no reciben mantenimiento ordinario del proyecto. Ante la gravedad de estos fallos, el equipo publicó backports mínimos de código fuente para 7.4, 8.0 y 8.1, pero eso no convierte de nuevo esas ramas en productos con soporte general ni garantiza que cada proveedor las distribuya con rapidez.
La salida preferente sigue siendo una rama compatible o un paquete mantenido por el sistema operativo o por un proveedor de soporte a largo plazo. Una compilación local de emergencia puede reducir el riesgo inmediato, pero añade la responsabilidad de probarla, desplegarla y seguir todas las correcciones posteriores.
Mitigar no equivale a cerrar el fallo
El aviso de PHP propone medidas temporales para reducir algunas rutas: ajustar límites de memoria y tamaño de peticiones, desactivar el progreso de subida de sesiones y reiniciar los procesos, entre otras. También advierte de que esas medidas no cubren todas las variantes y que ocultar mensajes de error no resuelve el problema.
El Centro Nacional de Ciberseguridad británico recomienda identificar primero todos los sistemas con PHP, priorizar los expuestos a internet y aplicar las actualizaciones del proveedor. Si un sistema no puede actualizarse ni mitigarse a tiempo, plantea valorar su desconexión temporal y revisar indicios de compromiso antes de devolverlo al servicio.
Lo que todavía no permite afirmar la evidencia pública
Las pruebas técnicas publicadas demuestran que las vulnerabilidades pueden explotarse, pero eso no fija cuántos servidores siguen expuestos ni acredita por sí solo una campaña activa en España. Las cifras difundidas por escáneres externos dependen de cómo detectan versiones y configuraciones, y no deben confundirse con víctimas confirmadas.
Durante las próximas horas conviene vigilar avisos de proveedores de alojamiento, distribuciones Linux, paneles de control y productos que incorporan PHP sin mostrarlo al usuario. La noticia ya no es que vaya a llegar un parche: el parche está publicado. La siguiente fase es comprobar qué plataformas lo han integrado y si aparecen evidencias fiables de explotación real.
