PHP2Shell: la vulnerabilidad crítica de PHP que pone en riesgo los servidores web y cómo protegerlos
El ecosistema web enfrenta una nueva alerta de seguridad. El 21 de octubre de 2026, el equipo de desarrollo de PHP publicó actualizaciones de emergencia para corregir dos vulnerabilidades críticas conocidas como PHP2Shell: CVE-2026-109618 y CVE-2026-109619.
Estas vulnerabilidades pueden permitir que un atacante remoto ejecute código arbitrario en un servidor vulnerable sin necesidad de autenticarse. El riesgo no se limita a una plataforma específica: afecta al motor PHP y, por tanto, puede alcanzar sitios web, sistemas de gestión de contenidos, aplicaciones empresariales y servicios desarrollados con este lenguaje.
La recomendación principal es clara: identificar las versiones de PHP instaladas, aplicar las actualizaciones de seguridad correspondientes y verificar que los procesos estén ejecutando realmente el código corregido. Fuente oficial de PHP.
¿Qué es PHP2Shell?
PHP2Shell es el nombre utilizado para agrupar dos vulnerabilidades críticas del motor de PHP. Para comprender su gravedad, hay que tener en cuenta que PHP no es solamente una herramienta que utilizan los desarrolladores: es el componente que procesa las solicitudes y ejecuta buena parte de la lógica de miles de aplicaciones web.
Las vulnerabilidades identificadas son:
- CVE-2026-109618: un error relacionado con la gestión de memoria cuando PHP se queda sin memoria disponible durante el procesamiento de una solicitud.
- CVE-2026-109619: un problema de referencias a memoria que ya ha sido liberada, conocido como use-after-free, que puede provocar un comportamiento inseguro entre solicitudes procesadas por determinados procesos de PHP.
En determinadas condiciones, estos fallos pueden permitir que una solicitud especialmente construida desencadene la ejecución de código malicioso o exponga información sensible.
Lo más preocupante es que un atacante no necesariamente necesita explotar un formulario vulnerable de WordPress ni aprovechar un plugin específico. El problema se encuentra en el propio entorno de ejecución de PHP.
¿Qué consecuencias puede tener un ataque?
Si un atacante consigue explotar una instalación vulnerable, el impacto dependerá de los permisos del proceso PHP, la configuración del servidor y los recursos a los que tenga acceso.
Entre los riesgos se encuentran:
1. Ejecución remota de código. Un atacante podría ejecutar instrucciones en el entorno del proceso PHP, lo que puede abrir la puerta a nuevas acciones maliciosas.
2. Robo de información. Los archivos de configuración, las credenciales de bases de datos y otros datos accesibles desde la aplicación podrían quedar expuestos.
3. Compromiso de sitios web. Un atacante podría intentar modificar archivos, introducir puertas traseras o alterar el funcionamiento de una aplicación.
4. Acceso a recursos adicionales. Si los permisos y la segmentación del servidor son deficientes, el incidente podría extenderse a otros sitios o servicios.
5. Interrupción del servicio. La explotación también puede ocasionar errores, caídas de procesos y problemas de disponibilidad.
La explotación no implica automáticamente que todos estos escenarios vayan a ocurrir. Sin embargo, la posibilidad de ejecutar código sin autenticación convierte estas vulnerabilidades en una prioridad para cualquier administrador.
¿Qué versiones de PHP están afectadas?
El equipo oficial de PHP publicó las siguientes versiones corregidas el 21 de octubre de 2026:
| Rama de PHP | Versión corregida |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Las versiones anteriores dentro de estas ramas deben actualizarse. PHP 8.1 y las ramas anteriores también requieren atención: están fuera de soporte oficial o necesitan comprobar si su proveedor ofrece un parche retroportado.
Importante: PHP 8.2 llegará al final de su soporte el 31 de diciembre de 2026. Aunque la versión 8.2.35 corrige estas vulnerabilidades, conviene planificar la migración a una rama con soporte vigente.
En servidores empresariales, la versión que muestra un comando no siempre permite determinar por sí sola si se ha aplicado un parche retroportado por la distribución. Deben verificarse los avisos del proveedor y el estado real del paquete instalado.
Fuente: PHP — Aviso de seguridad oficial.
¿Cómo proteger un servidor Linux con cPanel y WHM?
Los administradores de servidores con AlmaLinux, CloudLinux u otras distribuciones deben actuar en varios niveles.
1. Identificar todas las versiones de PHP
No basta con revisar la versión predeterminada del sistema. Un servidor puede ejecutar distintas versiones de PHP según el dominio, el pool PHP-FPM, la configuración de Apache o las herramientas instaladas.
En un servidor cPanel/WHM, conviene revisar:
- Las versiones instaladas desde EasyApache 4.
- Las versiones asignadas a cada dominio mediante MultiPHP Manager.
- Los servicios PHP-FPM activos.
- Las aplicaciones que incluyen su propia versión de PHP, como determinados contenedores o servicios independientes.
Como comprobación inicial, pueden utilizarse comandos como:
cat /etc/os-release
rpm -qa | grep -E '^ea-php[0-9]+-php-cli'Estos comandos ayudan a identificar la distribución y algunos paquetes PHP de EasyApache. No constituyen por sí solos un inventario completo de las versiones en ejecución.
2. Aplicar las actualizaciones de seguridad
En cPanel/WHM, revisa las actualizaciones disponibles de EasyApache 4 y actualiza los paquetes PHP afectados utilizando las herramientas oficiales de cPanel y los repositorios compatibles con el servidor.
No es recomendable descargar binarios de procedencia desconocida ni sustituir manualmente archivos del motor PHP en un servidor de producción.
Antes de realizar cambios, prepara una copia de seguridad y evalúa la compatibilidad de las aplicaciones. Después de actualizar, reinicia o recarga los servicios afectados siguiendo el procedimiento correspondiente a la configuración instalada.
3. Confirmar que el parche está activo
Una actualización instalada no garantiza que los procesos antiguos hayan dejado de ejecutarse.
Después del cambio, verifica la versión efectiva de cada entorno y comprueba que PHP-FPM, Apache u otros servicios estén utilizando los componentes actualizados. También conviene realizar pruebas funcionales de los sitios alojados.
4. Revisar los registros y buscar indicios de compromiso
Si el servidor estuvo expuesto mientras ejecutaba una versión vulnerable, no basta con actualizar y dar el incidente por cerrado.
Revisa, entre otros elementos:
- Los registros de acceso y errores del servidor web.
- Los errores de PHP y los reinicios inesperados de procesos.
- Las solicitudes multipart inusuales o repetitivas.
- Los archivos PHP nuevos o modificados sin autorización.
- Las tareas cron, los procesos y las cuentas que no reconozcas.
- Las conexiones salientes inesperadas desde los procesos web.
Ningún indicador aislado confirma necesariamente un ataque. La investigación debe considerar las marcas de tiempo, el contexto y la actividad legítima del sitio.
Si existen indicios de intrusión, preserva los registros y aísla el sistema cuando corresponda. Investiga las posibles puertas traseras y las credenciales expuestas antes de considerar resuelto el incidente.
¿Qué ocurre si no puedo actualizar inmediatamente?
La respuesta más segura es restringir o retirar temporalmente de Internet el servicio vulnerable hasta poder aplicar una corrección compatible.
Las recomendaciones provisionales de configuración pueden reducir determinadas vías de exposición, pero no sustituyen el parche de PHP. Desactivar funciones de seguimiento de cargas, limitar solicitudes multipart o ajustar parámetros de memoria no debe interpretarse como una solución definitiva.
Un firewall de aplicaciones web (WAF), las reglas de seguridad de un proxy y los servicios de protección perimetral pueden aportar una capa adicional de defensa. Sin embargo, las reglas pueden no cubrir todas las variantes del ataque, por lo que deben mantenerse como complemento de la actualización.
¿Los sitios WordPress también están en riesgo?
Sí. WordPress está desarrollado principalmente en PHP, por lo que la seguridad del motor que ejecuta la aplicación es fundamental.
Para reducir el riesgo, los propietarios de sitios WordPress deben:
- Solicitar a su proveedor de hosting que confirme la aplicación de los parches.
- Mantener WordPress, los temas y los plugins actualizados.
- Eliminar extensiones abandonadas o que no se utilicen.
- Utilizar contraseñas robustas y autenticación multifactor para las cuentas administrativas.
- Mantener copias de seguridad verificadas y separadas del entorno de producción.
- Revisar los archivos y las cuentas si existen señales de actividad sospechosa.
Actualizar WordPress o instalar un plugin de seguridad no corrige por sí mismo una vulnerabilidad presente en el motor PHP.
Conclusión: actualizar es la prioridad
PHP2Shell recuerda que la seguridad de una aplicación depende también de las tecnologías que se encuentran por debajo de ella.
Una instalación de WordPress actualizada puede seguir expuesta si el servidor ejecuta una versión vulnerable de PHP. Del mismo modo, un servidor con firewall, antivirus y copias de seguridad no queda automáticamente protegido frente a la ejecución remota de código.
La respuesta adecuada consiste en inventariar las instalaciones, aplicar las actualizaciones oficiales, reiniciar los procesos necesarios, verificar el resultado y revisar posibles indicios de compromiso.
La recomendación para empresas, administradores y proveedores de hosting es actuar sin demora y no considerar resuelto el riesgo hasta comprobar que todos los entornos PHP expuestos están corregidos.
