Respuesta urgente a PHP2Shell: dos vulnerabilidades PHP RCE críticas con CVSS 9,2

Qué ocurrió

PHP corrigió dos fallos críticos del núcleo del intérprete que pueden permitir ejecución remota de código sin autenticación. Son independientes del framework y afectan a todos los SAPI que atienden solicitudes: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed.

CVE-2026-109618 aprovecha una salida por falta de memoria mientras la memoria de la solicitud está parcialmente inicializada; el shutdown puede tratar estado corrupto como válido. CVE-2026-109619 es un use-after-free entre solicitudes: un valor global puede apuntar a memoria liberada de una solicitud anterior.

Versiones afectadas

PHP 8.2 a 8.5 tienen versiones oficiales corregidas. PHP 8.1 y anteriores están EOL aguas arriba. PHP proporcionó backports mínimos de código fuente para 7.4, 8.0 y 8.1, pero no nuevas versiones binarias oficiales.

Por qué actualizar la aplicación no basta

Las rutas de ataque se ejecutan durante la inicialización, análisis o limpieza de la solicitud PHP, antes del código de la aplicación. Actualizar WordPress, Drupal, Joomla, Laravel o un plugin de seguridad no sustituye la actualización de PHP.

• PHP considera mod_php el mayor riesgo: una solicitud no autenticada puede atacar antes del código de aplicación.
• PHP-FPM no debe considerarse seguro. El análisis del código respalda la exposición y el fallo relacionado se demostró en mod_php y FPM.
• Instalar un paquete no completa la corrección si workers antiguos de FPM, Apache, IIS o CLI siguen ejecutando el binario anterior.
• Docker exige una imagen nueva y recrear el contenedor; docker restart solo reinicia la imagen antigua.

Cómo revisamos el parque

Un escáner pasivo inventarió CLI, FPM, CGI, módulos Apache, Docker, servicios Windows, extensiones y valores INI. Después verificamos el runtime detrás de cada entrada web real en lugar de confiar en un único php -v.

• Revisar PATH, /www/server/php, /usr/local, /opt, pools FPM, Apache, IIS FastCGI, registro y contenedores.
• Comparar la instalación de paquetes con la hora de inicio de los workers para encontrar parches instalados pero no activos.
• Banner oculto, CDN o WAF reducen exposición, pero no demuestran que el origen esté corregido.
• Dispositivos, NAS, paneles y PHP embebido requieren avisos específicos del fabricante.

Secuencia segura de reparación

La actualización de PHP es la única corrección completa. Esta secuencia se aplica a Linux y Windows Server, incluidos BT panel, IIS y contenedores.

• Crear un snapshot completo en cloud o hipervisor y registrar PHP, SAPI, extensiones, servicios y pools.
• Respaldar el directorio PHP, php.ini, configuración FPM/Apache/IIS y binarios; verificar el script de rollback.
• Instalar la versión oficial de la misma rama o un paquete de distribución marcado explícitamente como corregido en su aviso CVE.
• En Docker, descargar la imagen nueva y recrear el contenedor. Tras un paquete, reiniciar completamente FPM, Apache, IIS y workers PHP persistentes.
• Probar login, subidas, pagos, colas, caché y APIs críticas, y confirmar la versión del SAPI web real.
• Si el host estuvo expuesto a Internet antes del parche, buscar webshells, procesos hijos anómalos, tareas nuevas, conexiones salientes y acceso a credenciales.

Si no es posible aplicar el parche de inmediato

La configuración bloquea solo rutas conocidas y no hace que PHP sea seguro. El parche y un reinicio completo de todos los workers siguen siendo la única corrección completa.

• CVE-2026-109618: imponer memory_limit=-1 donde la aplicación no pueda sobrescribirlo, reducir post_max_size y limitar en el proxy tamaño del cuerpo, partes, cabeceras y anidamiento. No usar RLIMIT_AS o RLIMIT_DATA en su lugar.
• CVE-2026-109619: definir session.upload_progress.enabled=0 antes de inicializar la solicitud y reiniciar todos los workers; en PHP 8.5 también fatal_error_backtraces=0.
• No depender de .user.ini o ini_set() para estas medidas; se aplican demasiado tarde en algunas rutas.
• Cloudflare WAF y otras reglas de borde son defensa en profundidad y solo cubren el tráfico que pasa por ese punto.

Rollback y límites de las herramientas

El rollback preferido sigue siendo el snapshot completo. Los scripts generan informes, manifiestos y rollback en /root/php2shell-fullfix/<marca>/ en Linux o C:\ProgramData\PHP2ShellFullFix\<marca>\ en Windows.

Los cambios automáticos se limitan a instalaciones BT panel reconocidas, contenedores Debian con imagen PHP oficial y ZIP oficiales de PHP en Windows. Las compilaciones desconocidas, paquetes de distribución y runtimes embebidos reciben una ruta manual.

Herramientas de respuesta

Los escáneres hacen inventario pasivo de versiones y configuración. Los scripts de servidor inician en modo comprobación y exigen tres confirmaciones antes de cambiar nada.

Sumas SHA256

Fuentes autorizadas

Los datos del producto priorizan PHP y GitHub Security Advisories; los avisos de CISA, CERT-EU, NCSC-NL y proveedores cloud sirven para contraste.

1. PHP official security advisory · 2026-10-21
2. CVE-2026-109618 · GHSA-w8hw-w9fx-j79w
3. CVE-2026-109619 · GHSA-6wmf-4rv5-p3rp
4. PHP 8.2.35 official release record
5. NCSC-NL · php2shell operational information
6. CISA CSAF/VEX · VA-26-295-01
7. Canadian Centre for Cyber Security · AL26-026
8. CERT-EU Security Advisory 2026-018
9. Cloudflare · php2shell WAF protection