Las fallas, identificadas como CVE-2026-109618 y CVE-2026-109619, tienen una puntuación CVSS de 9,2 y pueden permitir la ejecución remota de código. Ubuntu, Plesk y cPanel distribuyen correcciones que, en algunos casos, no modifican el número de versión visible de PHP.
El proyecto PHP publicó el 21 de octubre de 2026 actualizaciones de seguridad para corregir dos vulnerabilidades críticas conocidas como PHP2Shell. Identificadas como CVE-2026-109618 y CVE-2026-109619, ambas tienen una puntuación CVSS 4.0 de 9,2 y pueden permitir la ejecución remota de código sin autenticación en determinadas configuraciones.
El problema afecta a servidores web que ejecutan PHP mediante distintas modalidades, entre ellas Apache con mod_php, PHP-FPM, php-cgi, FrankenPHP y LiteSpeed, según los avisos de seguridad publicados por el proyecto.
La gravedad del hallazgo radica en que un atacante podría llegar a ejecutar código en el servidor vulnerable sin disponer previamente de una cuenta. La posibilidad concreta de explotación depende de la configuración y de las rutas de ejecución involucradas.
La PHP Foundation informó que la ejecución de código se demostró en Apache con mod_php utilizando la configuración predeterminada. También se confirmó la posibilidad de explotación en PHP-FPM a través de determinadas rutas de código de las aplicaciones.
Qué versiones de PHP incluyen las correcciones
El proyecto PHP publicó versiones corregidas para las ramas que reciben actualizaciones de seguridad:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Los administradores deben comprobar qué versión y qué paquete ejecuta cada aplicación, además de verificar las actualizaciones disponibles para su distribución o proveedor de alojamiento.
La comprobación no siempre puede hacerse mirando únicamente el número de versión que muestra un panel de administración. Algunos proveedores incorporan las correcciones en sus paquetes sin modificar el número de versión principal de PHP.
Los ataques y la disponibilidad de exploits
La actividad relacionada con PHP2Shell comenzó antes de la publicación oficial de las correcciones. Según informó SecurityWeek el 22 de octubre, Amazon observó un primer intento de ataque el 17 de octubre, mientras que la actividad aumentó después de hacerse públicas las vulnerabilidades.
El mismo informe recogió observaciones de la firma de seguridad watchTowr sobre exploits que circulaban públicamente y que, en las pruebas descritas, no conseguían ejecutar código: algunos se limitaban a medir tiempos de respuesta o podían provocar la caída del servidor.
Esto no elimina el riesgo. La disponibilidad de pruebas de concepto, los cambios que puedan introducir otros atacantes y las diferencias entre configuraciones hacen que la aplicación de las correcciones siga siendo una medida prioritaria.
La CISA, la agencia de ciberseguridad de Estados Unidos, también publicó una alerta sobre estas vulnerabilidades. Al publicarla, el 21 de octubre, la CISA todavía no había observado explotación. Las organizaciones que no puedan actualizar inmediatamente deben evaluar su exposición y las medidas de contención necesarias.
Por qué un servidor puede mostrar la misma versión y estar actualizado
Una particularidad de este incidente es que algunos proveedores aplican las correcciones sobre paquetes que conservan el número de versión de PHP. Por eso, observar una versión como 8.3.6 o 8.1.34 en un panel no permite determinar por sí solo si el servidor está protegido.
Los mecanismos de verificación dependen del proveedor:
Ubuntu
Ubuntu distribuye correcciones para sus paquetes mediante actualizaciones de seguridad. En Ubuntu 24.04 LTS, el aviso USN-8948-1 identifica como corregida la versión de paquete 8.3.6-0ubuntu0.24.04.13 o posterior, según corresponda.
Aunque PHP siga identificándose como 8.3.6, el sufijo del paquete permite distinguir la revisión que contiene la corrección.
Plesk
Plesk publicó actualizaciones para las versiones afectadas de PHP y para los componentes propios del panel que también requieren corrección.
En PHP 8.2 a 8.5 se publicaron versiones corregidas con nuevos números de versión. Para PHP 7.4.33, 8.0.30 y 8.1.34, la fecha de compilación permite identificar las compilaciones actualizadas.
También es necesario comprobar la versión del panel Plesk Obsidian. Según el aviso del proveedor, las versiones corregidas incluyen 18.0.81 Update 4 y 18.0.80 Update 11. Tener una rama de numeración aparentemente más reciente no garantiza, por sí solo, que esté instalada la actualización correspondiente.
cPanel
cPanel publicó paquetes corregidos para distintas ramas de PHP distribuidas mediante EasyApache 4, incluidos paquetes de ea-php74 a ea-php85.
Entre los ejemplos de paquetes actualizados figuran ea-php74 7.4.33-19 y ea-php81 8.1.34-5. El proveedor también publicó actualizaciones para distintas versiones de cPanel & WHM.
En estos entornos, el registro de cambios (changelog) del paquete permite comprobar si se incorporó la corrección correspondiente a las vulnerabilidades.
Qué deben revisar los administradores
La recomendación es comprobar el estado de los paquetes de PHP y las actualizaciones del entorno de alojamiento, en lugar de confiar únicamente en el número de versión visible en el panel.
En Ubuntu 24.04 LTS, por ejemplo, la versión instalada puede consultarse mediante:
dpkg-query -W libapache2-mod-php8.3 php8.3-fpm php8.3-cgi php8.3-cli
El resultado muestra la versión instalada de cada paquete. La comparación debe hacerse con las versiones corregidas publicadas para la distribución concreta.
En cPanel, el proveedor documenta el siguiente comando para comprobar si el registro de cambios de un paquete menciona la vulnerabilidad:
rpm -q --changelog ea-php81-php-cli | grep -m1 CVE-2026-109618
El ejemplo corresponde a ea-php81 en sistemas que utilizan paquetes RPM. En servidores Ubuntu con cPanel, el procedimiento es diferente y debe seguirse la documentación específica del proveedor.
En Plesk, la versión y la fecha de compilación pueden consultarse desde la línea de comandos. Por ejemplo, para PHP 8.3:
/opt/plesk/php/8.3/bin/php -v
Además de revisar los paquetes de PHP, es necesario comprobar que el propio panel de administración esté actualizado.
Los comandos y las versiones de referencia pueden variar según la distribución, la rama de PHP y el sistema de gestión instalado. Antes de ejecutar actualizaciones en producción, conviene verificar las instrucciones oficiales correspondientes al entorno.
El problema de las versiones antiguas de PHP
Las instalaciones que utilizan PHP 8.1 o versiones anteriores requieren especial atención. Estas ramas ya no reciben actualizaciones de seguridad del proyecto PHP, aunque algunos proveedores y servicios comerciales ofrecen mantenimiento extendido para determinadas versiones.
Para PHP 7.4 a 8.1, cPanel y Plesk ya publicaron paquetes corregidos propios. Solo para versiones anteriores a 7.4, los dos paneles recomiendan el soporte extendido de TuxCare.
La CISA recomienda que las organizaciones que no puedan actualizar sus sistemas vulnerables de inmediato, incluidas aquellas que continúen utilizando versiones antiguas de PHP, retiren de servicio los sistemas afectados hasta que puedan corregirlos o actualizarlos.
El proyecto PHP también describe medidas temporales para reducir la exposición, como deshabilitar determinadas funciones de seguimiento de carga de sesiones. Sin embargo, estas medidas no sustituyen la instalación de las correcciones.
Una actualización que requiere verificar todo el entorno
PHP2Shell pone de relieve que la seguridad de un servidor no depende únicamente de la versión de PHP que muestra una aplicación. También intervienen los paquetes instalados, las compilaciones distribuidas por cada proveedor, los componentes del panel de administración y el soporte vigente de la rama utilizada.
Para las empresas que dependen de aplicaciones web, tiendas en línea o sistemas internos, el primer paso es identificar qué versiones de PHP están en uso y comprobar si las correcciones correspondientes se encuentran instaladas.
En los servidores administrados por terceros, conviene solicitar al proveedor una confirmación explícita de las actualizaciones aplicadas y del método utilizado para verificarlas.