PHP2Shell: nuestra respuesta de seguridad y lo que debes revisar en tu sitio web

En Imagina Colombia comenzamos a aplicar los parches disponibles desde los primeros lanzamientos para los entornos cPanel y, posteriormente, incorporamos las actualizaciones de CloudLinux a medida que estuvieron disponibles para cada entorno.

Ante las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell, queremos explicarte qué medidas hemos tomado, por qué algunos sitios seguían mostrando números de versión aparentemente antiguos y qué debes hacer si tu plataforma utiliza una versión legacy de iAdmin.

¿Qué es PHP2Shell?

Estas vulnerabilidades afectan a PHP, una tecnología utilizada por numerosos sitios y aplicaciones web. Bajo determinadas condiciones, pueden permitir que un atacante ejecute código de forma remota sin iniciar sesión.

El proyecto PHP publicó correcciones para sus ramas soportadas y los proveedores distribuyeron paquetes adaptados a sus entornos. Puedes consultar el aviso oficial de seguridad de PHP.

¿Qué hicimos en Imagina Colombia?

Nuestra respuesta se desarrolló conforme los proveedores liberaron sus actualizaciones:

1. Aplicamos los primeros parches disponibles para los entornos cPanel.
2. Posteriormente aplicamos las actualizaciones de CloudLinux, siguiendo la disponibilidad de paquetes para cada versión y sistema operativo.
3. Continuamos dando seguimiento a los avisos de los proveedores, para incorporar las correcciones correspondientes a nuestra infraestructura administrada.

Puedes revisar la evolución de los lanzamientos en el comunicado oficial de CloudLinux sobre estas vulnerabilidades.

La actualización del servidor es parte de la protección de nuestros servicios de hosting. Sin embargo, tu aplicación también necesita mantenerse dentro de un ciclo de soporte vigente.

¿Por qué veía una versión de PHP aparentemente sin parchear?

Algunos usuarios observaron versiones inferiores a las anunciadas por PHP y pensaron que la actualización no se había aplicado.

La explicación es que CloudLinux distribuyó inicialmente varias correcciones mediante backports: incorporó el arreglo de seguridad a sus paquetes existentes sin cambiar el número de versión base de PHP. La revisión del paquete sí puede cambiar.

Por eso, un número de versión antiguo no basta para concluir que falta el parche. La comprobación debe considerar el paquete completo, su revisión y el registro de cambios del proveedor. Algunos escáneres que solo comparan versiones pueden generar alertas sobre paquetes ya corregidos.

Si tienes dudas sobre una alerta, comparte con nuestro equipo el dominio y el resultado del análisis para revisar tu caso.

Versiones vulnerables y versiones corregidas de PHP

La siguiente tabla corresponde a las versiones oficiales de PHP y a estas dos vulnerabilidades. Un paquete con backport del proveedor puede estar corregido aunque muestre una versión inferior.

Fuente: avisos oficiales de PHP. El equipo de PHP también proporcionó parches mínimos de código fuente para 7.4, 8.0 y 8.1; esto no restablece su soporte oficial.

Ejemplos de backports confirmados por CloudLinux: alt-php85 8.5.11-5 y ea-php84 8.4.26-2.el8.cloudlinux.1 contienen las correcciones. Son ejemplos concretos de paquetes, no una declaración de que cualquier instalación de PHP 8.5.11 o 8.4.26 esté protegida. Consulta la tabla de paquetes corregidos y su verificación.

Si tienes un VPS o un servidor dedicado

Si administras tu propio servidor dedicado o VPS, debes comprobar e instalar las actualizaciones. No asumas que las medidas aplicadas a nuestro hosting administrado actualizan también un servidor bajo tu administración. Si contrataste administración con nosotros, solicita la validación de tu servidor.

1. Identifica todas las versiones y proveedores de PHP que sirven tus sitios, incluidos contenedores. El resultado de php -v solo identifica el PHP de consola y puede diferir del utilizado por tu web.
2. Realiza una copia de seguridad y programa una ventana de mantenimiento.
3. Instala los paquetes corregidos desde los repositorios de tu proveedor para todas las ramas utilizadas.
4. Reinicia los procesos PHP y los servicios web que correspondan a tu configuración para cargar los binarios actualizados.
5. Comprueba el PHP que atiende cada sitio y prueba el administrador, formularios y cargas de archivos.

CloudLinux con paquetes EasyApache o PHP Selector

Como administrador root, en CloudLinux 8, 9 o 10, actualiza las familias instaladas:

dnf clean all
dnf upgrade 'ea-php*' 'alt-php*'

En CloudLinux 7 utiliza:

yum clean all
yum update 'ea-php*' 'alt-php*'

En cPanel con Apache y PHP-FPM, reinicia los servicios correspondientes:

/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

Si utilizas LiteSpeed u otros servicios PHP, reinicia también los procesos que atienden tus sitios. Si no aparecen actualizaciones, revisa el paquete cloudlinux-release y los repositorios. En CloudLinux 10, otras versiones de alt-php aparte de 5.2 se distribuyen mediante el repositorio TuxCare ELS ALT PHP; conserva php-els habilitado si tu instalación lo utiliza. Sigue las instrucciones vigentes de CloudLinux.

Cómo comprobar un backport

Estos ejemplos consultan paquetes concretos; adapta el nombre a la rama instalada:

rpm -q alt-php85-common ea-php84-php-cli
rpm -q --changelog alt-php85-common | grep -E 'CVE-2026-(109618|109619)'
rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'

Contrasta la revisión completa y el registro de cambios con el aviso del proveedor. Un resultado vacío no demuestra por sí solo que falte el parche: algunos paquetes actualizados a las versiones oficiales registran el cambio de versión sin enumerar los CVE.

RunCloud, otras distribuciones y contenedores

Utiliza el mecanismo de actualización del proveedor que suministra PHP y confirma la versión realmente instalada en cada aplicación. Los comandos anteriores son para paquetes CloudLinux y no se deben trasladar a otros entornos. Si usas contenedores, actualiza la imagen que incorpora PHP y recrea los contenedores; actualizar únicamente el host no cambia su PHP interno.

Medida adicional mientras completas la actualización

PHP recomienda mantener desactivado el seguimiento de progreso de carga hasta su siguiente versión regular de correcciones:

session.upload_progress.enabled=0

Aplica el ajuste en php.ini o en una configuración de servidor o pool efectiva antes del procesamiento de la solicitud, y reinicia los procesos. No basta con ini_set() ni con .user.ini en PHP-FPM. Esta medida limita determinadas vías de ataque y no sustituye los paquetes corregidos. Consulta el aviso de PHP del 23 de octubre.

Atención: los sitios con iAdmin legacy necesitan actualizarse

Como informamos en nuestro comunicado sobre el soporte de plataformas legacy, las versiones antiguas de nuestras plataformas están fuera del soporte activo estándar.

Si tu sitio utiliza iAdmin anterior a la versión 3.x, es importante que solicites su actualización cuanto antes. Esto incluye proyectos antiguos que dependen de PHP inferior a 8 y que no pueden pasar a una rama moderna sin adaptar su código.

Estas plataformas no recibirán parches de aplicación dentro del mantenimiento estándar de iAdmin. Necesitan una actualización o migración del proyecto para recuperar una base tecnológica con soporte vigente.

Esto debe distinguirse de los parches del servidor: CloudLinux ofrece correcciones para determinadas ramas antiguas de PHP. Por tanto, utilizar PHP anterior a 8 no significa automáticamente que no exista un paquete corregido; tampoco significa que una aplicación antigua vuelva a tener soporte.

¿Cómo puedes identificar tu versión de iAdmin?

Ingresa al administrador y revisa la versión que aparece debajo del logotipo o en la información del sistema:

• Anterior a iAdmin 3.x: solicita una evaluación para actualizar o migrar.
• iAdmin 3.x: pertenece a la línea soportada; el estado de cada instalación debe revisarse según su mantenimiento.
• Acceso mediante /backend: corresponde a una plataforma legacy.
• Acceso mediante /iadmin: revisa también la versión; la dirección por sí sola no permite identificarla.

Encontrarás las indicaciones completas en el comunicado de soporte de iAdmin.

El firewall ayuda, pero no sustituye la actualización

Según el entorno donde esté alojado tu sitio, cuentas con una capa adicional de protección mediante Imunify360 o el WAF de RunCloud. Su cobertura depende de las reglas activas y de la configuración de cada servidor.

Estas herramientas ayudan a bloquear solicitudes maliciosas y patrones de ataque conocidos. No garantizan protección frente a todas las variantes ni corrigen el código vulnerable. Mantener una plataforma antigua detrás de un firewall no elimina la necesidad de actualizarla.

Actualiza tu plataforma o migra a una tecnología moderna

Si tu proyecto utiliza una versión legacy, podemos evaluar dos caminos:

• Actualizar la plataforma, adaptando el código y sus dependencias para utilizar una versión reciente y soportada de PHP. El objetivo debe ser la versión estable más reciente compatible, con pruebas antes del cambio en producción.
• Migrar a una arquitectura moderna, como Astro, que hemos utilizado en nuestros desarrollos más recientes. Según las funcionalidades del proyecto, permite construir sitios que no dependan de PHP para servir sus páginas.

Cambiar de tecnología también exige mantener sus componentes actualizados. La decisión debe responder a las necesidades de tu sitio, su contenido y sus integraciones.

Contacta al equipo de Imagina Colombia con tu dominio y la versión de iAdmin para evaluar la actualización o migración de tu proyecto. Si utilizas una versión anterior a 3.x, prioriza esta revisión.