PHP2Shell: qué es la vulnerabilidad crítica de PHP y qué hacer hoy

Qué pasó, en corto

• Dos fallas en el núcleo de PHP: CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell. Las dos tienen 9,2 sobre 10 en CVSS v4.
• No hace falta iniciar sesión: un atacante puede ejecutar código en el servidor con una petición web. El riesgo más alto es con Apache y mod_php, donde la falla se dispara antes de que corra el código de tu aplicación.
• Afecta casi todo PHP en uso: PHP-FPM, mod_php, php-cgi, FrankenPHP y LiteSpeed, desde la versión 5.4 hasta la 8.5.11. Los investigadores confirmaron ataques sin autenticación contra versiones de WordPress, Drupal, Joomla y Magento.
• Ya hay ataques: Amazon vio el primer intento el 17 de octubre, cuatro días antes de que se publicara la falla, y dice que ahora se explota de forma amplia. Cloudflare también reporta ataques.

Versiones afectadas y corregidas

Si usas PHP 8.1 o anterior, no hay parche que esperar: la única salida es subir a 8.2 o superior. Es el caso de muchos servidores viejos que nadie se ha atrevido a tocar.

Cómo saber si tu servidor está expuesto

• En un servidor Linux (EC2, Lightsail, VPS): corre php -v y, si usas PHP-FPM, también php-fpm -v (el nombre puede llevar la versión, por ejemplo php-fpm8.3 -v). Compara con la tabla.
• En hosting con cPanel: revisa la versión de cada dominio en MultiPHP Manager. Un mismo servidor puede tener sitios en versiones distintas.
• En contenedores: mira la etiqueta de la imagen base (por ejemplo php:8.3-fpm) y la versión real dentro del contenedor. Una imagen construida hace un mes sigue vulnerable aunque la etiqueta diga 8.3.
• En toda una cuenta de AWS: Amazon Inspector y el inventario de Systems Manager muestran qué instancias e imágenes de ECR tienen paquetes de PHP y en qué versión. Así no se queda por fuera el servidor que nadie recordaba.

Qué hacer hoy, en orden

1. 1. Actualizar PHP. Es la única solución completa. Si usas los paquetes de tu distribución (Ubuntu, Debian, Red Hat), instala la actualización de seguridad de PHP y reinicia PHP-FPM o Apache. En Amazon Linux 2023 el paquete corregido estaba en preparación el 21 de octubre: revisa si ya salió antes de dar el tema por cerrado. En contenedores, reconstruye la imagen con la versión corregida y vuelve a desplegar.
2. 2. Si no puedes actualizar hoy, reduce la exposición. El equipo de PHP propone ajustes temporales: session.upload_progress.enabled=0 y, en PHP 8.5, fatal_error_backtraces=0; para la otra falla, fijar memory_limit=-1 de forma que la aplicación no lo pueda cambiar, con un límite de memoria en el contenedor o el servidor para que no se caiga. Reinicia todos los procesos de PHP después. Bajan el riesgo, pero no reemplazan la actualización.
3. 3. Poner un filtro adelante. Cloudflare ya tiene reglas para todos sus clientes, incluido el plan gratis. En AWS, con AWS WAF en el balanceador o en CloudFront, puedes bloquear las peticiones que traen el texto PHP_SESSION_UPLOAD_PROGRESS o, si tu aplicación no recibe archivos, las subidas de archivos. Pruébalo antes en modo de conteo para no tumbar formularios legítimos.
4. 4. Revisar si ya entraron. Busca en los registros del servidor desde el 17 de octubre peticiones POST con PHP_SESSION_UPLOAD_PROGRESS, procesos que no reconoces y archivos PHP nuevos o modificados en las carpetas del sitio.
5. 5. Si nada de lo anterior es posible, saca el sitio de internet hasta actualizarlo. Es lo que recomienda CERT-EU para aplicaciones expuestas sin parche.

Preguntas frecuentes