Introducción
La confirmación de la explotación activa de las vulnerabilidades PHP2Shell por parte de la CISA marca un punto de inflexión crítico para los equipos de infraestructura y seguridad. No se trata de una advertencia teórica; los honeypots han registrado ejecución remota de código (RCE) real, incluyendo la divulgación de memoria usable para derivar direcciones de funciones en payloads de ejecución. El riesgo es alto y la ventana de tiempo para las agencias federales, que sirve como indicador de urgencia para el sector privado, es mínima.
El problema concreto radica en que estas fallas permiten RCE no autenticado en despliegues de PHP afectados, específicamente en configuraciones de un solo worker con mod_php, aunque el alcance potencial es mucho mayor debido a la naturaleza de la vulnerabilidad subyacente en la librería Brotli. Este artículo proporciona los pasos exactos para parchear PHP en Linux y Windows, y verificar la integridad de servicios relacionados como Envoy e Istio, que también han emitido parches críticos derivados del mismo defecto en la decodificación de Brotli.
Qué es y para qué sirve
Las vulnerabilidades identificadas como PHP2Shell (y variantes como Broccoli2Shell, HTTP2Shell y Node2Shell) afectan a múltiples componentes de la pila de software moderna. La causa raíz es un defecto de escritura fuera de límites (out-of-bounds write) en la biblioteca de decodificación de Brotli, catalogado bajo CVE-2026-111497. Esta falla permite que un atacante envíe datos manipulados que corrompan la memoria del proceso servidor, derivando en la ejecución de código arbitrario.
En el contexto de PHP, estas vulnerabilidades tienen una puntuación CVSS de 9.2. La explotación ha sido confirmada en entornos donde la extensión cURL está habilitada con descompresión automática de respuestas HTTP mediante Brotli. Aunque esta función está deshabilitada por defecto en cURL, muchas aplicaciones de terceros y librerías de cliente HTTP la activan implícitamente, exponiendo los servidores a ataques. La confirmación de CISA en el catálogo KEV (Known Exploited Vulnerabilities) eleva esto de una «parche recomendado» a una «parche obligatorio inmediato».
La gravedad se amplifica porque la misma vulnerabilidad en la librería C de Brotli afecta a otros ecosistemas. Node.js, Bun, Envoy Proxy, Istio, .NET y Python han recibido parches o actualizaciones de dependencias para mitigar este riesgo. Para un equipo de DevOps, esto significa que la superficie de ataque no se limita a los servidores web tradicionales, sino que incluye mallas de servicio, proxies de borde y microservicios escritos en lenguajes que dependen de implementaciones vulnerables de Brotli.
Prerequisitos
Para ejecutar esta guía de mitigación, necesitas acceso root o sudo a los servidores afectados y conocimiento básico de los sistemas de gestión de paquetes de tu distribución Linux o PowerShell en Windows. Asegúrate de contar con las siguientes versiones mínimas de software antes de comenzar, ya que los parches disponibles son específicos:
- PHP: Versión 8.5.12, 8.4.27, 8.3.36 o 8.2.35 (o superior).
- Brotli Library: Versión 1.0.10, 1.1.1 o 1.2.1 (o superior).
- Accesos: Credenciales de administrador para actualizar paquetes del sistema.
- Monitoreo: Acceso a logs de aplicación y sistema para verificar la estabilidad post-parche.
Es crucial identificar primero qué versiones están corriendo. En Linux, ejecuta php -v para confirmar la versión actual. En contenedores, revisa la imagen base. Si estás utilizando Envoy o Istio, verifica las versiones de los sidecars y del plano de control, ya que estos también requieren actualización de sus dependencias internas de Brotli.
Guía paso a paso
Paso 1: Identificación rápida de vulnerabilidad
Antes de parchear, verifica si tu sistema es vulnerable comprobando la versión de PHP y la configuración de cURL. La vulnerabilidad es explotable si PHP está dentro del rango afectado y la descompresión Brotli está activa en las llamadas HTTP salientes.
# Verificar versión de PHP
php -v
# Verificar si la extensión cURL está habilitada y su configuración de descompresión
php -i | grep -i "curl.*brotli"
# En sistemas Linux, verificar la versión de la librería Brotli instalada
ldconfig -p | grep brotli
dpkg -l | grep libbrotli # Debian/Ubuntu
rpm -qa | grep brotli # RHEL/CentOSEl resultado esperado mostrará una versión de PHP inferior a las parcheadas (ej. 8.3.35) y, posiblemente, referencias a libbrotli en versiones 1.0.3 a 1.0.9 o 1.1.0. Si curl.*brotli devuelve on o valores de soporte, el riesgo de RCE es inmediato.
Paso 2: Parcheo de PHP en Linux
La mitigación principal es actualizar PHP a las versiones seguras. Dado que PHP no siempre se actualiza a través del repositorio estándar del sistema operativo debido a las políticas de distribución, es probable que necesites repositorios especializados como Remi (CentOS/RHEL/Fedora) o PPA (Ubuntu).
Para distribuciones basadas en Debian/Ubuntu, la actualización directa del paquete php suele ser suficiente si el repositorio está actualizado. Sin embargo, para garantizar la versión exacta parcheada, verifica primero el changelog.
# Actualizar índices de paquetes
sudo apt update
# Instalar la versión parcheada específica (ejemplo para PHP 8.2)
# Ajusta el número de versión según la guía de tu distribución
sudo apt install php8.2=8.2.35-0ubuntu0.22.04.1
# Reiniciar el servicio web para aplicar los cambios
sudo systemctl restart apache2
# O si usas Nginx con PHP-FPM
sudo systemctl restart php8.2-fpmPara CentOS/RHEL con Remi, el comando es más directo para obtener la última versión estable:
sudo dnf update php
sudo systemctl restart httpdEl resultado esperado es que php -v muestre la nueva versión (ej. 8.2.35) y que el servicio web reinicie sin errores.
Paso 3: Parcheo de PHP en Windows
El PHP Foundation ha liberado builds de Windows específicos (8.5.12-1, 8.4.27-1, etc.) que incluyen la corrección para CVE-2026-111497. No basta con actualizar el binario de PHP; debes asegurarte de que la DLL de Brotli asociada también sea la versión corregida.
Descarga el build correcto desde el sitio oficial de PHP para Windows. Reemplaza los archivos en tu directorio de instalación de PHP. Es crítico respaldar el directorio ext y el archivo php.ini antes de sobrescribir.
# Detener el servicio IIS o Apache
Stop-Service W3SVC -Force
# Copiar los nuevos archivos (ejemplo conceptual, ajusta rutas)
Copy-Item "C:\Temp\php-8.2.35-nts-Win32-VC16-x64\*" -Destination "C:\php\" -Recurse -Force
# Reiniciar el servicio
Start-Service W3SVCVerifica la versión en la consola de comandos de Windows ejecutando php -v. El resultado esperado debe indicar la versión 8.2.35-1 o superior.
Paso 4: Mitigación en Envoy e Istio
Dado que Envoy y Istio dependen de la librería Brotli vulnerable para la negociación de contenido, actualizar PHP no es suficiente si tienes una malla de servicio. Envoy Proxy ha lanzado parches para las versiones afectadas. Si utilizas Istio, debes actualizar el sidecar y el plano de control.
Para Istio, la estrategia recomendada es realizar un rollout de la actualización del proxy.
# Verificar versión actual de Istio
istioctl version
# Actualizar el plano de control a una versión parcheada
istioctl upgrade --set profile=default --set values.global.tag=1.20.2
# (Nota: Ajusta la versión al parche específico que incluya la corrección de Brotli)
# Forzar el reinicio de los sidecars para que carguen la nueva imagen
kubectl rollout restart deployment -n istio-system istiod
kubectl rollout restart deployment -n <namespace> <deployment-name>El resultado esperado es que los pods de la aplicación terminen y reinicien con la nueva imagen de proxy Istio, que ya no contendrá la versión vulnerable de Brotli.
Consideraciones y buenas prácticas
La confirmación de CISA indica que los exploits son funcionales y están siendo utilizados. No asumas que tu aplicación está segura porque no usas directamente curl con Brotli en tu código PHP. Muchas librerías de cliente (como Guzzle en PHP o requests en Python) pueden habilitar la descompresión de forma transparente o mediante configuraciones globales. Revisa tus dependencias de terceros.
Un error común es ignorar los entornos de desarrollo y staging. Los atacantes a menudo escanean rangos de IP completos; si un entorno de desarrollo está expuesto a internet y ejecuta PHP vulnerable, puede ser el punto de entrada para comprometer la red interna. Asegúrate de que la política de parcheo se aplique a todos los entornos, no solo a producción.
Además, aunque el parche mitiga la vulnerabilidad de RCE, debes considerar la desactivación de funciones innecesarias. Si no utilizas la descompresión Brotli en tus clientes HTTP, desactívala explícitamente en la configuración de cURL o en las librerías de aplicación. Esto reduce la superficie de ataque incluso si olvidas aplicar un parche futuro.
Finalmente, monitorea los logs de error de PHP y de los proxies (Envoy/Nginx) después del parche. Cambios en las bibliotecas de descompresión pueden ocasionalmente causar errores de contenido no decodificado si hay inconsistencias de versión entre el cliente y el servidor. Mantén un plan de rollback preparado si detectas regresiones funcionales críticas, aunque la seguridad debe tener prioridad dada la naturaleza crítica de la falla.
Conclusión
La explotación activa de PHP2Shell representa una amenaza inminente para cualquier infraestructura que dependa de PHP o de librerías de decodificación Brotli vulnerables. La velocidad de la confirmación de RCE por parte de la comunidad de seguridad y la inclusión en el catálogo KEV de CISA dejan claro que la mitigación inmediata es la única opción responsable.
Al seguir esta guía, has actualizado los componentes críticos de PHP y has verificado la postura de seguridad de tus servicios de malla y proxy. Sin embargo, la seguridad no es un evento único. Implementa automatización para escanear versiones de paquetes en toda tu flota de servidores y contenedores. Herramientas como Snyk, Trivy o los escáneres nativos de tu nube pueden alertarte proactivamente sobre vulnerabilidades conocidas, permitiendo una respuesta antes de que los exploits públicos sean masivos.
Fuentes
https://thehackernews.com/2026/10/cisa-confirms-active-exploitation-of.html