En resumen: En RHEL, AlmaLinux y Rocky Linux comprueba el parche de PHP frente a PHP2Shell por tres vías: los avisos de seguridad de la distribución (dnf updateinfo), el registro de cambios del paquete (rpm -q --changelog) y la hora de inicio de los procesos de PHP. Red Hat da por afectados RHEL 7 a 10 y comunicó en la consulta que algunas actualizaciones están disponibles y otras en preparación. Tras la actualización vale: reiniciar por completo, no solo recargar.
Qué ha publicado Red Hat sobre PHP2Shell
Red Hat ha publicado sobre PHP2Shell el boletín de seguridad RHSB-2026-013. Lo consultamos el 25 de octubre de 2026. Los puntos más importantes para los administradores:
- Afectados están RHEL 10, 9, 8 y 7, así como los productos y contenedores basados en ellos con imágenes RHEL o UBI.
- RHEL 7 está afectado, según Red Hat, solo por CVE-2026-109619; el código de CVE-2026-109618 no estaría incluido allí.
- No afectados están los sistemas sin PHP o con PHP que no procesa peticiones HTTP no fiables.
- Actualizaciones: algunas estaban disponibles en la consulta y otras en preparación. El boletín no mencionó números de errata concretos, sino que remitía a las páginas de errata.
Red Hat valora CVE-2026-109618 con un método propio como «Important» y señala que las instalaciones estándar desde RHEL 8 usan PHP-FPM en lugar de mod_php. Es una clasificación, no una señal de tranquilidad. El proyecto PHP valora ambas vulnerabilidades con CVSS v4.0 9,2, y el BSI (Oficina Federal alemana para la Seguridad de la Información) recomienda la actualización inmediata.
AlmaLinux y Rocky Linux: la misma fuente, su propio ritmo
AlmaLinux y Rocky Linux recompilan sus paquetes a partir de las fuentes de Red Hat. Por eso las correcciones suelen llegar con el mismo contenido, pero en su propio momento y bajo sus propios avisos de seguridad. Una referencia a una errata de Red Hat no significa que el paquete esté disponible el mismo día en su derivado.
Lo decisivo es, por tanto, el nivel en su sistema. Compruébelo con las herramientas de gestión de paquetes y no con noticias o foros.
Fíjese además en si el servidor usa servidores espejo o fuentes de paquetes internas. En muchas empresas los servidores no obtienen sus actualizaciones directamente del fabricante, sino de un espejo interno o de una herramienta de administración. Si ese espejo no está actualizado, dnf no encuentra paquetes nuevos aunque hace tiempo que estén publicados.
Comprobar el parche de PHP en RHEL y derivados
Los siguientes comandos son de solo lectura. Los nombres de paquete valen para los paquetes de PHP de la distribución; los paquetes de fuentes de terceros como Remi se llaman en parte de otra forma.
# ¿Qué streams de PHP conoce el sistema y cuál está activo? (RHEL 8 y 9)
dnf module list php
# Paquetes de PHP instalados con versión y origen
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | sort
# ¿Hay avisos de seguridad sobre los CVE para este sistema?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
# ¿Figura la corrección en el registro de cambios del paquete instalado?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
dnf updateinfo muestra solo avisos de actualizaciones aún no instaladas; con --installed ve también las ya aplicadas. Un resultado vacío puede significar por tanto dos cosas: la actualización ya está dentro o aún no está publicada. La comparación con el registro de cambios lo aclara. Cómo conservar el resultado como justificante lo describe el artículo Acreditar números CVE en el registro de cambios del paquete.
Como en otras distribuciones empresariales, el paquete suele conservar su versión original de PHP; solo cambia el indicador de release. Un número más antiguo en php -v no es por eso señal de una corrección ausente. Indicaciones generales sobre la comprobación de versiones figuran en Comprobar correctamente la versión de PHP y el nivel de parcheo.
Reconocer el modo de ejecución correcto
Red Hat menciona los modos de ejecución predeterminados: desde RHEL 8, PHP funciona mediante PHP-FPM; en RHEL 7, como mod_php en el servicio de Apache httpd. Muchos servidores se desvían de esto, por ejemplo por paneles, fuentes de terceros o configuraciones antiguas.
| Sistema | Predeterminado según Red Hat | Reinicio tras la actualización |
|---|---|---|
| RHEL 8, 9, 10 y derivados | PHP-FPM | systemctl restart php-fpm |
| RHEL 7 | mod_php en httpd | systemctl restart httpd |
| Contenedores basados en RHEL o UBI | según la imagen | Reconstruir la imagen, sustituir el contenedor |
Para los contenedores, Red Hat recomienda reconstruir las propias imágenes tras las imágenes base actualizadas y sustituir los contenedores o pods en ejecución. Una actualización dentro del contenedor en funcionamiento no es una vía fiable.
Tras la actualización: reinicio y control
Red Hat subraya que una recarga no basta. Los workers existentes pueden conservar el estado afectado. Por eso reinicie cada servicio que carga PHP y compruebe el resultado:
# Mostrar servicios con bibliotecas obsoletas (dnf-utils o dnf-plugins-core)
needs-restarting -s
# Comparar la hora de inicio de los procesos de PHP con el momento de la actualización
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Para la configuración, Red Hat da una indicación práctica: php -i muestra los ajustes de la línea de comandos, no los del servidor web. Quien quiera comprobar si valores provisionales como session.upload_progress.enabled=0 rigen en el contexto web usa brevemente una página phpinfo protegida y la borra después. Qué más hay que tener en cuenta en el reinicio figura en Reiniciar PHP-FPM y todos los workers.
Medidas provisionales: las indicaciones de Red Hat
Donde aún falta una actualización, Red Hat remite a las mismas medidas provisionales que php.net y añade algunas indicaciones prácticas para sistemas RHEL. No sustituyen la actualización.
- Añadir realmente la línea: según Red Hat, la línea de
session.upload_progress.enabledestá comentada en la configuración entregada, es decir, la función está activa por defecto. El valor0debe fijarse expresamente. - Fijar de forma no sobrescribible: mediante
php_admin_valueen el pool de PHP-FPM y, con mod_php, en la configuración de Apache. No medianteini_set()ni.user.ini. - Buscar a los adversarios: Red Hat recomienda revisar los archivos
.htaccess, los VirtualHosts y los archivos.user.inipor si vuelven a activar los ajustes afectados. - Fijar límites también antes: además de
post_max_sizeen PHP, Red Hat aconseja considerar límites para el tamaño de las peticiones también en el servidor web o el proxy.
En los sistemas con PHP-FPM, los pools suelen estar en /etc/php-fpm.d/. Tras cada cambio vale lo mismo que tras la actualización: reiniciar por completo todos los workers.
Si en el mismo servidor funciona además PHP del repositorio Remi, valen para él paquetes y servicios propios. Lea al respecto el artículo El repositorio Remi.
¿Cómo ayuda PHP SOS en concreto?
- En RHEL, AlmaLinux y Rocky Linux comprobamos todos los paquetes de PHP, streams y fuentes de terceros y los contrastamos con los avisos de seguridad.
- Aplicamos las actualizaciones, reiniciamos por completo todos los workers y controlamos las horas de inicio de los procesos.
- En entornos de contenedores reconstruimos imágenes y sustituimos de forma controlada las instancias en ejecución.
- El estado de cada servidor lo recogemos en el justificante del servicio de parcheo de PHP.
Preguntas frecuentes
¿Está RHEL 7 afectado por PHP2Shell?
Según Red Hat, RHEL 7 solo está afectado por CVE-2026-109619; el código vulnerable de CVE-2026-109618 no existe allí. En RHEL 7, mod_php es el modo de ejecución predeterminado, que el equipo de PHP califica de especialmente arriesgado.
¿Por qué Red Hat valora la vulnerabilidad más baja que php.net?
Red Hat usa una valoración propia según CVSS v3.1 y clasifica CVE-2026-109618 como Important, porque la explotación requeriría un momento exacto. php.net valora con CVSS v4.0 9,2. Ambos consideran posible la ejecución de código sin autenticación; la actualización es necesaria en cualquier caso.
¿Reciben AlmaLinux y Rocky Linux las correcciones automáticamente?
Ambas recompilan sus paquetes a partir de las fuentes de Red Hat y publican sus propios avisos de seguridad. El momento puede diferir del de Red Hat. Por eso compruebe el nivel en su propio sistema y en los avisos de su distribución.
¿Basta systemctl reload php-fpm tras la actualización?
No. Red Hat advierte expresamente de que una recarga no basta, porque los workers existentes pueden conservar el estado afectado. Reinicie todos los workers y, con mod_php, el servicio Apache httpd.