PHP2Shell: dos fallos críticos de PHP permiten ejecutar código en servidores web sin autenticación

El 21 de octubre de 2026, el proyecto PHP publicó de urgencia las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir CVE-2026-109618 y CVE-2026-109619, dos fallos de memoria que permiten a un atacante sin credenciales ejecutar código mediante una petición HTTP manipulada. El CERT-FR emitió una alerta: toda instalación de PHP que sirva tráfico web debe actualizarse, incluidas las antiguas ramas 7.x y 8.0–8.1.

Qué ha pasado

El 21 de octubre de 2026 el proyecto PHP publicó una actualización de seguridad crítica, PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrige dos fallos de ejecución remota de código bautizados PHP2Shell, con una puntuación de 9,2 en CVSS 4.0 cada uno. El CERT-FR publicó ese mismo día la alerta CERTFR-2026-ALE-014. CVE-2026-109618 procede de la gestión de la falta de memoria: una petición puede interrumpirse cuando sus datos internos solo están parcialmente inicializados, y la fase de limpieza utiliza después esos datos no válidos. Las peticiones multipart desmesuradas son una forma de provocarlo. CVE-2026-109619 es un uso de memoria liberada: el estado que deja una petición sobrevive en el proceso trabajador y lo reutiliza una petición posterior.

A quién afecta

Según php.net, afecta a toda instalación que sirva peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Los avisos de PHP indican que se validó la ejecución completa de código sin autenticación contra mod_php con su configuración por defecto, y contra FPM en el caso del segundo fallo. El CERT-FR considera vulnerables todas las versiones 5.x, 6.x, 7.x, 8.0 y 8.1; de forma excepcional, el equipo de PHP publicó parches mínimos de código fuente para las ramas 7.4, 8.0 y 8.1, ya sin soporte. Las fuentes oficiales no informaban de explotación activa al cierre de esta edición; según ZATAZ, circulan demostraciones en foros. WordPress, Drupal, Joomla y las aplicaciones a medida funcionan sobre PHP.

Qué hacer ahora

1. Inventaríe sus versiones de PHP en cada servidor y contenedor: php -v, comprobando la versión que usa realmente el servidor web (pool FPM, módulo de Apache).
2. Actualice a 8.2.35, 8.3.36, 8.4.27 u 8.5.12, o instale los paquetes corregidos de su distribución (apt update && apt upgrade, dnf upgrade 'php*'), y después reinicie PHP-FPM o Apache para que no quede ningún proceso antiguo.
3. Si no puede parchear hoy: fije session.upload_progress.enabled = Off en php.ini, como recomienda el CERT-FR, y ponga fatal_error_backtraces en Off; el equipo de PHP advierte de que estos ajustes no cubren todas las vías de ataque.
4. En 7.4 a 8.1: aplique ya los parches retroportados o los de su proveedor y planifique el paso a una rama con soporte (la 8.2 termina el 31 de diciembre de 2026).
5. Vigile los registros: caídas de procesos PHP, errores de memoria agotada y archivos inesperados en los directorios web.

Nuestra opinión

PHP está debajo de buena parte de los sitios web empresariales, a menudo en versiones que nadie recuerda haber instalado. Estos fallos recuerdan que hay que inventariar los entornos de ejecución, no solo las aplicaciones, y tratar una rama de PHP sin soporte como un riesgo que eliminar, no como una herencia que soportar.

Fuentes

• PHP — Critical security release: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35
• CERT-FR — CERTFR-2026-ALE-014 : Multiples vulnérabilités dans PHP
• PHP (GitHub security advisory) — RCE via OOM corruption
• PHP (GitHub security advisory) — RCE via stale global state
• ZATAZ — PHP2Shell : deux failles critiques menacent les serveurs web

Cómo elegimos, verificamos y redactamos nuestros análisis →