El proyecto PHP publicó el 21 de octubre de 2026 actualizaciones para dos vulnerabilidades críticas que permiten la ejecución remota de código sin autenticación. Para quienes administran sitios y aplicaciones basadas en PHP, la prioridad es actualizar el motor utilizado por el servidor y verificar que los procesos activos hayan cargado la versión correcta. Actualizar únicamente el CMS no soluciona un defecto del lenguaje subyacente.
🚨 Organizations should immediately patch critical PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619. These vulnerabilities enable unauthenticated #RCE and affect PHP installations serving web requests. Learn more: 🔗 https://t.co/8vu6SvNzfB pic.twitter.com/LUWik7aQcG
, CISA Cyber (@CISACyber) October 21, 2026
Los fallos están identificados como CVE-2026-109618 y CVE-2026-109619, ambos con una gravedad de 9,2 sobre 10 en la escala CVSS v4.0. Cloudflare declaró haber observado tráfico de ataque contra sus clientes, mientras que CloudLinux reportó intentos que coinciden con los patrones conocidos. Son señales de actividad hostil: no demuestran que cada instalación vulnerable haya sido comprometida.
Dos problemas en la gestión de memoria
La CVE-2026-109618 afecta al comportamiento de PHP cuando una operación agota la memoria disponible. La interrupción puede dejar datos internos parcialmente inicializados; durante el cierre de la solicitud, el proceso puede tratarlos como válidos. El aviso oficial documenta un impacto que puede llegar a la ejecución de código sin credenciales, con los privilegios de la cuenta que ejecuta el proceso web.
La CVE-2026-109619, en cambio, afecta a un estado interno que permanece accesible después de liberar la memoria a la que hacía referencia. Una solicitud posterior, gestionada por el mismo proceso, puede utilizar esas referencias ya inválidas. También en este caso se ha demostrado la posibilidad de ejecutar código de forma remota. Esto no significa obtener automáticamente privilegios de administrador del sistema: el impacto inicial depende de los permisos del proceso involucrado.
Qué servidores están expuestos
El aviso de PHP abarca las instalaciones que procesan solicitudes web mediante PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El proyecto considera el riesgo más alto en Apache con mod_php, donde un ataque demostrado puede activarse antes de que comience la ejecución del código de la aplicación. Un control insertado en el CMS no puede considerarse, por tanto, una protección suficiente para ese escenario.
El riesgo no es idéntico en todas las configuraciones. Los avisos distinguen entre rutas de ataque demostradas y condiciones que dependen del modo de ejecución, las extensiones y la aplicación concreta. Para la segunda vulnerabilidad se ha validado la ejecución remota también en PHP-FPM a través del ciclo de gestión de sesiones. Usar PHP-FPM, por sí solo, no permite considerar el servidor como exento.
Los tres puntos clave
- Gravedad: dos vulnerabilidades críticas, ambas con CVSS v4.0 de 9,2.
- Corrección: actualizar PHP y asegurarse de que los procesos que sirven el sitio carguen el código correcto.
- Verificación: comprobar el motor efectivamente usado por el servidor web, no únicamente el comando disponible en el terminal.
Versiones correctas y paquetes con backport
El proyecto PHP indica las primeras versiones corregidas para las cuatro ramas mantenidas. La tabla se refiere a las versiones distribuidas por el proyecto: para los paquetes de las distribuciones Linux y de los proveedores de soporte es necesario consultar también el boletín de seguridad correspondiente.
Two critical vulnerabilities have been identified in PHP, a widely used programming language that powers websites and web applications. These vulnerabilities (CVE-2026-109618 and CVE-2026-109619) could allow malicious cyber actors to remotely execute code in PHP core, potentially… pic.twitter.com/tnwiQv5v0F
, FBI Cyber Division (@FBICyberDiv) October 21, 2026
Las versiones exactas están recogidas en los avisos oficiales de ambas vulnerabilidades.
PHP 8.1 y las ramas anteriores ya no reciben actualizaciones del proyecto PHP, pero algunos proveedores mantienen paquetes con correcciones portadas a versiones más antiguas, los llamados backports. Para estos paquetes, el simple número de versión original no basta para determinar si la corrección está presente: hace falta verificar la revisión distribuida y las indicaciones del proveedor. El soporte de seguridad oficial de PHP 8.2 finaliza además el 31 de diciembre de 2026: aplicar este parche y planificar la migración son dos necesidades distintas.
Cómo actualizar y comprobar el resultado
La actualización debe afectar a todas las instalaciones PHP utilizadas en el servidor. Un solo sistema puede alojar varias versiones, varios sitios y procesos separados. Las notas de cPanel distinguen, por ejemplo, el PHP interno del panel de los paquetes EasyApache destinados a los sitios. Plesk y CloudLinux también publican indicaciones para componentes y plataformas específicos: la disponibilidad debe verificarse para el entorno efectivamente utilizado.
Daniele Molteni
El comando php -v identifica el programa ejecutado desde la shell, que puede ser distinto del motor configurado para el sitio. Una verificación en el panel o una página de diagnóstico ejecutada desde el servidor web permite comprobar el contexto correcto. Si se utiliza phpinfo(), el acceso debe ser limitado y la página eliminada tras la comprobación: puede mostrar rutas, configuraciones, cabeceras y variables de entorno. El procedimiento a acordar con el administrador o proveedor es el siguiente:
- Preparar una copia de seguridad o un snapshot, con un procedimiento de restauración disponible.
- Identificar las versiones y componentes en uso, incluidos los motores asignados a los diferentes sitios y los utilizados por los paneles.
- Instalar los paquetes correctos mediante el gestor de la distribución o las herramientas oficiales del proveedor.
- Reiniciar los servicios y procesos afectados, siguiendo las indicaciones para PHP-FPM, Apache o el entorno utilizado: los procesos antiguos no deben continuar gestionando solicitudes.
- Comprobar el resultado desde el terminal y desde el sitio, verificando la versión, la revisión del paquete y el funcionamiento de las aplicaciones.
WAF y medidas temporales no sustituyen el parche
Cloudflare y CloudLinux han anunciado reglas para interceptar algunos esquemas de ataque. Son una capa adicional de protección, no la eliminación del defecto en el servidor. El propio Cloudflare recomienda aplicar las actualizaciones de PHP incluso cuando las protecciones WAF están activas.
Las modificaciones de configuración indicadas en los avisos oficiales también cubren rutas específicas y no constituyen una solución general. Deben evaluarse según la aplicación y aplicarse en el punto correcto de la configuración. La protección completa frente a estos dos fallos requiere el código correcto, distribuido por el proyecto PHP o a través de un paquete del proveedor que incluya los parches.
La lectura de fondo
Básicamente, el control decisivo es lo que el servidor está ejecutando realmente. La presencia de un paquete actualizado o de un panel en la última versión no demuestra, por sí sola, que cada sitio haya abandonado el motor antiguo. La verificación debe llegar hasta el proceso que recibe y gestiona las solicitudes.
Para los administradores, la intervención se completa con tres resultados verificables: correcciones instaladas, procesos actualizados y revisión de las aplicaciones expuestas. Esta secuencia evita confundir la disponibilidad del parche con su aplicación efectiva.
Fuentes
- PHP, aviso oficial del 21 de octubre de 2026.
- PHP, advisory CVE-2026-109618 y advisory CVE-2026-109619.
- PHP, calendario de versiones soportadas.
- Cloudflare, ataques observados y protecciones WAF.
- CloudLinux, estado de las actualizaciones y mitigaciones.
- cPanel, notas de lanzamiento y Plesk, boletín sobre los componentes afectados.
- Manual de PHP: opciones de línea de comandos y información expuesta por phpinfo.
