AlmaLinux ha incorporado a sus repositorios de producción los paquetes PHP que corrigen dos vulnerabilidades críticas denominadas colectivamente php2shell (CVE-2026-109618 y CVE-2026-109619). Las correcciones cubren todas las corrientes (streams) de PHP que distribuye la distribución en sus ramas 8, 9 y 10, y ya no es necesario habilitar el repositorio de pruebas para recibirlas.
Qué cambia y por qué importa php2shell
Las dos fallas permiten a un atacante no autenticado ejecutar código remoto en un servidor web que ejecute PHP, con los mismos permisos del proceso PHP. PHP evaluó ambas vulnerabilidades con una puntuación de riesgo muy alta (9.2 en CVSS v4.0). Los fallos se producen cuando PHP aborta una petición por falta de memoria en un punto en que el estado de la petición está sólo parcialmente inicializado; la limpieza posterior puede leer memoria ya liberada (use‑after‑free), lo que puede conducir a ejecución remota. PHP confirmó explotación completa contra mod_php (el módulo de Apache) y también demostró RCE vía PHP‑FPM en al menos una ruta de procesamiento (session upload progress).
Quiénes están afectados
- Todos los sistemas AlmaLinux 8, 9 y 10 que sirvan peticiones web con PHP y usen los paquetes de PHP de los repositorios oficiales están afectados.
- Instalaciones que usen mod_php (principalmente en AlmaLinux 8 si Apache se configuró con mpm_prefork) son las de mayor riesgo, porque PHP demostró explotación sin depender del código de la aplicación.
- PHP‑FPM también es susceptible; en este caso la explotación puede depender de que la aplicación ofrezca una operación que el atacante pueda forzar a fallar.
- Si PHP fue instalado desde otros proveedores (paneles de control, repositorios de terceros o binarios del proveedor de alojamiento), esas instalaciones deben consultar a su proveedor para conocer el estado de los parches.
Qué deben hacer los administradores (instrucciones prácticas)
- Actualizar los paquetes PHP desde los repositorios de AlmaLinux: ejecutar sudo dnf clean metadata && sudo dnf upgrade ‘php*’.
- Tras actualizar, reiniciar el servicio PHP correspondiente: para PHP‑FPM, sudo systemctl restart php-fpm; si usa mod_php en AlmaLinux 8, reinicie Apache con sudo systemctl restart httpd.
- Verificar que el sistema ejecuta las builds parcheadas comprobando el paquete instalado, por ejemplo con rpm -q php-common (o rpm -q php8.4-common para PHP 8.4 en AlmaLinux 10) y cotejándolo con las versiones parcheadas indicadas por AlmaLinux.
- Si habilitó el repositorio de pruebas (testing) para ayudar a verificar los paquetes, puede deshabilitarlo después de actualizar en entornos de producción.
Mitigaciones temporales y recomendaciones adicionales
Si no puede actualizar de inmediato, AlmaLinux señala que existen mitigaciones que reducen la exposición; no obstante, dada la criticidad y la posibilidad de ejecución remota, la recomendación prioritaria es aplicar los parches. Además, si su instalación utiliza streams de PHP que ya alcanzaron el fin de vida en RHEL (por ejemplo php:7.2, 7.3, 8.0 en ciertas ramas), AlmaLinux ha provisto backports de la corrección, pero advierte que futuras actualizaciones para streams retirados no están garantizadas: planifique migrar a una versión soportada.
Contexto técnico breve
Las correcciones upstream evitann que PHP aborte una petición en mitad de una operación crítica cuando se alcanza el límite de memoria por petición; en su lugar, el servidor detiene la petición en el siguiente punto seguro, evitando dejar punteros al estado de la petición que puedan ser usados tras liberar la memoria. Este cambio de comportamiento corrige la raíz del use‑after‑free que permitía la explotación.
AlmaLinux indica que la mayor parte de los mirrors sincronizan cada pocas horas, por lo que si el paquete parcheado no aparece de inmediato conviene reintentar pasado un rato.
Lee también:
- PHP publica parches de emergencia: actualice ya PHP 8.5, 8.4, 8.3 y 8.2 por dos fallos RCE críticos
- Atarim se incorpora como patrocinador Silver de MariaDB Foundation
Fuente: Blog on AlmaLinux
