PHP2Shell: dos fallos críticos en PHP permiten ejecutar código sin autenticarse
PHP2Shell tiene nombre de exploit de película, pero el problema es aburrido y grave: dos fallos en el núcleo de PHP, con CVSS 9.2, que permiten a un desconocido ejecutar código en tu servidor antes de que tu aplicación se entere.
Qué es PHP2Shell y por qué no es una vulnerabilidad de plugin
El 21 de octubre de 2026, a las 14:00 UTC, el proyecto PHP publicó una versión de seguridad fuera de ciclo que arregla dos vulnerabilidades del intérprete, conocidas en conjunto como PHP2Shell. No hay módulo de terceros ni tema de por medio: el código que falla es el mismo que ejecuta cualquier archivo .php.
Dos CVE, una sola historia: CVE-2026-109618 y CVE-2026-109619
La primera permite ejecución remota de código. La segunda expone memoria del proceso y sirve de apoyo. Comparten origen: el manejo de peticiones con cuerpo multipart/form-data dentro de la extensión de sesiones.
CVSS 9.2 y ejecución remota de código sin autenticarse
Ambas tienen 9.2 en CVSS v4.0. Traducido: el atacante no necesita cuenta, ni sesión válida, ni pasar por un formulario de login. Le basta con enviar peticiones HTTP manipuladas a un servidor que hable PHP.
Lee también
El fallo está en el intérprete: WordPress, Laravel y tu script propio por igual
Eso es lo que cambia el cálculo. WordPress, Drupal, Laravel y el script de cuarenta líneas que alguien dejó en un subdirectorio comparten superficie: si el PHP que los ejecuta está sin parchear, todos están expuestos. Si nunca has mirado debajo del framework, qué es PHP y por qué es importante te ubica la pieza.
Cómo funciona, sin leer código C
No hace falta entender el parche para entender el riesgo. El mecanismo se cuenta en tres pasos y una analogía.
La barra de progreso de subida que casi nadie usa y que viene activada
PHP trae una función opcional llamada progreso de subida de sesión: sirve para mostrar una barra mientras se sube un archivo grande, y el intérprete va leyendo el cuerpo de la petición mientras llega. Viene activada por defecto y se ejecuta aunque tu aplicación no use sesiones.
El use-after-free: memoria liberada que se sigue usando
Durante esa lectura, PHP guarda referencias a la sesión y las usa hasta que la subida termina. Si el envío se corta en el momento exacto, la sesión se reinicializa y libera esa memoria, pero las referencias siguen apuntando ahí: eso es un use-after-free, escribir en memoria que ya no te pertenece. Con ese control se redirige la ejecución. La analogía: la llave se quedó puesta en una habitación que recepción acaba de reasignar.
Por qué la autenticación de tu aplicación no detiene el ataque
El fallo se dispara cuando PHP todavía está leyendo el cuerpo de la petición, antes de que el framework decida qué ruta atender. Un middleware de autenticación o un login no llegan a ejecutarse. Quienes reprodujeron los fallos lo dicen sin rodeos: la autenticación de la aplicación no bloquea este ataque.
Versiones afectadas y versiones que lo arreglan
El proyecto PHP mantiene parches de seguridad solo para las ramas soportadas. Lo disponible desde el 21 de octubre:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Qué pasa con PHP 8.1 y anteriores
No hay parche oficial y no lo habrá. Sansec, que publicó el análisis de referencia, sostiene que el rango afectado llega hasta PHP 5.4. Además, el soporte de seguridad de la rama 8.2 termina a finales de 2026: actualizar ahora es también la última ventana cómoda para saltar de rama.
Cómo comprobar tu versión real, la que sirve las peticiones
Aquí se comete el error clásico: el comando de versión en la consola puede devolver una cifra distinta de la que usa el proceso que atiende a los visitantes. Lo que vale es el SAPI real: el pool de PHP-FPM, el módulo de Apache o el contenedor que escucha. Un archivo temporal de información del intérprete, la cabecera del panel del hosting o el comando ejecutado dentro del contenedor son formas fiables de verlo.
La carrera contra el reloj: filtración el 20, parche el 21
Los detalles circularon antes del aviso oficial
Los identificadores y los detalles técnicos se filtraron el 20 de octubre y circularon por foros y redes antes de que existiera arreglo público. El parche llegó al día siguiente por la tarde: la ventana entre enterarse y actualizar fue de horas.
Explotación en la naturaleza: qué se observó y desde cuándo
Según AWS, hubo intentos de explotación desde el 17 de octubre, días antes de que hubiera versión corregida. Otros proveedores reportan explotación activa. No hay cifra fiable de servidores comprometidos, y conviene desconfiar de quien la dé.
Qué hicieron los proveedores: parches de distribución y reglas de WAF
Las distribuciones publicaron paquetes corregidos el mismo día y los proveedores de WAF desplegaron reglas para los vectores conocidos, incluido el plan gratuito de Cloudflare. También circularon configuraciones para bloquear envíos multipart hacia PHP. Todo eso compra tiempo; nada sustituye al parche, y así lo aclararon quienes publicaron las reglas.
Qué hacer ahora, en orden
- Parchear y reiniciar los procesos que sirven PHP. Instala la versión corregida de tu rama y reinicia PHP-FPM o el servidor web: si copias archivos sin reiniciar, los procesos viejos siguen atendiendo con el binario anterior.
- Si no puedes parchear hoy: apagar el progreso de subida y limitar el cuerpo. Desactiva la opción en el archivo de configuración del SAPI real, o en el pool, y reinicia; no sirve hacerlo en tiempo de ejecución desde la aplicación. Suma un límite bajo de tamaño de petición si no recibes archivos: 8 MB es razonable, 32 MB si necesitas subidas.
- Filtrar en el borde. Reglas de WAF actualizadas y, si tu aplicación no necesita subir archivos, bloqueo de envíos multipart hacia PHP. Es un puente, no un destino.
- Revisar después. Integridad de archivos, archivos nuevos en directorios de subida, accesos y procesos que no reconoces. Un fallo de esta gravedad obliga a mirar hacia atrás aunque ya estés parcheado.
Qué significa esto para el ecosistema PHP y Laravel
La versión de PHP dejó de ser un detalle de hosting
Durante años fue una línea del panel que nadie miraba. Con dos fallos de 9.2 en el núcleo y explotación previa al parche, esa línea pasa a ser superficie de ataque: si administras servidores, fijar y actualizar la versión te toca a ti.
El caso de los servidores gestionados y las imágenes de contenedor viejas
Los dos puntos ciegos son el hosting compartido que tarda semanas en mover su PHP y las imágenes de contenedor que nadie reconstruye. En el segundo caso, las imágenes de Docker para PHP en producción se actualizan con un rebuild: si el pipeline no reconstruye, la imagen sigue con el intérprete viejo. En Forge la versión se fija por servidor y por sitio, así que hay que cambiarla sitio por sitio y verificar después. Para la revisión posterior, la guía para fortalecer la seguridad en sistemas Linux cubre lo básico de integridad y accesos.
Conclusión
La única mitigación completa es actualizar el intérprete; el resto solo compra días. Si tienes un servidor con PHP, revisa hoy la versión que atiende las peticiones y confirma que el proceso se reinició después del cambio. En el blog hay más análisis de seguridad y desarrollo web, con contexto técnico y sin alarmismo.
