En resumen: El repositorio Remi PHP ofrece versiones actuales de PHP para Fedora y la familia RHEL, bien como stream de módulo que sustituye el PHP del sistema, bien como Software Collection que instala varias versiones en paralelo. Las correcciones de PHP2Shell 8.2.35, 8.3.36, 8.4.27 y 8.5.12 se anunciaron allí el 22 de octubre de 2026. Compruebe cada versión instalada por separado y reinicie cada servicio correspondiente.
Por qué tantos servidores RHEL obtienen PHP de Remi
Las distribuciones empresariales como RHEL, AlmaLinux y Rocky Linux apuestan por una estabilidad larga. Entregan pocas ramas de PHP y las mantienen durante años. Pero muchas aplicaciones exigen versiones más nuevas que las que ofrece la distribución. Ahí interviene el repositorio de Remi Collet, un mantenedor de paquetes de PHP desde hace muchos años en el entorno de Fedora y RHEL.
Remi compila las versiones de PHP poco después de las versiones oficiales. Sobre PHP2Shell apareció en el blog del repositorio, el 22 de octubre de 2026, un artículo sobre las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12. En él se mencionan las dos vulnerabilidades críticas CVE-2026-109618 y CVE-2026-109619 y se recomienda con urgencia la actualización. Los avisos de seguridad de Red Hat no valen para estos paquetes; lo que Red Hat comunica para sus propios paquetes figura en el artículo RHEL, AlmaLinux y Rocky Linux: comprobar el parche de PHP.
Dos vías: stream de módulo o Software Collection
Según el blog de Remi, las compilaciones para Enterprise Linux desde la versión 8 están disponibles por dos vías. Cuál se use en su servidor determina cómo comprueba y reinicia.
| Vía | Repositorio | Efecto | Servicio típico |
|---|---|---|---|
Stream de módulo, por ejemplo php:remi-8.3 |
remi-modular | sustituye el PHP del sistema, una versión predeterminada | php-fpm |
Software Collection, por ejemplo php83 |
remi-safe | versión adicional en paralelo en una ruta propia | servicio propio por versión, por ejemplo php83-php-fpm |
| Paquetes de prueba y candidatas a versión | remi-modular-test, remi-test | versiones preliminares | no para producción |
Las Software Collections suelen estar bajo /opt/remi/phpXY y su configuración bajo /etc/opt/remi/phpXY. Es práctico para operar aplicaciones antiguas y nuevas en un servidor. Pero también es el motivo más frecuente de que una versión se pase por alto en la actualización.
Una indicación sobre la línea de comandos: las Software Collections no están automáticamente disponibles bajo el comando php. Según la configuración, las tareas cron y los scripts las invocan mediante un comando propio o una ruta completa. Por eso revise también crontabs y scripts de despliegue si quiere saber qué collection se usa para qué.
Comprobar el repositorio Remi PHP tras PHP2Shell
Los siguientes comandos son de solo lectura y muestran qué paquetes de Remi están instalados y en qué estado.
# Fuentes de paquetes activas: ¿está incluido remi-modular o remi-safe?
dnf repolist
# Stream de módulo activo para PHP
dnf module list --enabled php
# Paquetes base y Software Collections instaladas en paralelo
rpm -qa 'php-*' 'php[0-9][0-9]-php-*' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort
# Versión de cada collection instalada
for b in /opt/remi/php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done
En las ramas compatibles la situación es clara: si ahí figura 8.5.12, 8.4.27, 8.3.36 u 8.2.35 o posterior, la corrección está incluida. En Remi, el número de versión suele corresponder a la versión upstream, a diferencia de los paquetes de la distribución, que a menudo conservan su número antiguo.
Para las collections más antiguas como php81, php80 o php74 no hay versión de destino oficial. Remi da PHP 8.1 por fin de vida (End-of-Life). Si un paquete instalado contiene una corrección frente a PHP2Shell lo aclara en el registro de cambios, por ejemplo con rpm -q --changelog php81-php-fpm | grep -E "CVE-2026-10961[89]". Sin coincidencias, trate el paquete como no aclarado. Cómo acreditar bien esas coincidencias lo describe el artículo Acreditar números CVE en el registro de cambios del paquete.
No active de forma permanente repositorios de prueba como remi-test o remi-modular-test en servidores de producción. Ofrecen candidatas a versión, pensadas para pruebas.
Actualización y reinicio de cada versión
La actualización en sí suele ser poco llamativa en Remi: dnf upgrade trae paquetes nuevos para el stream y las collections. La parte crítica viene después. Cada collection tiene su propio servicio FPM, y cada uno debe reiniciarse.
# Listar todos los servicios PHP-FPM, también los de las collections
systemctl list-units --type=service --all | grep -E "php.*fpm"
# Comprobar las horas de inicio de todos los procesos de PHP
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Horas de inicio anteriores a la actualización significan: este servicio sigue funcionando con código antiguo. Por qué una recarga no basta lo explica la página Reiniciar PHP-FPM y todos los workers.
Remi y la distribución: ¿quién es responsable?
Quien cambia a Remi mediante un stream de módulo cambia de proveedor para PHP. Los avisos de seguridad de Red Hat, AlmaLinux o Rocky Linux ya no se refieren entonces a los paquetes de PHP instalados. Y al revés, Remi no comunica problemas en otros paquetes del sistema. Debe, pues, vigilar ambas fuentes.
De dónde procede un paquete instalado lo muestra la base de datos de paquetes, por ejemplo con rpm -qi php-fpm en los campos de fabricante y empaquetador. Como para los paquetes de Remi no hay errata en el sentido de Red Hat, el blog del repositorio sirve como vía de notificación; puede suscribirse mediante un feed RSS. En PHP2Shell, el aviso apareció allí un día después de las versiones oficiales.
Para las empresas, este reparto no es un obstáculo, pero debe estar documentado. Deje constancia de qué servidores obtienen PHP de Remi, quién lee los avisos y quién reinicia los servicios tras una actualización. De lo contrario, cada uno confía en el otro.
Mantener el orden: menos versiones, menos riesgo
Las Software Collections invitan a dejar las versiones antiguas sin tocar. Tras PHP2Shell es un buen momento para ordenar:
- Aclarar para cada collection qué sitio web o tarea cron la usa.
- Desactivar las collections no utilizadas y eliminarlas tras un periodo de observación.
- Llevar las aplicaciones en collections antiguas a una rama compatible.
- Documentar las versiones restantes con su finalidad y su responsable.
Cómo mantener la visión de conjunto con muchas versiones en paralelo lo describe el artículo Varias versiones de PHP en un servidor.
¿Cómo ayuda PHP SOS en concreto?
- Registramos todos los streams y collections de Remi en sus servidores y los asignamos a sitios web y tareas cron.
- Comprobamos el estado de PHP2Shell por versión mediante la versión del paquete y el registro de cambios.
- Aplicamos las actualizaciones, reiniciamos cada servicio y lo acreditamos con las horas de inicio de los procesos en el marco del servicio de parcheo de PHP.
- Las collections que ya no se necesitan las eliminamos de forma controlada tras acordarlo.
Preguntas frecuentes
¿Ha proporcionado Remi las versiones de PHP2Shell?
Sí. En el blog del repositorio se anunciaron el 22 de octubre de 2026 las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12, con la indicación de dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, y la recomendación urgente de actualizar.
¿Qué diferencia hay entre stream de módulo y SCL en Remi?
Con un stream de módulo sustituye el PHP del sistema por una versión de Remi; entonces hay una versión de PHP como predeterminada. Las Software Collections instalan otras versiones en paralelo en rutas propias, cada una con su propio servicio.
¿Recibe PHP 8.1 de Remi todavía actualizaciones?
Remi da PHP 8.1 por fin de vida (End-of-Life); el proyecto PHP ya no mantiene la rama. Si un paquete 8.1 concreto contiene una corrección frente a PHP2Shell, compruébelo en el registro de cambios del paquete instalado. Sin entrada, el estado se considera no aclarado.
¿Tengo que reiniciar cada versión de PHP tras una actualización de Remi?
Sí. Cada versión instalada en paralelo tiene su propio servicio FPM. Si solo se reinicia el servicio de la versión principal, las demás siguen funcionando con código antiguo.