Cómo mitigar la vulnerabilidad crítica de PHP con Imunify360 y Hardened PHP
Después de más de veinte años administrando servidores y trabajando en el sector del alojamiento web, hay algo que tengo cada vez más claro: la seguridad de una página web no depende únicamente de mantener WordPress, PrestaShop o sus plugins actualizados. También depende, y mucho, de lo que ocurre dentro del servidor donde está alojada.
Y precisamente eso es lo que nos ha vuelto a recordar PHP2Shell, el nombre con el que se conocen dos vulnerabilidades críticas de PHP que han puesto en alerta a administradores de sistemas y proveedores de hosting.
El 21 de octubre de 2026, el equipo de PHP publicó actualizaciones de seguridad para corregir dos fallos identificados como CVE-2026-109618 y CVE-2026-109619, ambos con una gravedad de 9,2 sobre 10 según CVSS v4.0.
Lo preocupante es que estos errores pueden permitir que un atacante ejecute código en un servidor de forma remota, sin necesidad de conocer contraseñas ni acceder previamente al panel de administración de una página web.
No estamos hablando de un plugin vulnerable o de una aplicación que su propietario haya olvidado actualizar.
Estamos hablando de un problema en el propio intérprete de PHP, una pieza fundamental para el funcionamiento de millones de sitios web.
En HostingTG llevamos más de dos décadas trabajando con servidores y alojamientos web. Durante este tiempo hemos aprendido que la seguridad debe abordarse desde diferentes niveles.
Por eso utilizamos Imunify360 en todos nuestros hostings, dentro de una estrategia que combina prevención, monitorización, mantenimiento y actualizaciones de seguridad.
En este artículo quiero explicar qué es PHP2Shell, qué riesgos representa y cómo podemos mitigar las vulnerabilidades críticas de PHP utilizando Imunify360, Hardened PHP y los parches de seguridad correspondientes.
Porque si algo nos ha enseñado nuestra experiencia es que no basta con reaccionar cuando aparece una vulnerabilidad: también debemos disponer de las herramientas necesarias para reducir sus consecuencias.
PHP2Shell: la vulnerabilidad crítica que pone en riesgo los servidores PHP
PHP es uno de los lenguajes de programación más utilizados para desarrollar páginas web y aplicaciones dinámicas.
Sistemas tan conocidos como WordPress, PrestaShop, Joomla, Drupal o Moodle dependen de PHP para ejecutar buena parte de sus funciones.
Normalmente, cuando hablamos de vulnerabilidades en estas plataformas, pensamos en extensiones desactualizadas, temas inseguros o errores en el código de una aplicación.
Sin embargo, PHP2Shell es diferente.
Las vulnerabilidades están presentes en componentes internos del propio lenguaje, relacionados con la gestión de memoria y el procesamiento de determinadas peticiones.
Esto significa que el problema puede afectar a múltiples aplicaciones que comparten una misma instalación de PHP, independientemente de que su código esté actualizado.
Qué son CVE-2026-109618 y CVE-2026-109619
Aunque las dos vulnerabilidades se agrupan bajo el nombre PHP2Shell, sus causas técnicas son distintas.
CVE-2026-109618: corrupción de memoria por falta de recursos
Esta vulnerabilidad está relacionada con la manera en la que PHP gestiona determinados errores de falta de memoria, conocidos como Out of Memory u OOM.
Bajo ciertas condiciones, el procesamiento de una petición puede interrumpirse cuando algunas estructuras internas todavía no están completamente inicializadas.
Posteriormente, los procesos de limpieza pueden utilizar información inválida, generando situaciones de corrupción de memoria.
En determinadas configuraciones, un atacante podría aprovechar este comportamiento para ejecutar código malicioso.
CVE-2026-109619: reutilización de información interna liberada
El segundo fallo está relacionado con el uso de información interna cuya memoria ya ha sido liberada.
En determinados escenarios, datos pertenecientes a una petición anterior pueden permanecer asociados al proceso PHP y ser utilizados incorrectamente cuando se procesa una nueva solicitud.
Este comportamiento puede dar lugar a una vulnerabilidad de tipo use-after-free (uso de memoria después de haber sido liberada), que bajo determinadas condiciones también puede permitir a un atacante ejecutar código malicioso de forma remota en el servidor.
Por qué una web actualizada también puede ser vulnerable
Uno de los errores que más he visto durante mi trayectoria profesional es pensar que una página web está protegida simplemente porque utiliza las últimas versiones de sus aplicaciones.
Y quiero dejar algo claro: mantener actualizado WordPress, PrestaShop o cualquier otro CMS es imprescindible, pero no garantiza por sí solo que el alojamiento sea seguro.
Imaginemos una tienda online que utiliza la versión más reciente de PrestaShop, tiene todos sus módulos actualizados y cuenta con contraseñas seguras.
En principio, su propietario está haciendo las cosas correctamente.
Sin embargo, si el servidor donde está alojada ejecuta una versión vulnerable de PHP, esa tienda podría seguir expuesta a PHP2Shell.
El motivo es sencillo: las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 afectan al intérprete de PHP, no al código específico de la tienda online.
Además, el equipo de seguridad de PHP ha confirmado que determinadas condiciones de explotación pueden producirse antes de que comience a ejecutarse el código de la aplicación, especialmente en servidores que utilizan Apache con mod_php.
Esto resulta particularmente preocupante porque deja fuera de juego algunas de las medidas de seguridad que normalmente aplicamos dentro de WordPress o PrestaShop.
Por ejemplo, un plugin de seguridad de WordPress no puede corregir un fallo que se produce antes de que WordPress empiece a ejecutarse.
Por eso, después de tantos años trabajando con servidores, insisto en una idea: la seguridad debe comenzar en la infraestructura.
Y ahí es donde entran en juego las actualizaciones de PHP, las reglas de protección de Imunify360 y soluciones de soporte extendido como Hardened PHP.
Versiones de PHP afectadas y versiones corregidas
El 21 de octubre de 2026 se publicaron las actualizaciones oficiales que corrigen las dos vulnerabilidades críticas.
Las versiones afectadas y sus correspondientes versiones corregidas son las siguientes:
| Rama de PHP | Versiones vulnerables | Primera versión oficial corregida |
|---|---|---|
| PHP 8.5 | 8.5.11 y anteriores | PHP 8.5.12 |
| PHP 8.4 | 8.4.26 y anteriores | PHP 8.4.27 |
| PHP 8.3 | 8.3.35 y anteriores | PHP 8.3.36 |
| PHP 8.2 | 8.2.34 y anteriores | PHP 8.2.35 |
| PHP 8.1 y anteriores | Sin nueva versión oficial corregida | Requieren actualización de rama o correcciones del proveedor |
Hay un matiz importante en esta tabla.
Las versiones antiguas de PHP que han llegado al final de su vida útil, conocido como End of Life o EOL, ya no reciben actualizaciones oficiales convencionales.
Sin embargo, determinados proveedores de sistemas operativos y servicios de soporte extendido distribuyen paquetes corregidos para esas ramas.
Por eso, no debemos asumir que una instalación es vulnerable únicamente porque su número de versión parece antiguo.
Por ejemplo, una distribución puede mantener el número PHP 8.4.26 e incorporar mediante un backport las correcciones que el proyecto oficial publicó en PHP 8.4.27.
Lo importante es comprobar el paquete instalado, su fecha de compilación y la información de seguridad facilitada por el proveedor.
También debemos tener presente que en un mismo servidor pueden convivir varias versiones de PHP.
Esta situación es muy habitual en alojamientos con cPanel, donde diferentes clientes utilizan versiones distintas por motivos de compatibilidad.
Por tanto, actualizar la versión de PHP de una página web no significa necesariamente que todas las instalaciones del servidor estén protegidas.
Cómo ayuda Imunify360 a mitigar los ataques PHP2Shell
Cuando aparece una vulnerabilidad tan grave como PHP2Shell, una de mis principales preocupaciones es reducir la exposición mientras aplicamos las correcciones necesarias.
En un servidor que aloja numerosas páginas web, cada minuto importa.
Durante nuestra trayectoria en HostingTG hemos visto cómo determinadas vulnerabilidades comienzan a utilizarse en ataques automatizados poco después de hacerse públicas.
Los atacantes no necesitan conocer personalmente una página web ni tener un interés especial en ella.
En muchos casos utilizan herramientas que recorren grandes cantidades de direcciones buscando sistemas vulnerables.
Por eso considero fundamental disponer de soluciones capaces de detectar y bloquear comportamientos sospechosos antes de que lleguen a comprometer un servidor.
Aquí es donde Imunify360 desempeña un papel importante.
Reglas de firewall y protección frente a intentos de explotación
Imunify360 es una plataforma de seguridad diseñada para proteger servidores Linux utilizados en entornos de alojamiento web.
Entre sus principales funcionalidades encontramos el firewall de aplicaciones web, la detección de malware, la monitorización de amenazas y diferentes mecanismos de protección frente a ataques.
En el caso de PHP2Shell, Imunify360 ha distribuido reglas destinadas a identificar y bloquear determinados intentos de explotación de las vulnerabilidades críticas de PHP.
Estas protecciones permiten actuar sobre patrones de tráfico sospechosos antes de que las peticiones alcancen los componentes vulnerables.
Desde mi punto de vista, su utilidad es especialmente importante durante las primeras horas de una alerta de seguridad.
No siempre es posible actualizar inmediatamente todos los servidores y todas las versiones de PHP instaladas.
Puede haber aplicaciones que requieren pruebas de compatibilidad, clientes con configuraciones específicas o paquetes del proveedor que todavía están pendientes de distribución.
Disponer de reglas de protección adicionales ayuda a reducir el riesgo durante ese intervalo.
Ahora bien, las reglas de un firewall de aplicaciones web dependen de su capacidad para reconocer los comportamientos que intentan bloquear.
Un atacante puede modificar determinadas características de una petición y conseguir que deje de coincidir con los patrones conocidos.
Por eso, aunque Imunify360 representa una capa de seguridad muy valiosa, debemos entender correctamente su función.
Su objetivo es mitigar determinados ataques, no corregir los errores internos del intérprete de PHP.
Por qué Imunify360 no sustituye las actualizaciones de PHP
Este es uno de los puntos en los que más me gusta insistir cuando hablamos de seguridad.
Instalar Imunify360 no significa que podamos olvidarnos de actualizar PHP.
Tampoco debemos interpretar que un servidor está completamente protegido simplemente porque su firewall ha recibido nuevas reglas.
La diferencia entre mitigación y corrección es fundamental.
Una mitigación intenta reducir la probabilidad de que una vulnerabilidad pueda explotarse.
Una corrección elimina el fallo concreto que permite esa explotación.
En PHP2Shell, el problema se encuentra en la gestión interna de memoria de PHP.
Ninguna regla de firewall puede modificar por sí sola ese comportamiento.
Para corregirlo necesitamos instalar una versión de PHP que incorpore los parches correspondientes.
Además, algunos ataques pueden utilizar variantes que no coincidan con las reglas de detección existentes.
Esta es precisamente la razón por la que no me gusta hablar de sistemas completamente invulnerables.
Después de tantos años trabajando en este sector, tengo claro que la seguridad absoluta no existe.
Lo que sí podemos hacer es establecer diferentes barreras, reducir la superficie de ataque y mantener actualizados los componentes críticos.
En otras palabras: Imunify360 es una parte importante de la solución, pero no debemos confundir protección adicional con eliminación de la vulnerabilidad.
Nuestra estrategia de seguridad con Imunify360 en HostingTG
En HostingTG utilizamos Imunify360 en todos nuestros hostings porque consideramos que la seguridad debe formar parte de la infraestructura, no ser una opción que el cliente tenga que contratar por separado.
A lo largo de más de veinte años hemos tenido que afrontar amenazas muy diferentes.
Desde ataques de fuerza bruta contra cuentas de administración hasta archivos maliciosos, intentos de inyección de código, infecciones en gestores de contenidos y vulnerabilidades en componentes del servidor.
Esa experiencia nos ha enseñado que depender de una única herramienta no es suficiente.
Por eso trabajamos con una estrategia de protección por capas.
Imunify360 nos proporciona capacidades de detección, prevención y respuesta frente a diferentes amenazas.
Las actualizaciones de seguridad permiten corregir vulnerabilidades conocidas en el sistema operativo y las aplicaciones.
La monitorización facilita identificar comportamientos anómalos.
Y la administración activa del servidor permite revisar configuraciones y tomar decisiones cuando aparecen nuevas alertas de seguridad.
PHP2Shell es un ejemplo de por qué considero acertado trabajar de esta manera.
Si aparece una vulnerabilidad en PHP, necesitamos poder actuar tanto sobre el tráfico que llega al servidor como sobre la versión del intérprete que procesa las peticiones.
Una buena estrategia de seguridad no consiste en elegir entre firewall y actualizaciones, sino en utilizar ambas medidas de forma complementaria.
Hardened PHP: cómo proteger versiones antiguas de PHP
Uno de los problemas habituales cuando administramos servicios de alojamiento web es que no todas las aplicaciones pueden actualizarse inmediatamente a las versiones más recientes de PHP.
Me encuentro con esta situación con bastante frecuencia.
Hay páginas web desarrolladas hace años, tiendas online con módulos que dejaron de recibir mantenimiento y aplicaciones empresariales que dependen de determinadas funciones de versiones antiguas de PHP.
Lo ideal sería modernizarlas.
Pero quienes trabajamos administrando servidores sabemos que una migración de PHP puede requerir modificaciones en el código, pruebas de compatibilidad y, en algunos casos, una renovación importante de la aplicación.
Mientras llega ese momento, necesitamos mantener el entorno lo más protegido posible.
Aquí es donde Hardened PHP cobra especial importancia.
Qué es Hardened PHP y cómo funciona el soporte extendido
Hardened PHP es una solución de soporte de seguridad extendido que permite mantener determinadas versiones antiguas de PHP mediante la incorporación de correcciones de seguridad.
Su principal utilidad es proporcionar una alternativa temporal para aplicaciones que todavía no pueden funcionar con una versión moderna de PHP.
Cuando una rama alcanza el final de su vida útil, deja de recibir actualizaciones oficiales del proyecto PHP.
Eso no significa que sus vulnerabilidades desaparezcan.
Al contrario, pueden seguir descubriéndose nuevos problemas de seguridad que afecten a esas versiones.
Las soluciones de soporte extendido, como las que ofrece CloudLinux dentro de su ecosistema, permiten distribuir correcciones adaptadas a determinadas ramas antiguas.
De esta manera, una aplicación puede seguir funcionando con una versión compatible mientras se prepara su migración.
En HostingTG considero especialmente útil esta posibilidad cuando gestionamos alojamientos con necesidades técnicas diferentes.
Pero hay algo que debemos tener muy presente.
Hardened PHP no debe utilizarse como excusa para mantener indefinidamente aplicaciones obsoletas.
Aunque una versión antigua reciba determinadas correcciones, seguir utilizando software desactualizado puede implicar otros problemas de compatibilidad, mantenimiento y seguridad.
Mi recomendación es utilizar el soporte extendido como una medida de transición.
Nos ayuda a ganar tiempo para planificar correctamente una migración, pero no debería sustituir la modernización de las aplicaciones.
Cómo activar Hardened PHP en cPanel con Imunify360
Si administramos un servidor con cPanel y WHM que utiliza una instalación compatible de Imunify360, podemos gestionar Hardened PHP desde la propia interfaz de seguridad.
El procedimiento documentado por cPanel es el siguiente:
- Accedemos a WHM utilizando una cuenta con privilegios de administrador root.
- Entramos en Home → Plugins → Imunify360.
- Abrimos el apartado Settings.
- Localizamos la sección General.
- Buscamos la opción correspondiente a la instalación o desinstalación de Hardened PHP.
- Activamos la instalación cuando sea necesario y esté disponible para nuestra configuración.
- Comprobamos que se han instalado los paquetes correspondientes y verificamos las versiones de PHP utilizadas por las aplicaciones.
Es importante señalar que la disponibilidad de Hardened PHP depende del sistema operativo, las licencias, los repositorios y la compatibilidad del servidor.
Por ejemplo, la documentación de cPanel indica que Hardened PHP todavía no está disponible para determinadas instalaciones de Ubuntu con cPanel.
Por tanto, antes de activarlo, debemos comprobar que nuestro entorno cumple los requisitos del fabricante.
También conviene recordar que instalar Hardened PHP no garantiza que todas las cuentas del servidor estén utilizando automáticamente una versión corregida.
Debemos revisar qué versiones de PHP están asignadas a los diferentes dominios y confirmar que los paquetes correspondientes contienen los parches necesarios.
Este último paso es imprescindible.
No basta con activar una opción en el panel de control y asumir que el problema está resuelto.
Qué son los backports y por qué importa comprobar los parches
Hay un detalle técnico que puede generar bastante confusión cuando trabajamos con versiones antiguas de PHP.
Me refiero a los backports.
Un backport consiste en adaptar una corrección desarrollada para una versión más reciente de un programa y aplicarla a una versión anterior.
Esto permite solucionar una vulnerabilidad sin necesidad de incorporar todos los cambios existentes entre ambas versiones.
Es especialmente útil en servidores donde determinadas aplicaciones dependen de una versión concreta de PHP.
Con PHP2Shell, este procedimiento ha adquirido especial importancia.
Las correcciones oficiales se encuentran en PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12.
Sin embargo, algunos proveedores pueden distribuir paquetes que incorporan los mismos parches de seguridad sin modificar el número principal de la versión.
Por ejemplo, un paquete de PHP 8.4.26 distribuido por un proveedor podría incluir un backport de la corrección de seguridad, aunque la versión oficial corregida sea PHP 8.4.27.
Esto significa que mirar únicamente el resultado del comando php -v puede llevarnos a conclusiones equivocadas.
Para comprobar correctamente el estado de seguridad debemos revisar:
- La versión de PHP que realmente utiliza la página web.
- El proveedor del paquete instalado.
- La versión completa y revisión del paquete.
- Los registros de cambios y avisos de seguridad del proveedor.
- La presencia de los parches correspondientes a las dos vulnerabilidades.
Personalmente, considero que esta comprobación es fundamental cuando administramos servidores con diferentes versiones de PHP.
Una versión aparentemente antigua no tiene por qué seguir siendo vulnerable si incorpora los parches correctos, pero debemos poder demostrarlo.
Cómo proteger un servidor frente a PHP2Shell paso a paso
Cuando aparece una vulnerabilidad crítica, mi prioridad es determinar qué sistemas están afectados y aplicar las medidas necesarias de forma ordenada.
Prefiero seguir un procedimiento que permita identificar el problema, corregirlo y comprobar posteriormente que la solución está funcionando.
En un entorno de alojamiento web, donde pueden convivir decenas o cientos de aplicaciones, este enfoque resulta especialmente importante.
No debemos dar por hecho que actualizar una única versión de PHP protege automáticamente todo el servidor.
Identificar todas las versiones de PHP instaladas
El primer paso consiste en revisar qué versiones de PHP están disponibles y cuáles utilizan realmente las páginas web alojadas.
En un servidor Linux podemos comenzar ejecutando:
php -vEste comando muestra la versión de PHP disponible en la línea de comandos.
Sin embargo, hay un detalle importante: la versión utilizada por la consola no tiene por qué coincidir con la que utiliza una página web.
En servidores con cPanel es habitual encontrar distintas versiones gestionadas mediante EasyApache o herramientas equivalentes.
Por eso debemos revisar también las asignaciones de PHP de cada dominio mediante MultiPHP Manager, CloudLinux PHP Selector o el sistema correspondiente.
Si utilizamos PHP-FPM, también conviene identificar las versiones y servicios FPM activos.
En entornos con varias versiones instaladas, podemos revisar los paquetes disponibles y los procesos que están ejecutándose.
El objetivo es elaborar un inventario completo.
No debemos olvidar aplicaciones secundarias, subdominios, entornos de pruebas o instalaciones antiguas que siguen siendo accesibles desde Internet.
Desde mi experiencia, estos sistemas olvidados suelen ser precisamente los que terminan generando problemas de seguridad.
Aplicar las actualizaciones y parches de seguridad
Una vez identificadas las versiones afectadas, debemos instalar los paquetes corregidos.
Para las ramas oficiales de PHP, las primeras versiones que solucionan ambos fallos son:
- PHP 8.2.35.
- PHP 8.3.36.
- PHP 8.4.27.
- PHP 8.5.12.
Si utilizamos una distribución que incorpora sus propias correcciones de seguridad, debemos seguir las instrucciones de su proveedor.
Esto es especialmente importante en servidores con CloudLinux, Hardened PHP o paquetes distribuidos por el fabricante del panel de control.
No recomiendo sustituir manualmente los paquetes de PHP por otros procedentes de repositorios desconocidos.
Una modificación de este tipo puede provocar incompatibilidades, dependencias rotas o problemas con las actualizaciones posteriores.
Lo adecuado es utilizar los canales oficiales del entorno que estamos administrando.
En sistemas que emplean DNF, por ejemplo, podemos consultar los paquetes instalados y las actualizaciones disponibles utilizando las herramientas habituales de gestión de paquetes.
Antes de ejecutar cualquier actualización, conviene revisar qué componentes van a modificarse y disponer de copias de seguridad recientes.
En servidores de producción también debemos valorar las posibles interrupciones de servicio.
La prioridad es instalar los parches de seguridad cuanto antes, pero hacerlo de forma controlada.
Revisar Imunify360 y aplicar mitigaciones temporales
Mientras instalamos las actualizaciones, debemos comprobar que Imunify360 está funcionando correctamente.
Esto incluye revisar el estado del firewall, las actualizaciones de sus reglas de protección y los registros de actividad relacionados con posibles intentos de explotación.
Si todavía no podemos instalar los parches correspondientes, existen algunas mitigaciones temporales recomendadas por el equipo de seguridad de PHP.
Una de ellas consiste en desactivar el seguimiento del progreso de subida de archivos mediante la siguiente directiva:
session.upload_progress.enabled = OffEsta configuración reduce la exposición frente a determinadas técnicas relacionadas con CVE-2026-109619.
Sin embargo, no elimina completamente el riesgo ni corrige CVE-2026-109618.
También deben revisarse otras configuraciones relacionadas con los límites de memoria y el tamaño de las peticiones HTTP, siguiendo las recomendaciones específicas del proyecto PHP y del proveedor del servidor.
En este punto debemos tener especial cuidado.
Cambiar los límites de memoria o el tamaño máximo de las peticiones puede afectar al funcionamiento normal de determinadas aplicaciones.
Por ejemplo, una tienda online puede necesitar procesar archivos grandes, importar catálogos o realizar operaciones que consumen una cantidad considerable de memoria.
Por tanto, no conviene modificar estos valores indiscriminadamente.
Mi recomendación es evaluar cada cambio antes de aplicarlo y comprobar posteriormente que las aplicaciones continúan funcionando.
Y, sobre todo, recordar que estas medidas son temporales.
La solución definitiva sigue siendo instalar una versión de PHP que incorpore las correcciones de seguridad correspondientes.
Reiniciar los servicios PHP y verificar las correcciones
Hay un aspecto de las actualizaciones que muchas veces pasa desapercibido.
Instalar un paquete corregido no significa necesariamente que todos los procesos del servidor estén utilizando inmediatamente el código nuevo.
Algunos servicios pueden mantener procesos en memoria que todavía ejecutan componentes cargados antes de la actualización.
Por eso debemos reiniciar o recargar, según corresponda, los servicios PHP afectados.
En entornos con PHP-FPM, esto implica revisar los servicios y procesos asociados a cada versión instalada.
Si utilizamos Apache con mod_php, también debemos comprobar que el servicio web ha cargado las bibliotecas actualizadas.
Después del reinicio, resulta imprescindible verificar el resultado.
No basta con comprobar que el gestor de paquetes indica que la actualización se ha instalado correctamente.
Debemos confirmar que:
- Las versiones de PHP utilizadas por las páginas web corresponden a versiones corregidas o paquetes con los backports adecuados.
- Los servicios PHP están funcionando con los nuevos componentes.
- Las páginas web continúan respondiendo correctamente.
- Los registros del servidor no muestran errores inesperados.
- Imunify360 permanece activo y con sus protecciones actualizadas.
En servidores donde se alojan aplicaciones críticas, también conviene comprobar las funciones principales de cada sitio.
Por ejemplo, procesos de compra, formularios de contacto, accesos de usuarios, pasarelas de pago o tareas programadas.
Durante mi trayectoria administrando servidores he aprendido que una actualización no termina cuando finaliza el comando de instalación.
La actualización termina cuando hemos comprobado que la corrección está aplicada y que el servicio funciona correctamente.
Por qué la seguridad de un hosting debe comenzar en el servidor
Hay una reflexión que me gustaría compartir a raíz de todo lo ocurrido con PHP2Shell.
Durante muchos años se ha insistido en que los propietarios de páginas web deben mantener actualizados sus gestores de contenidos, plugins y temas.
Y estoy completamente de acuerdo.
Pero también considero importante recordar que existe una parte de la seguridad que el propietario de una página web no puede gestionar directamente.
Un cliente que utiliza WooCommerce para vender sus productos no tiene por qué saber cómo funciona internamente PHP-FPM.
Tampoco debería necesitar conocimientos sobre las diferencias entre mod_php y CGI, las reglas de ModSecurity o el funcionamiento de los backports de seguridad.
Para eso estamos los profesionales que administramos los servidores.
Las limitaciones de mantener únicamente WordPress y sus plugins actualizados
Mantener actualizado WordPress es una de las medidas de seguridad más importantes que puede aplicar el propietario de una página web.
Lo mismo ocurre con los plugins, las plantillas y cualquier otra aplicación instalada.
Estas actualizaciones permiten corregir vulnerabilidades conocidas y reducir muchos riesgos habituales.
Pero no resuelven los problemas de seguridad que se encuentran en el sistema operativo, el servidor web o el intérprete de PHP.
PHP2Shell demuestra precisamente esta diferencia.
Aunque todas las aplicaciones alojadas estén completamente actualizadas, una versión vulnerable de PHP puede seguir representando un riesgo para ellas.
Además, algunas vulnerabilidades pueden afectar a componentes compartidos por numerosas páginas web.
Por tanto, una única instalación vulnerable puede convertirse en un problema que exige actuar sobre una parte importante de la infraestructura.
Desde mi punto de vista, el cliente y el proveedor de hosting tienen responsabilidades complementarias.
El propietario de la página web debe preocuparse por mantener su aplicación actualizada, utilizar credenciales seguras y seguir buenas prácticas de administración.
Por su parte, el proveedor de alojamiento debe encargarse de mantener protegida la infraestructura bajo su responsabilidad.
Esto incluye instalar las actualizaciones de seguridad, revisar configuraciones, monitorizar amenazas y aplicar las correcciones necesarias cuando aparecen nuevas vulnerabilidades.
En definitiva, la seguridad de una página web no debería depender exclusivamente de lo que haga su propietario.
Prevención, monitorización y mantenimiento en HostingTG
En HostingTG llevamos más de veinte años trabajando con servidores y servicios de alojamiento web.
Durante este tiempo hemos visto evolucionar tanto las tecnologías que utilizamos como las amenazas a las que están expuestas.
Los ataques actuales son cada vez más automatizados y pueden aprovechar vulnerabilidades que afectan a componentes muy concretos del servidor.
Por eso defendemos una estrategia de seguridad basada en diferentes capas de protección.
Imunify360 es una de las herramientas que utilizamos en todos nuestros hostings porque nos permite contar con mecanismos adicionales de prevención y detección.
Pero no nos limitamos a instalar un software y olvidarnos del resto.
También consideramos fundamental el mantenimiento de los sistemas, la revisión de las actualizaciones y la administración activa de los servidores.
Hardened PHP y las soluciones de soporte extendido pueden desempeñar un papel importante cuando determinadas aplicaciones todavía necesitan versiones antiguas de PHP.
Las actualizaciones oficiales permiten corregir los fallos desde su origen.
Y la monitorización ayuda a identificar comportamientos que requieren atención.
Todo forma parte de una misma estrategia.
Porque la seguridad no consiste únicamente en reaccionar cuando aparece un problema.
También consiste en estar preparados para afrontarlo.
No podemos garantizar que nunca vuelva a descubrirse una vulnerabilidad crítica en PHP o en cualquier otro componente.
Lo que sí podemos hacer es reducir los riesgos, mantener la infraestructura y disponer de mecanismos para actuar con rapidez.
Y después de tantos años trabajando en HostingTG, sigo pensando que esa es una de las diferencias más importantes entre limitarse a ofrecer espacio en un servidor y proporcionar un servicio de alojamiento web administrado.
Imunify360, Hardened PHP y actualizaciones como estrategia conjunta
PHP2Shell nos ha recordado algo que quienes trabajamos administrando servidores conocemos bien: la seguridad de una página web depende de muchos más elementos que su propio código.
Una vulnerabilidad en el intérprete de PHP puede afectar a aplicaciones completamente actualizadas y poner en riesgo la infraestructura donde están alojadas.
Por eso considero fundamental abordar este tipo de problemas utilizando diferentes medidas de protección.
Imunify360 nos ayuda a detectar y bloquear determinados intentos de explotación.
Hardened PHP y los sistemas de soporte extendido permiten incorporar correcciones de seguridad a versiones antiguas que todavía necesitan algunas aplicaciones.
Y las actualizaciones oficiales o los paquetes corregidos del proveedor solucionan las vulnerabilidades en el propio intérprete.
No son soluciones alternativas entre las que debamos elegir una sola.
Son herramientas complementarias que forman parte de una estrategia de seguridad más completa.
En HostingTG llevamos más de veinte años trabajando con servidores y sabemos que las vulnerabilidades seguirán apareciendo.
Hoy hablamos de PHP2Shell, pero mañana puede surgir un problema diferente que afecte a otro componente del sistema.
Por eso seguimos apostando por combinar prevención, mantenimiento, monitorización y capacidad de reacción.
Porque, al final, la mejor seguridad no es la que promete que nunca ocurrirá nada, sino la que trabaja continuamente para reducir los riesgos y estar preparada cuando aparece una nueva amenaza.
Dudas de la comunidad
¿Imunify360 protege completamente contra PHP2Shell?
No. Imunify360 dispone de mecanismos de protección que pueden bloquear determinados intentos de explotación de PHP2Shell, pero no garantiza una protección absoluta.
Sus reglas de firewall ayudan a reducir el riesgo, especialmente mientras se aplican las actualizaciones correspondientes.
Sin embargo, las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 se encuentran en el propio intérprete de PHP.
La corrección definitiva consiste en instalar una versión que incorpore los parches de seguridad.
Mi recomendación es combinar Imunify360 con actualizaciones y monitorización, en lugar de depender exclusivamente del firewall.
¿Hardened PHP permite seguir utilizando versiones antiguas con seguridad?
Hardened PHP permite recibir determinadas correcciones de seguridad en versiones de PHP que ya no cuentan con soporte oficial.
Esto resulta especialmente útil para aplicaciones antiguas que todavía no pueden migrarse a versiones modernas.
Sin embargo, debemos comprobar que el proveedor ha publicado e instalado las correcciones necesarias para las vulnerabilidades concretas que queremos solucionar.
Además, utilizar una versión antigua con soporte extendido no debería interpretarse como una solución permanente.
Siempre que sea posible, recomiendo planificar la actualización de las aplicaciones para que puedan funcionar con versiones de PHP que sigan recibiendo mantenimiento oficial.
¿Cómo saber si mi proveedor de hosting ha corregido PHP2Shell?
Lo primero es comprobar qué versión de PHP utiliza realmente la página web.
Las primeras versiones oficiales que corrigen las dos vulnerabilidades son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12.
Si el alojamiento utiliza versiones anteriores, eso no significa necesariamente que continúe siendo vulnerable.
Algunos proveedores incorporan correcciones mediante backports sin modificar el número principal de la versión.
Por eso recomiendo consultar con el proveedor de hosting y solicitar confirmación de que los paquetes instalados incluyen los parches para CVE-2026-109618 y CVE-2026-109619.
También es importante confirmar que los servicios PHP se han reiniciado correctamente después de aplicar las actualizaciones.
¿Es suficiente actualizar WordPress para solucionar estas vulnerabilidades?
No.
PHP2Shell afecta al intérprete de PHP, no al núcleo de WordPress.
Por tanto, aunque WordPress, sus plugins y sus temas estén completamente actualizados, la página puede seguir expuesta si el servidor utiliza una versión vulnerable de PHP.
Para corregir el problema debemos instalar los parches correspondientes en el servidor.
Si utilizamos un alojamiento compartido, normalmente será el proveedor de hosting quien deba realizar esta operación.
Actualizar WordPress sigue siendo imprescindible, pero debe formar parte de una estrategia de seguridad que también incluya la infraestructura donde está alojado.
Opinión Personal
Después de más de veinte años trabajando en el sector del alojamiento web, hay algo que tengo muy claro: la seguridad de una página web no debería depender únicamente de que su propietario mantenga actualizado WordPress, PrestaShop o cualquier otra aplicación.
Vulnerabilidades como PHP2Shell demuestran que los problemas también pueden aparecer en el corazón del servidor, donde muchos usuarios ni siquiera tienen acceso para intervenir.
Por eso, en HostingTG siempre hemos defendido una estrategia de seguridad basada en la prevención y la protección por capas. Utilizar Imunify360 en todos nuestros hostings no significa que seamos inmunes a cualquier ataque, pero sí refleja nuestra manera de entender la seguridad: anticiparnos a los problemas siempre que sea posible y estar preparados para reaccionar cuando aparecen.
También considero que herramientas como Hardened PHP son especialmente valiosas para mantener protegidas aplicaciones que todavía necesitan versiones antiguas de PHP. Eso sí, nunca deberían convertirse en una excusa para dejar de actualizar.
Personalmente, creo que un buen proveedor de hosting no es simplemente quien ofrece servidores rápidos, mucho espacio o precios competitivos. Es quien también se preocupa por todo lo que ocurre detrás de las páginas web de sus clientes.
Porque las vulnerabilidades seguirán apareciendo. La verdadera diferencia estará en cómo nos preparamos para afrontarlas.
Y ahora me gustaría conocer tu opinión.
¿Crees que los proveedores de hosting deberían asumir un papel más activo en la seguridad de las páginas web? ¿Utilizas Imunify360, Hardened PHP u otras herramientas para proteger tus servidores? ¿Has tenido que enfrentarte alguna vez a una vulnerabilidad crítica de PHP?
Te leo en los comentarios. Me gustaría conocer tu experiencia y descubrir cómo afrontáis este tipo de amenazas, porque compartir conocimientos también es una excelente forma de mejorar nuestra seguridad.
