PHP publicó parches para dos vulnerabilidades críticas que permiten ejecución remota de código sin autenticar. CloudLinux confirma que los paquetes PHP corregidos ya se han publicado en sus repositorios estables para las versiones afectadas y que las instalaciones protegidas por Imunify360 reciben reglas WAF que ofrecen mitigación inmediata.
Qué cambia y qué ofrece CloudLinux
Las versiones oficiales de PHP con corrección son 8.5.12, 8.4.27, 8.3.36 y 8.2.35; PHP recomienda actualizar como única solución completa. CloudLinux ha publicado paquetes corregidos en las ramas que mantienen: ea-php (paquetes para cPanel EasyApache 4), alt-php (versiones alternativas empaquetadas por CloudLinux) y los paquetes nativos del sistema. En muchos casos los fixes se han incluido como backports, por lo que el número de versión del paquete del proveedor puede no coincidir exactamente con el de PHP.net.
Imunify360: mitigación en el borde
Imunify360 ha desplegado nuevas reglas WAF que llegan automáticamente a los servidores con el servicio habilitado. La ruleset 8.88 introduce un bloqueo específico (ID 77049357) que detiene objetos PHP serializados en el campo de progreso de subida sin tener en cuenta el Referer; versiones anteriores (8.84–8.86) ya añadieron otras reglas para detectar variantes del exploit.
Estas reglas actúan como un parche virtual: filtran patrones de petición conocidos en la capa de aplicación (ModSecurity/Coraza y LiteSpeed) y pueden impedir algunos vectores de ataque mientras el código vulnerable siga en el servidor. Sin embargo, Imunify360 no cubre todas las variantes (por ejemplo, aún no bloquea la ruta por falta de memoria descrita para CVE-2026-109618) y no sustituyen la actualización de PHP.
A quién afecta y qué debe hacer el administrador
- Servidores con PHP en cualquiera de las ramas mencionadas: actualizar PHP a la versión corregida correspondiente para su rama (8.5.12, 8.4.27, 8.3.36 o 8.2.35) o instalar el paquete parcheado del proveedor.
- Entornos con múltiples versiones de PHP (común en hosting compartido): actualizar cada versión activa que sirva sitios y reiniciar PHP-FPM o el servidor web para cargar los binarios nuevos.
- Servidores con Imunify360: comprobar que la ruleset ha llegado (8.88 o superior). En hosts con WAF habilitado la regla se instala automáticamente; confirme leyendo el fichero VERSION de las reglas como root o consultando la documentación de Imunify360 para la ruta correspondiente a su panel (cPanel/Plesk/DirectAdmin/LiteSpeed).
Si tras aplicar las reglas de Imunify360 un formulario legítimo de subida deja de funcionar (por ejemplo, subidas desde otro dominio o navegadores que eliminan el Referer), contacte con soporte, ya que la regla puede bloquear casos válidos.
Notas prácticas y medidas temporales
- Si añadió el repositorio ELS alt-php como solución temporal, puede desactivarlo ahora y actualizar desde los repositorios estándar de CloudLinux.
- Algunos paquetes incluyen el fix como backport y mantienen números de versión inferiores a los de PHP.net. Si un scanner solo compara números, verifique el changelog del paquete para confirmar la presencia de las entradas con los CVE.
- Si no puede actualizar inmediatamente, siga las mitigaciones parciales indicadas por PHP: por ejemplo, desactivar el progreso de subida (setting upload progress a 0) en php.ini o en la configuración del pool FPM que aplique antes del parseo de la petición, y reiniciar los workers. Estas medidas reducen la exposición pero no garantizan seguridad completa.
- Si una actualización no encuentra paquetes, confirme que el paquete cloudlinux-release está actualizado, limpie la caché del gestor de paquetes y vuelva a intentar la actualización.
Conclusión
La recomendación práctica es clara: actualizar PHP en todos los servidores que ejecuten las versiones afectadas y reiniciar los servicios PHP/web. Imunify360 aporta una defensa adicional en el borde, pero no sustituye la instalación de los parches oficiales. Compruebe los changelogs de los paquetes y la versión de la ruleset WAF para confirmar que la mitigación está aplicada.
Lee también:
- Vulnerabilidad php2shell en PHP 7.4: Ubuntu 20.04 Pro y proveedores de hosting han aplicado parches
- PHP2Shell: qué deben comprobar los administradores de QNAP, Nextcloud y OPNsense
Fuente: CloudLinux
