Halloween trajo una vulnerabilidad con disfraz. PHP2Shell es el nombre que circula para un par de registros CVE críticos en el núcleo de PHP, CVE-2026-109618 y CVE-2026-109619, ambos con ejecución remota de código sin autenticación. El nombre hace mucho trabajo. Un buen nombre pone un bug en el teléfono del CISO antes de que el aviso sea siquiera legible, y en este caso, la marca llegó literalmente antes que los hechos, cuando un vídeo de prueba de concepto bajo embargo y diferencias tempranas de contenedor filtraron el 20 de octubre antes de la publicación coordinada.

Ahora que el polvo se ha asentado tras la publicación de emergencia del 21 de octubre, separemos los hechos verificados del rumor en redes sociales. Ambas vulnerabilidades residen en el código C del propio Zend Engine y afectan a todas las versiones de PHP desde 5.4 hasta 8.5.11. Descubiertas de forma independiente en agosto por investigadores de Calif (con OpenAI) y Wiz Research mediante auditoría de código asistida por IA, ambos fallos tienen una puntuación CVSS v4.0 oficial de 9.2:

• CVE-2026-109618 (Corrupción por agotamiento de memoria): Cuando una solicitud manipulada agota memory_limit a mitad del análisis, PHP aborta mediante longjmp() antes de que las estructuras internas estén completamente inicializadas, engañando a la rutina de limpieza para que libere memoria no inicializada. Contra Apache mod_php, una sola solicitud sin autenticación puede desencadenar RCE antes de que se ejecute una sola línea de código de aplicación.

• CVE-2026-109619 (Estado global obsoleto): Tras un error fatal, punteros propiedad de la solicitud pueden sobrevivir apuntando a memoria liberada. La siguiente solicitud gestionada por el mismo worker persistente (como PHP-FPM) reutiliza ese estado envenenado, principalmente a través de la configuración habilitada por defecto session.upload_progress.enabled.

En las primeras 48 horas de un bug con nombre propio, la historia siempre tiene tres capas: lo que dice el aviso oficial, lo que dicen los informes de los investigadores y lo que dicen mil reposts en pánico. El catálogo Known Exploited Vulnerabilities (KEV) de CISA () sigue siendo la señal serena aquí. Si bien las redes honeypot de Amazon, Cloudflare y Arctic Wolf ya han detectado escaneos oportunistas y sondeos de botnets, CISA indicó en su alerta del 21 de octubre que aún no había confirmado intrusiones exitosas en entornos reales, y ninguno de los dos CVE ha sido añadido a KEV todavía.

Lo que sí podemos analizar con total confianza es lo que sucede después, porque el manual de post-explotación nunca cambia. Ya sea que un atacante use PHP2Shell para ejecutar comandos directamente en memoria (MITRE ATT&CK T1190) o instale una web shell persistente (T1505.003, ), el payload se ejecuta con la identidad del servidor web. Y en demasiadas organizaciones, esa identidad es una cuenta de servicio discretamente poderosa con una contraseña de base de datos almacenada en un fichero de configuración contiguo.

Por eso una publicación de IAM está escribiendo sobre un bug de PHP. El exploit es la entrada. La identidad es el premio. Una vez que un atacante ejecuta código como www-data o como el usuario del pool de workers de FPM, las preguntas que determinan si esto será una mala tarde o un mal trimestre son todas preguntas de identidad:

• ¿Qué credenciales puede leer ese proceso? Usuarios de base de datos, claves de API, secretos de cliente OAuth y roles de instancia en la nube accesibles a través del endpoint de metadatos.

• ¿Qué pueden hacer esas credenciales? Un usuario de base de datos que solo necesita SELECT en tres tablas pero que tiene privilegios de DBA porque «era más fácil en 2019» convierte un worker comprometido en una brecha de datos completa.

• ¿Qué identidad tiene el propio host web? Un rol de IAM con permisos excesivos adjunto a la instancia de cómputo es la ruta más rápida desde una máquina hasta toda la cuenta en la nube. AWS documenta el hardening de metadatos de instancia (IMDSv2) precisamente por esta razón ().

• ¿Lo detectarías siquiera? Los workers comprometidos son ruidosos si se registra el comportamiento de los procesos y silenciosos si solo se monitorizan los logs HTTP. Las conexiones salientes desde un servidor web hacia hosts desconocidos, nuevos ficheros en directorios con permisos de escritura web, y workers de PHP que invocan /bin/sh, curl o wget son detecciones baratas y de alta señal.

PHP ofrece palancas de configuración que reducen la exposición mientras se prueba el parche (). Para PHP2Shell específicamente, establecer session.upload_progress.enabled = 0 y (en PHP 8.5) fatal_error_backtraces = 0 cierra los caminos más comunes de CVE-2026-109619. Restringir disable_functions (exec, shell_exec, system, passthru) y open_basedir sigue siendo una buena práctica contra payloads PHP oportunistas, aunque como PHP2Shell corrompe memoria en el motor C subyacente, un exploit sofisticado puede eludir las restricciones de php.ini en memoria. El confinamiento a nivel de sistema operativo (SELinux, AppArmor y límites estrictos de memoria con cgroup v2) es donde reside el perímetro real.

En el plano de la identidad, el consejo habitual no es glamuroso pero es correcto. Asigna al nivel web el conjunto mínimo de permisos que necesita, rota los secretos que gestiona, saca esos secretos de ficheros .env planos y llévelos a un gestor de secretos con tokens de vida corta, y trata la cuenta de servicio del servidor web como un principal a auditar igual que cualquier administrador humano. Las cuentas de servicio no se quejan en entrevistas de salida, así que nadie las revisa. Ese es todo el problema.

Aquí está la parte alentadora, y lo digo en serio. Cada bug con un nombre llamativo es un ejercicio de tabletop gratuito. No es necesario esperar al próximo CVE para responder: «Si un extraño ejecutara código en nuestro nivel PHP esta noche, ¿qué obtendría y nos daríamos cuenta?» Si tu respuesta honesta te hace estremecerte, enhorabuena: acabas de encontrar la vulnerabilidad real, y no necesitaba un número CVE.

Actualiza a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35 (y si aún ejecutas PHP 8.1 en fin de vida o versiones 7.x, reconoce que los parches del upstream no llegarán). Monitoriza CISA KEV. Mientras tanto, reduce lo que el nivel web puede alcanzar. El disfraz habrá desaparecido el lunes. La cuenta de servicio con privilegios excesivos seguirá ahí, a menos que la gestiones.