PHP: entiende las fallas de seguridad y actualiza tu servidor

El 21 de octubre de 2026, el proyecto PHP publicó correcciones para dos vulnerabilidades críticas. Si administras un sitio en PHP, conviene hacer espacio en la agenda para actualizarlo. Pero antes de pegar comandos, vamos a entender el problema y organizar el mantenimiento sin convertir la prisa en otro incidente.

¿Quién debe prestar atención?

La alerta de PHP abarca instalaciones que atienden solicitudes web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Las correcciones oficiales están en 8.2.35, 8.3.36, 8.4.27 y 8.5.12, o versiones posteriores de cada serie. Ambas fallas pueden permitir ejecución remota sin autenticación. Alerta oficial de PHP.

Esto incluye el PHP que utilizan WordPress, Laravel, tiendas virtuales y aplicaciones propias. Actualizar solo los plugins o el framework no sustituye la corrección del intérprete. Por otro lado, tener Apache o Nginx instalado sin ejecutar PHP no sitúa ese servicio dentro del alcance de estas dos fallas.

“Ejecución remota” significa conseguir que un proceso ejecute código elegido por un atacante. El impacto depende de los permisos y del aislamiento del entorno; no implica automáticamente acceso root.

Las dos vulnerabilidades, sin complicaciones

CVE-2026-109618: al agotarse la memoria, la inicialización puede detenerse en un estado inválido. La corrección hace segura esa ruta. Se demostró explotación en mod_php antes del código del sitio; PHP-FPM es susceptible, pero ese exploit completo no se demostró allí. Detalles técnicos.

CVE-2026-109619: un proceso reutilizado puede conservar referencias a memoria de una solicitud anterior y acceder a ella después de liberarla. La corrección limpia ese estado. La explotación depende de condiciones de aplicación/configuración; las rutas documentadas incluyen mod_php y sesiones en PHP-FPM. Detalles técnicos.

Cómo actualizar AlmaLinux 9 con cPanel

El procedimiento siguiente es para AlmaLinux 9 con cPanel/WHM y EasyApache 4. Ejecuta los comandos como root o con los privilegios administrativos adecuados. No los copies en Ubuntu, instalaciones sin cPanel o servidores que utilicen otro proveedor de PHP.

1. Prepara el terreno

Comprueba que tienes una copia de seguridad reciente de archivos, bases de datos y configuración, con un procedimiento conocido de restauración. Reserva una ventana de mantenimiento y asegúrate de poder acceder a la consola del proveedor si se corta SSH.

En MultiPHP Manager, identifica la versión asignada a cada dominio y el uso de PHP-FPM. Enumera también las tareas programadas, colas y aplicaciones con configuración propia. Ejecutar php -v en la terminal no demuestra qué PHP atiende todos los sitios.

Evita mezclar este parche urgente con un cambio de serie, como pasar de 8.2 a 8.5. Aplica primero la corrección disponible; planifica y prueba las migraciones por separado.

2. Comprueba el paquete corregido

EasyApache 4 registró las correcciones y backports para ea-php74, ea-php80 y ea-php81. Un backport aplica la corrección a una serie antigua sin cambiar su número principal. Esto no garantiza soporte para todo PHP obsoleto; comprueba el paquete que ofrece tu repositorio. Registro de cambios de cPanel.

Anota las versiones y revisiones (builds) de los paquetes instalados y compáralas con el boletín del proveedor. Si no aparece la corrección, investiga los repositorios, las exclusiones y la disponibilidad con soporte. “Nada que hacer” no confirma la protección.

3. Revisa la transacción antes de instalar

El filtro ea-php* no cubre alt-php, contenedores ni binarios PHP instalados por separado; actualízalos mediante sus proveedores correspondientes.

Actualiza los metadatos y pide a DNF que muestre su propuesta, rechazando automáticamente la ejecución, según las opciones de DNF:

dnf --refresh upgrade 'ea-php*' --assumeno

Comprueba los paquetes, dependencias, versiones y posibles eliminaciones. El * va entre comillas para que lo interprete DNF, no el shell. Si aparece un conflicto, una eliminación inesperada o un cambio de proveedor, detente e investiga. No fuerces la transacción a ciegas.

Una vez revisada la propuesta, ejecuta:

dnf --refresh upgrade 'ea-php*'

Lee de nuevo el resumen y confirma solo si es correcto. El comando omite -y precisamente para mantener esa revisión. Espera a que termine y comprueba si hubo errores; una finalización correcta suele mostrar Complete!.

4. Asegúrate de que el nuevo PHP está funcionando

Tener el paquete instalado no basta si siguen activos procesos antiguos. cPanel puede reiniciar servicios automáticamente, pero comprueba el resultado. Para buscar servicios desactualizados sin reiniciarlos:

/usr/local/cpanel/scripts/find_outdated_services --never-restart

Este comando es de diagnóstico, no una orden para reiniciarlo todo. Documentación del script.

Identifica los procesos PHP y servicios involucrados. Si quedan workers antiguos, recarga o reinicia solo los servicios necesarios mediante el procedimiento adecuado para tu entorno, teniendo en cuenta la interrupción. No supongas que una lista vacía sustituye la comprobación de la versión que realmente utiliza la aplicación.

Comprueba los paquetes corregidos, el PHP de cada sitio y los servicios activos. Prueba el inicio de sesión, páginas importantes, formularios, tareas cron y colas. Revisa los logs después del mantenimiento. Actualizar solo PHP no exige automáticamente reiniciar todo el servidor; otras actualizaciones pueden tener requisitos propios.

¿Y en otros entornos?

• Linux sin cPanel: utiliza los paquetes y el procedimiento del proveedor de tu instalación. Confirma la corrección o el backport en su boletín; comparar solo el número principal puede resultar engañoso.
• Contenedores: obtén una imagen PHP corregida, reconstruye cuando sea necesario y vuelve a desplegar. Comprueba también las réplicas que siguen en ejecución.
• Hosting compartido: solicita al proveedor la confirmación de la corrección y de la versión que utiliza realmente tu dominio.
• PHP sin soporte: busca una corrección mantenida explícitamente por el proveedor y planifica la migración. No supongas que todas las versiones antiguas recibieron un parche.

Por último, un WAF y las reglas del firewall son capas adicionales, no sustitutos de la actualización. Aplicar el parche tampoco demuestra que nunca hubo una intrusión. Si encuentras señales sospechosas, conserva los logs e investiga más allá del mantenimiento.

En la práctica: comprueba el entorno, ten una copia de seguridad, revisa la actualización y valida después los sitios y procesos. La seguridad mejora cuando la actualización termina con una verificación, no solo cerrando la terminal.

Fuentes consultadas el 21 de octubre de 2026.