PHP2Shell es el nombre de dos vulnerabilidades críticas en PHP, publicadas el 21 de octubre de 2026. Están registradas como CVE-2026-109618 y CVE-2026-109619, ambas con un puntaje CVSS v4.0 de 9.2. Permiten que un atacante sin credenciales ejecute código en un servidor web. Además, ya se registraron intentos de explotación, incluso antes de la publicación oficial.
Qué es PHP2Shell
Las dos fallas comparten un mismo patrón. PHP corta el procesamiento de una petición con una salida abrupta, conocida como bailout. Ese corte puede dejar el estado interno a medio inicializar o apuntando a memoria ya liberada.
En el caso de CVE-2026-109618, el disparador es un error de memoria agotada. La petición queda con datos parcialmente inicializados. Después, las rutinas de limpieza los procesan como válidos y eso abre un camino a la ejecución remota de código.
CVE-2026-109619, en cambio, aparece después de un error fatal. PHP conserva referencias a memoria que ya liberó. Así, una petición posterior atendida por el mismo worker usa esas referencias antes de que se reinicien.
El riesgo crece cuando un mismo worker atiende muchas peticiones, como en Apache con mod_php. También pesa la configuración. Tres de las cinco técnicas demostradas usan el progreso de carga de sesión como disparador remoto.
La investigación la publicaron equipos de Wiz, OpenAI y Calif, con crédito a Quarkslab por una de las fallas.
Qué versiones de PHP están afectadas
Se estima que el problema alcanza a PHP desde la versión 5.4.0. Están en riesgo las instalaciones que atienden peticiones web, como PHP-FPM, mod_php, php-cgi, FrankenPHP y LiteSpeed. La explotabilidad depende de la configuración y de la aplicación. Según el equipo de PHP, mod_php es la prioridad. El exploit demostrado se dispara antes de que corra el código de la aplicación.
| Rama de PHP | Versión corregida | Estado |
|---|---|---|
| 8.5 | 8.5.12 | Parche oficial |
| 8.4 | 8.4.27 | Parche oficial |
| 8.3 | 8.3.36 | Parche oficial |
| 8.2 | 8.2.35 | Parche oficial |
| 7.4, 8.0 y 8.1 | Sin release | Backports mínimos de código fuente |
| 5.4 a 7.3 | Sin release | Sin parche |
Las distribuciones Linux pueden mantener el número de versión anterior con la corrección aplicada. Por eso conviene validar cada paquete contra el aviso de su proveedor.
Cómo evolucionó la explotación de PHP2Shell
| Fecha | Hecho |
|---|---|
| 22/10/2026 | Palo Alto Networks confirma impacto en PAN-OS y Panorama |
| 21/10/2026 | Circulan detalles filtrados y PHP publica los parches |
| 20/10/2026 | PHP anticipa un release crítico para el día siguiente |
| 17/10/2026 | Amazon registra un intento de explotación en un honeypot |
El primer intento se detectó cuatro días antes de la divulgación coordinada, según Help Net Security. Hoy, Amazon, Cloudflare y Patchstack ya reportaron actividad maliciosa.
Por qué PHP2Shell tiene un alcance tan amplio
PHP es el lenguaje de servidor de la mayoría de los sitios web. Según W3Techs, lo usa el 69,3% de los sitios cuyo lenguaje de servidor se conoce. Dentro de ese universo, el 34,6% todavía corre PHP 7 o PHP 5. Son ramas sin un release corregido oficial.
A eso se suma la velocidad. El informe 2026 de Rapid7 lo mide con el catálogo KEV de CISA, que lista vulnerabilidades explotadas. La mediana entre la publicación y la inclusión en ese catálogo bajó de 8,5 a 5 días. En PHP2Shell, la explotación empezó antes de la publicación.
También hay PHP en lugares que no figuran en los inventarios. Aparece en contenedores, paneles de hosting, sistemas heredados y appliances de terceros. De hecho, Palo Alto Networks confirmó que todas las versiones de PAN-OS y Panorama están afectadas.
Qué hacer ahora
Actualizar a una versión corregida es la única solución completa. Las mitigaciones reducen la exposición mientras el parche se despliega.
- Relevar todas las instalaciones de PHP, incluidas las embebidas en appliances y contenedores.
- Instalar 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o el paquete corregido de la distribución.
- Reiniciar o reemplazar los workers y confirmar que ninguno sigue con el build anterior.
- Volver a escanear para validar la remediación.
Si el parche no puede llegar de inmediato, hay medidas temporales.
- Fijar
session.upload_progress.enabled=0en php.ini o en el pool, y reiniciar los workers. - En PHP 8.5, fijar
fatal_error_backtraces=0a nivel administrativo. - Fijar
memory_limit=-1a nivel administrativo, conphp_admin_valueen el pool de FPM o en Apache. Así, las aplicaciones no pueden cambiarlo. También conviene mantener bajopost_max_size. Sin límite de memoria, una sola petición puede consumir toda la RAM. Por eso, esta medida siempre va junto con la siguiente. - Limitar el tamaño de las peticiones en el servidor web o el proxy, y bloquear multipart donde la aplicación no lo use.
- Activar reglas de WAF para los vectores conocidos.
- Aislar o restringir el acceso público a los sistemas que no puedan corregirse pronto.
Revisar si hubo compromiso
Actualizar cierra la vulnerabilidad. Sin embargo, un acceso previo puede seguir activo después del parche. Por eso, cada servidor actualizado necesita una revisión de compromiso.
- Buscar webshells y archivos PHP nuevos o modificados desde el 17 de octubre.
- Revisar cuentas creadas recientemente en el sistema operativo, el CMS y los paneles.
- Analizar conexiones salientes inusuales desde los servidores web.
- Rotar contraseñas, tokens y API keys accesibles desde el proceso de PHP.
Ante cualquier señal, el paso siguiente es contener el sistema y activar el plan de respuesta a incidentes.
Una respuesta continua
PHP2Shell muestra que la respuesta empieza mucho antes del parche. Saber dónde corre cada tecnología, validar la corrección y detectar accesos previos forman un mismo proceso. En PUCARA Cybersecurity lo trabajamos de forma continua con CVM y SOC as a Service. Así, la próxima vulnerabilidad crítica encuentra ese proceso ya en marcha.
