PHP2Shell: dos vulnerabilidades críticas de PHP ponen en riesgo a millones de sitios web
Dos vulnerabilidades críticas de corrupción de memoria en PHP pueden permitir la ejecución remota de código (RCE) sin autenticación, incluso cuando la propia aplicación no contiene ningún error explotable. Así funciona PHP2Shell, por qué importa y qué tienen que hacer los administradores.
Hay algo especialmente inquietante en una vulnerabilidad que no requiere ningún error en tu aplicación.
Puedes escribir PHP limpio. Puedes validar cada entrada, escapar cada salida, mantener tus dependencias actualizadas y seguir todas las guías de programación segura.
Y aun así, un atacante podría comprometer tu servidor a través de una vulnerabilidad en el propio intérprete de PHP.
Eso es lo que hace de PHP2Shell una divulgación de seguridad tan importante.
El 21 de octubre de 2026, el equipo de desarrollo de PHP publicó actualizaciones de emergencia que corrigen dos vulnerabilidades críticas:
- CVE-2026-109618: Ejecución remota de código mediante corrupción por falta de memoria (out-of-memory).
- CVE-2026-109619: Ejecución remota de código mediante estado global obsoleto.
Ambas tienen una puntuación CVSS v4.0 de 9,2 (crítica).
Las vulnerabilidades afectan a la gestión interna de memoria de PHP y al ciclo de vida de las peticiones. En condiciones vulnerables, los atacantes pueden ejecutar código sin autenticación o acceder a información sensible que haya quedado en la memoria del proceso.
Los investigadores han demostrado una explotación exitosa contra WordPress, Drupal y Joomla. Pero ninguna de esas aplicaciones es la causa de fondo.
La vulnerabilidad está en el propio PHP.
Y eso cambia la escala del problema.
Por qué PHP2Shell es una vulnerabilidad tan grave
PHP sigue siendo uno de los cimientos de la web moderna.
Según las estadísticas de W3Techs a las que hacen referencia los investigadores, PHP funciona en aproximadamente el 70 % de los sitios web cuyo lenguaje de programación del lado del servidor está identificado.
Esa cifra describe la presencia global de PHP en el mercado, no el porcentaje de sitios web que se haya confirmado que son vulnerables o explotables.
Aun así, la superficie de ataque potencial es enorme.
PHP da soporte a aplicaciones que van desde pequeños blogs personales hasta grandes plataformas de comercio electrónico, aplicaciones empresariales, sistemas de gestión de contenidos y sitios web gubernamentales.
Entre el software popular construido sobre PHP se incluyen:
- WordPress
- Drupal
- Joomla
- Magento / Adobe Commerce
- Aplicaciones Laravel
- Aplicaciones Symfony
- Moodle
- MediaWiki
- Nextcloud
El detalle importante es dónde existe PHP2Shell.
La mayoría de las vulnerabilidades de seguridad de aplicaciones surgen porque una aplicación procesa de forma incorrecta una entrada no confiable.
Algunos ejemplos son la inyección SQL, la inyección de comandos, la omisión de autenticación y la deserialización insegura.
PHP2Shell opera a un nivel más bajo.
Las vulnerabilidades afectan a cómo PHP inicializa, mantiene y libera la memoria interna mientras gestiona peticiones HTTP.
En ciertos escenarios, la explotación puede producirse antes de que la aplicación empiece a ejecutar su propio código PHP.
Esto significa que incluso una aplicación trivial podría quedar expuesta si se ejecuta sobre un runtime vulnerable y una configuración de servidor explotable.
Para un atacante, este es un objetivo atractivo. En lugar de buscar una vulnerabilidad en cada aplicación PHP, puede investigar debilidades compartidas por muchas aplicaciones que se ejecutan sobre la misma tecnología subyacente.
Entender las dos vulnerabilidades de PHP2Shell
PHP2Shell se refiere a dos clases de vulnerabilidad relacionadas que implican corrupción de memoria.
Aunque las vulnerabilidades tienen similitudes, sus modos de fallo subyacentes son distintos.
CVE-2026-109618: ejecución remota de código mediante corrupción por falta de memoria (out-of-memory)
PHP incluye mecanismos para detener los scripts que consumen demasiada memoria.
El ajuste memory_limit es uno de ellos.
Normalmente, un fallo de asignación de memoria debería terminar de forma segura la operación afectada.
Sin embargo, históricamente PHP usó un mecanismo basado en longjmp() para salir de ciertas condiciones de error fatal.
Esto permite que la ejecución salte fuera del contexto actual sin seguir la secuencia ordinaria de retorno de funciones.
Ese comportamiento se vuelve peligroso cuando la operación interrumpida no ha terminado de inicializar o limpiar las estructuras internas.
Considera el siguiente ciclo de vida simplificado:
- PHP empieza a procesar una petición HTTP entrante.
- Se asignan e inicializan estructuras internas.
- Falla una asignación de memoria.
- PHP aborta la operación actual.
- Algunos datos internos quedan inicializados solo en parte.
- El procedimiento de cierre de la petición intenta procesar esos datos no válidos.
La debilidad crítica aparece cuando el código de cierre trata la memoria no válida o inicializada de forma incompleta como estado interno legítimo.
Esto puede producir corrupción de memoria.
Según el entorno de ejecución y la capacidad del atacante para influir en la disposición de la memoria, el resultado puede ser la caída del proceso o, potencialmente, la ejecución de código arbitrario.
Por qué Apache mod_php está especialmente expuesto
Uno de los hallazgos más importantes se refiere a los despliegues de Apache que usan mod_php.
En esta arquitectura, PHP se ejecuta dentro de los procesos worker de Apache.
El aviso de seguridad de PHP explica que el procedimiento de cierre de la petición puede ejecutarse incluso cuando falla la inicialización de la petición.
En consecuencia, una petición HTTP controlada por el atacante puede desencadenar la condición vulnerable durante el procesamiento de la petición del propio PHP, antes de que empiece el código específico de la aplicación.
Los investigadores confirmaron la ejecución remota de código completa y sin autenticación contra configuraciones mod_php afectadas con ajustes por defecto.
Esto es significativo porque la validación de entradas a nivel de aplicación no puede proteger código que todavía no ha empezado a ejecutarse.
PHP-FPM se comporta de otra manera.
Cuando falla el arranque de la petición, PHP-FPM puede terminar el worker afectado y evitar así esa ruta de limpieza concreta. Sin embargo, otras condiciones de falta de memoria posteriores a un arranque correcto aún pueden llegar a estados inseguros.
El aviso de PHP trata a PHP-FPM como potencialmente susceptible a esta clase de vulnerabilidad, a la vez que distingue el exploit demostrado de mod_php de las rutas que no se habían validado por completo para ese CVE concreto.
Los distintos entornos de ejecución de PHP tienen distintas condiciones de explotación. Nada de eso es motivo para retrasar la aplicación del parche.
CVE-2026-109619: ejecución remota de código mediante estado global obsoleto
La segunda vulnerabilidad implica que PHP conserva referencias a memoria que ya se ha liberado.
Es un problema clásico de seguridad de memoria, conocido habitualmente como use-after-free.
Los workers de PHP pueden gestionar varias peticiones HTTP a lo largo de su vida.
Aunque cada petición tiene sus propias asignaciones de memoria, parte del estado global interno persiste dentro del worker.
Ese estado debe restablecerse correctamente cuando termina una petición.
El problema surge cuando una referencia a memoria propiedad de la petición sobrevive después de que la petición haya terminado.
Una petición posterior puede entonces acceder a la referencia obsoleta.
Una secuencia simplificada sería así:
- La petición A inicializa estado interno de PHP.
- Un error fatal interrumpe una operación antes de que se complete la limpieza.
- La petición A termina y su memoria se libera.
- El worker conserva una referencia a la memoria liberada.
- La petición B llega a una operación que accede a esa referencia obsoleta.
- PHP procesa memoria que ya no pertenece al objeto original.
Un atacante que pueda influir en la secuencia de operaciones y en la disposición de memoria relevante puede ser capaz de convertir esta condición en corrupción de memoria o en ejecución remota de código.
Los investigadores también demostraron escenarios en los que se podía exponer contenido sensible de la memoria del proceso sin haber obtenido antes ejecución de código.
Esa distinción importa.
Una vulnerabilidad que filtra tokens de autenticación u otros secretos puede tener consecuencias graves aunque no produzca una shell.
Progreso de subida de sesión y ciclo de vida de la petición
Una ruta de ataque especialmente interesante implica la funcionalidad de progreso de subida de sesión (session upload progress) de PHP.
Esta funcionalidad puede interactuar con el estado de la sesión mientras se procesan peticiones HTTP multipart.
Importante: parte de este procesamiento ocurre antes de la inicialización normal de la petición.
Los investigadores mostraron cómo el procesamiento interrumpido de una sesión podía dejar un estado interno que una petición posterior podría reutilizar de forma incorrecta.
Otras rutas identificadas implican backtraces de errores fatales, gestión de diagnósticos y estado de runtime relacionado.
El problema de fondo es más amplio que una opción de configuración o una funcionalidad de sesiones.
Es un fallo a la hora de garantizar que no se pueda acceder a la memoria propiedad de una petición una vez terminada su vida útil.
Precisamente por eso el equipo de PHP decidió abordar los problemas subyacentes del ciclo de vida en lugar de parchear solo las rutas de explotación concretas que se demostraron.
Por qué esto no es solo otra vulnerabilidad de WordPress
Hay que hacer una distinción crítica.
WordPress, Drupal y Joomla se usaron para demostrar la explotación, pero eso no significa que los investigadores descubrieran la misma vulnerabilidad de aplicación en las tres plataformas.
El componente vulnerable común era PHP.
Wiz Research demostró la ejecución remota de código sin autenticación contra despliegues representativos de estos CMS que usaban entornos PHP vulnerables.
Esas demostraciones establecen que la explotación es posible en stacks de aplicación reales.
No establecen que todas las instalaciones de esas plataformas se puedan explotar de la misma forma.
Entre los factores que influyen en la explotación se incluyen:
- Versión y compilación de PHP.
- Integración con el servidor web.
- Extensiones de PHP disponibles.
- Comportamiento de la gestión de memoria.
- Rutas de ejecución de la aplicación.
- Configuración de runtime.
- Ciclo de vida de los workers.
- Gestión de las peticiones HTTP del frontend.
Esta distinción es esencial para evaluar el riesgo correctamente.
Un servidor con una versión vulnerable de PHP necesita atención urgente, pero la explotabilidad concreta de un despliegue individual puede depender de condiciones del entorno.
Al mismo tiempo, los equipos de seguridad no deberían esperar a que un atacante reproduzca el exploit contra su infraestructura exacta antes de aplicar la corrección oficial.
El papel de la IA en el descubrimiento de PHP2Shell
Quizá el aspecto más interesante de esta divulgación es cómo se investigaron las vulnerabilidades.
PHP2Shell es un ejemplo destacado de investigación de vulnerabilidades asistida por IA contra software maduro y ampliamente desplegado.
Investigadores de Calif, Wiz y OpenAI aportaron de forma independiente hallazgos e investigación de exploits, mientras el equipo de seguridad de PHP coordinaba las correcciones.
La investigación usó modelos de IA de frontera, entre ellos GPT-5.6 Sol y Gemini 4 Argon.
Wiz también informa de que usó su propio entorno de investigación asistido por IA, Wiz Atlas.
Pero sería inexacto decir que un modelo de IA descubrió, explotó y corrigió PHP de forma independiente, sin experiencia humana.
Investigadores con experiencia seleccionaron objetivos, investigaron el comportamiento de la memoria, verificaron hallazgos, desarrollaron estrategias de explotación y coordinaron la divulgación responsable.
La IA aceleró partes de ese trabajo.
Por qué la IA marcó la diferencia
La explotación de la corrupción de memoria exige entender detalles que pueden variar mucho entre entornos.
Un investigador puede necesitar razonar sobre tiempos de vida de objetos, asignación de memoria, flujo de ejecución, estado del proceso y diferencias entre entornos.
Incluso después de identificar un error de seguridad de memoria, convertirlo en un exploit fiable puede requerir una experimentación extensa.
Los agentes de IA pueden ayudar con:
- Navegar por grandes repositorios de código nativo.
- Entender flujos de control complejos.
- Identificar rutas de gestión de errores relacionadas.
- Generar y evaluar hipótesis.
- Asistir en la depuración.
- Comparar el comportamiento entre versiones.
- Desarrollar y validar parches candidatos.
El equipo de Wiz informa de que la asistencia de la IA redujo sustancialmente el esfuerzo necesario para adaptar su investigación a distintos entornos PHP.
Esto es importante porque algunas vulnerabilidades siguen sin explotarse no porque sean inherentemente seguras, sino porque convertirlas en ataques fiables requiere una experiencia y un esfuerzo considerables.
Es posible que la IA esté cambiando el esfuerzo necesario para cruzar esa barrera.
Eso es un avance mucho más importante que limitarse a generar más informes de vulnerabilidades.
Una vulnerabilidad con una larga historia
El relato de la PHP Foundation sobre este incidente es especialmente revelador.
El problema subyacente de falta de memoria no apareció de repente en 2026.
Ya se habían identificado preocupaciones relacionadas años antes.
En 2024, una auditoría de seguridad organizada a través de OSTIF y realizada por Quarkslab sacó a la luz indicios asociados con el problema de falta de memoria.
Todavía no se había establecido una ruta concreta de explotación remota.
Desarrollar una corrección segura también resultó difícil.
El equipo de seguridad de PHP se enfrentó a requisitos contrapuestos de compatibilidad, rendimiento, extensiones de terceros y la posibilidad de que una corrección propuesta introdujera nuevos problemas.
El trabajo se estancó.
La PHP Foundation ha reconocido públicamente que las limitaciones de recursos y su proceso de toma de decisiones contribuyeron al retraso.
Esa admisión es importante.
Mantener el runtime de un lenguaje que usa una parte sustancial de internet es una responsabilidad enorme.
Sin embargo, el trabajo profundo de seguridad en la infraestructura de código abierto depende con frecuencia de un número relativamente pequeño de especialistas.
Cuando la investigación de 2026 demostró una ejecución remota de código práctica, la urgencia cambió drásticamente.
El problema ya no era una preocupación oscura de gestión de memoria con un impacto incierto.
Era una vulnerabilidad crítica confirmada que afectaba a un componente de software fundamental.
Cronología de la divulgación
| Fecha | Novedad |
|---|---|
| 2024 | Una auditoría de seguridad anterior investiga el problema de falta de memoria |
| 30 de julio de 2026 | Calif inicia su trabajo de investigación sobre PHP |
| 11 de agosto | Calif y OpenAI informan de forma independiente de hallazgos críticos relacionados con la causa raíz |
| 19–24 de agosto | Wiz identifica y notifica rutas de explotación adicionales |
| septiembre | Continúan la investigación adicional y el desarrollo coordinado de parches |
| 20 de octubre | Circulan los identificadores CVE antes de la divulgación prevista |
| 21 de octubre | PHP publica actualizaciones de seguridad de emergencia y avisos técnicos |
El proceso de divulgación también encontró dificultades.
Según la PHP Foundation, la información circuló públicamente antes de la fecha de publicación prevista y empezó a difundirse material temprano de prueba de concepto.
El proyecto aceleró la publicación de seguridad mientras los distribuidores y los proveedores de infraestructura preparaban las actualizaciones.
Cloudflare informó de que observó tráfico de ataque antes de la divulgación pública oficial y desplegó reglas de protección.
En el momento de la declaración de lanzamiento de la PHP Foundation, su equipo de seguridad no había identificado un exploit público funcional en el material de prueba de concepto que había revisado.
Estas observaciones describen distintos tipos de evidencia. El tráfico de ataque no implica automáticamente un compromiso exitoso.
Aun así, es una advertencia de lo rápido que puede estrecharse una ventana de divulgación coordinada.
¿Están los atacantes explotando PHP2Shell?
A fecha del 22 de octubre, Cloudflare ha informado públicamente de tráfico dirigido a PHP2Shell.
La empresa afirma que los atacantes ajustaron sus peticiones para intentar eludir las protecciones desplegadas.
Eso aporta evidencia de intentos activos de explotación.
Sin embargo, es importante distinguir varios estados:
Vulnerabilidad confirmada: Los investigadores han demostrado que el fallo subyacente existe.
Ejecución remota de código demostrada: Los investigadores reprodujeron la ejecución de código en entornos controlados.
Explotación intentada en ataques reales: La telemetría de seguridad muestra tráfico que intenta desencadenar la debilidad.
Compromiso exitoso en el mundo real confirmado: Los investigadores tienen evidencia de que un sistema de producción fue efectivamente comprometido.
Estas afirmaciones no son intercambiables.
En el momento de escribir esto, la información pública revisada respalda que se ha confirmado la explotación de la vulnerabilidad en entornos de investigación y que se han observado intentos de ataque contra sistemas expuestos a internet.
No establece un recuento verificado de servidores de producción comprometidos con éxito.
Dado el alcance del despliegue de PHP y la disponibilidad de detalles técnicos, los administradores no deberían asumir que esperar a esa confirmación es una estrategia razonable de gestión de riesgos.
¿Qué versiones de PHP son vulnerables?
El proyecto PHP publicó versiones corregidas el 21 de octubre de 2026.
| Rama de PHP | Versiones vulnerables | Primera versión corregida |
|---|---|---|
| PHP 8.5 | Anteriores a 8.5.12 | 8.5.12 |
| PHP 8.4 | Anteriores a 8.4.27 | 8.4.27 |
| PHP 8.3 | Anteriores a 8.3.36 | 8.3.36 |
| PHP 8.2 | Anteriores a 8.2.35 | 8.2.35 |
| PHP 8.1 y anteriores | Versiones heredadas afectadas | Se requiere un backport del proveedor o actualizar a una versión con soporte |
El problema afecta a versiones de PHP que se remontan a la época de PHP 5.4, aunque las rutas de vulnerabilidad y las condiciones concretas difieren.
PHP 8.1 y anteriores ya no reciben soporte del proyecto PHP upstream.
El equipo de seguridad de PHP ha publicado backports mínimos del código fuente para ciertas ramas antiguas, mientras que algunas distribuciones de Linux y proveedores de soporte comercial ofrecen sus propios paquetes parcheados.
PHP 8.2 también se acerca al fin de su vida útil, el 31 de diciembre de 2026.
¿Y los paquetes de las distribuciones Linux?
Hay un detalle operativo importante.
Una distribución de Linux puede hacer un backport de la corrección de seguridad sin cambiar el número de versión upstream de PHP a una de las versiones indicadas arriba.
Por lo tanto, la cadena de versión por sí sola puede no bastar para saber si un paquete mantenido por el proveedor contiene la corrección.
Los administradores deben verificar tanto la versión del paquete instalado como el estado de seguridad publicado por su distribución o proveedor de hosting.
No asumas que toda cadena de versión de aspecto antiguo corresponde a un paquete sin parchear.
Y no asumas que actualizar un framework de aplicación también actualiza PHP.
Cómo comprobar tu entorno
La primera prioridad es identificar qué runtime de PHP atiende realmente las peticiones web.
1. Comprueba la versión de PHP instalada
En un servidor donde PHP está disponible por línea de comandos:
php -vEsto muestra la versión de PHP CLI.
Sin embargo, el intérprete de PHP de línea de comandos puede no ser la misma instalación que usan Apache, PHP-FPM u otro runtime de aplicación.
Un servidor puede contener varias versiones de PHP a la vez.
Por eso, los administradores también deberían revisar la configuración de su servidor web y los procesos de PHP que atienden cada aplicación.
2. Identifica los procesos worker de PHP
En un sistema Linux, un inventario inicial de procesos puede ayudar:
ps -eo pid,user,comm,args | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd'Este es un paso de descubrimiento, no una evaluación completa de vulnerabilidades.
Identifica la versión de PHP, el paquete y la configuración asociados a cada worker activo.
3. Revisa las imágenes de contenedor
Si las aplicaciones usan Docker o Kubernetes, revisa la versión del runtime de PHP dentro de cada imagen desplegada.
No te fíes únicamente de la etiqueta de la imagen.
Las etiquetas pueden moverse, y los contenedores en ejecución pueden seguir usando imágenes más antiguas.
La pregunta relevante es qué runtime de PHP parcheado está presente en el artefacto realmente desplegado.
4. Verifica las actualizaciones de seguridad de la distribución
Consulta el aviso de seguridad de la distribución o del proveedor de hosting.
En el hosting gestionado, solicita la confirmación de que el runtime de PHP se ha actualizado o de que se ha aplicado un backport equivalente con soporte del proveedor.
Si el entorno contiene versiones heredadas de PHP sin una vía de actualización de seguridad con soporte, prioriza la migración.
Cómo proteger tus servidores contra PHP2Shell
El equipo de seguridad de PHP es explícito:
Instalar una versión corregida de PHP es la única remediación completa.
Otras medidas de configuración pueden reducir la exposición a rutas de explotación concretas, pero no pueden garantizar la protección frente a todas las variantes.
1. Actualiza PHP de inmediato
Actualiza cada runtime afectado a la versión corregida correspondiente o instala el paquete de seguridad equivalente que proporciona el proveedor.
Reinicia Apache, PHP-FPM y otros procesos de PHP de larga duración según corresponda.
Verifica que todos los workers ejecutan código parcheado.
Esto incluye servidores de producción, entornos de staging, infraestructura de desarrollo expuesta a usuarios externos, contenedores y plataformas de aplicaciones gestionadas.
2. Revisa con cuidado las mitigaciones temporales del límite de memoria
El aviso de seguridad de PHP describe cómo establecer temporalmente:
memory_limit = -1Esto puede eliminar el fallo predecible del límite de memoria a nivel de PHP que interviene en ciertas rutas de ataque demostradas.
Sin embargo, no elimina la vulnerabilidad subyacente.
También cambia el comportamiento ante el agotamiento de recursos.
Sin un límite de memoria adecuado a nivel de sistema operativo, un worker de PHP puede consumir memoria en exceso y afectar a la disponibilidad del servidor.
El equipo de PHP recomienda controles de contenedor o cgroups diseñados con cuidado cuando esta mitigación sea necesaria.
Esto debe tratarse como una opción de reducción de riesgo de emergencia para administradores que entienden las consecuencias operativas, no como una recomendación universal para la configuración de PHP en producción.
3. Desactiva el progreso de subida de sesión si no es necesario
Una de las rutas de vulnerabilidad confirmadas implica la funcionalidad de progreso de subida de sesión de PHP.
Las aplicaciones que no la necesitan pueden plantearse desactivar:
session.upload_progress.enabled = 0El ajuste debe aplicarse a nivel administrativo antes de que se produzca el procesamiento de la petición relevante, y es necesario reiniciar los workers afectados.
Esto bloquea una ruta de ataque demostrada, pero no protege frente a todas las variantes de PHP2Shell.
4. Restringe la complejidad innecesaria de las peticiones
Revisa los límites de:
- Tamaño del cuerpo de las peticiones HTTP.
- Envíos de formularios multipart.
- Tamaños de los archivos subidos.
- Profundidad de anidamiento de la entrada.
- Número de variables de entrada.
- Recursos de procesamiento de peticiones.
Estos límites pueden reducir las oportunidades de ataque que implican un consumo excesivo de memoria.
Sin embargo, deben ser compatibles con la funcionalidad legítima de la aplicación.
Son controles de defensa en profundidad, no sustitutos del parche.
5. Usa las protecciones de un WAF como capa adicional
Cloudflare anunció mitigaciones que cubren PHP2Shell.
Otros proveedores de seguridad pueden ofrecer protecciones equivalentes.
Las reglas de WAF pueden reducir la exposición a técnicas de ataque conocidas, sobre todo cuando los administradores no pueden actualizar de inmediato.
Pero las vulnerabilidades de corrupción de memoria pueden tener varias rutas de explotación.
Una regla de WAF no hace que un intérprete vulnerable sea seguro.
6. Reduce el impacto de un worker de PHP comprometido
Aplica el principio de mínimo privilegio al entorno de ejecución de PHP.
Usa cuentas de servicio separadas cuando proceda.
Evita dar a los workers web acceso innecesario a:
- Archivos de configuración sensibles.
- Credenciales administrativas de la nube.
- Secretos de despliegue.
- Otras aplicaciones del mismo host.
- Funcionalidad privilegiada del sistema operativo.
SELinux, AppArmor, el aislamiento de contenedores y unos permisos de sistema de archivos adecuados pueden ayudar a limitar las consecuencias de una explotación exitosa.
Cómo investigar posibles ataques de PHP2Shell
Como estas vulnerabilidades implican el manejo de peticiones y la corrupción de memoria, los logs convencionales de las aplicaciones pueden no contener una explicación completa de lo ocurrido.
Los equipos de seguridad deberían correlacionar varias fuentes de evidencia.
Logs HTTP y del servidor web
Busca patrones inusuales con peticiones multipart, fallos repetidos y comportamientos inesperados previos a las caídas de workers.
Entre los posibles indicadores se incluyen:
- Peticiones POST inusuales repetidas.
- Ráfagas inesperadas de respuestas HTTP 500.
- Peticiones multipart malformadas o inusualmente complejas.
- Peticiones repetidas asociadas a fallos de workers de PHP.
Son señales para investigar, no una prueba de explotación.
Logs de errores de PHP
Investiga los errores de agotamiento de memoria y los fallos fatales sin explicación.
Entre los mensajes especialmente relevantes pueden estar:
Allowed memory size exhaustedSin embargo, los errores de memoria también pueden deberse a problemas legítimos de la aplicación.
Deben interpretarse junto con otras evidencias.
Comportamiento de workers y procesos
Investiga:
- Caídas o reinicios inesperados de workers de PHP.
- Procesos del servidor web que lanzan shells o utilidades de descarga.
- Procesos hijo inusuales.
- Conexiones salientes inesperadas.
- Cambios en archivos o en tareas programadas.
Integridad de la aplicación y de las credenciales
Si sospechas que hubo un compromiso, investiga si los atacantes establecieron persistencia.
Busca archivos PHP desconocidos, plugins modificados, cuentas administrativas inesperadas y cambios no autorizados en la configuración de la aplicación.
Considera la posible exposición de credenciales que pudieran haber sido accesibles en la memoria del proceso de PHP.
Parchear una vulnerabilidad no elimina una puerta trasera instalada antes de la actualización.
Cuando se sospeche un compromiso, conserva la evidencia forense y sigue un proceso estructurado de respuesta a incidentes.
Por qué PHP2Shell me recuerda a Heartbleed y Log4Shell
Los investigadores de seguridad suelen comparar las vulnerabilidades importantes con incidentes anteriores a escala de internet.
Dos referencias históricas obvias son Heartbleed y Log4Shell.
Heartbleed demostró cómo un fallo en una biblioteca criptográfica muy usada podía exponer memoria sensible del proceso.
Log4Shell demostró cómo una funcionalidad inesperada dentro de una dependencia de software común podía crear riesgos de ejecución remota de código en todo el ecosistema del software.
PHP2Shell comparte algunas características con ambas.
Como Heartbleed, puede exponer memoria sensible.
Como Log4Shell, afecta a software fundamental usado en innumerables aplicaciones.
Pero los mecanismos de explotación son fundamentalmente distintos.
PHP2Shell implica fallos complejos del ciclo de vida de la memoria y la interacción del manejo de peticiones con la recuperación de errores.
Sería prematuro concluir que su impacto real igualará o superará el de esas vulnerabilidades históricas.
Aun así, merece un nivel similar de seriedad operativa.
La lección general es coherente:
La seguridad de una aplicación depende de mucho más que del código que escribieron sus desarrolladores.
Qué nos dice PHP2Shell sobre el futuro de la investigación de vulnerabilidades
Hay tres observaciones que me parecen especialmente importantes.
1. El software maduro sigue teniendo vulnerabilidades profundas
PHP existe desde hace décadas.
Su código ha sido examinado por investigadores de seguridad, desarrolladores, empresas comerciales de seguridad y herramientas automatizadas.
Aun así, estos problemas persistieron.
La explicación no es necesariamente que los investigadores fueran descuidados.
Algunas vulnerabilidades son extremadamente difíciles de convertir en exploits fiables.
Dependen de temporización sutil, tiempos de vida de objetos, asignación de memoria e interacciones entre componentes.
El análisis de seguridad no puede quedarse en los errores evidentes de validación de entradas.
2. La IA está cambiando la economía del desarrollo de exploits
Una vulnerabilidad que antes se consideraba demasiado compleja para explotarla de forma fiable puede volverse más práctica a medida que mejoran las herramientas de análisis.
La investigación asistida por IA puede acelerar la ingeniería inversa, la navegación por el código, la comprobación de hipótesis y la depuración.
También puede ayudar a los defensores a descubrir variantes y verificar correcciones.
Es un avance de doble uso.
Las mismas mejoras que ayudan a los defensores a identificar debilidades críticas podrían acabar ayudando a los atacantes a explotarlas.
Debemos esperar que los defensores tengan menos tiempo entre la divulgación técnica y el intento de explotación de ciertas vulnerabilidades.
3. La seguridad del código abierto necesita más que hallazgos automatizados
La divulgación de la PHP Foundation también ilustra un desafío estructural.
Un sistema de IA potente puede identificar un posible error.
Pero alguien tiene que determinar si el hallazgo es real.
Alguien tiene que entender su causa raíz, desarrollar una corrección compatible, probar las versiones afectadas, coordinar a los distribuidores y preparar el ecosistema.
Esas actividades requieren personas con un conocimiento profundo del software.
Si la IA aumenta el volumen de hallazgos de vulnerabilidades, la presión sobre los equipos pequeños de mantenedores no hará más que crecer.
La solución a largo plazo no puede limitarse a generar más informes.
También necesitamos financiación sostenible, mejor infraestructura de pruebas, divulgación coordinada y formas más eficaces de validar las correcciones de seguridad.
Reflexiones finales
PHP2Shell es una divulgación de vulnerabilidad grave.
Dos debilidades críticas en el intérprete de PHP pueden permitir la ejecución remota de código sin autenticación y la divulgación de memoria en las condiciones afectadas.
Las vulnerabilidades llegan por debajo de los frameworks de aplicación y pueden comprometer sistemas incluso cuando los desarrolladores han seguido prácticas de programación segura.
La recomendación inmediata es sencilla:
Identifica las instalaciones de PHP afectadas, aplica las actualizaciones de seguridad oficiales, verifica los workers en ejecución e investiga la actividad sospechosa.
Pero la lección a más largo plazo es más interesante.
Durante años, la complejidad de encontrar y explotar ciertas vulnerabilidades de corrupción de memoria actuó como una barrera práctica.
La investigación de seguridad asistida por IA puede estar reduciendo esa barrera.
Eso no significa que la explotación automatizada se haya vuelto trivial.
Significa que algunos ataques que antes exigían un esfuerzo excepcional ahora pueden estar al alcance de equipos más pequeños con herramientas potentes.
Los defensores tienen que adaptarse en consecuencia.
Deberíamos dejar de tratar el descubrimiento, la explotabilidad y la remediación de vulnerabilidades como actividades aisladas.
Una vulnerabilidad no queda resuelta solo porque exista un aviso.
No es necesariamente explotable solo porque haya un componente vulnerable instalado.
Y no queda remediada solo porque alguien informe de que se desplegó un parche.
La seguridad exige entender el contexto técnico completo y verificar el resultado real.
PHP2Shell es otro recordatorio de que lo que nos protege no es la complejidad del software, sino nuestra capacidad de entenderlo, probarlo y asegurarlo.
Preguntas frecuentes
¿Qué es PHP2Shell?
PHP2Shell es el nombre colectivo de dos vulnerabilidades críticas del runtime de PHP, CVE-2026-109618 y CVE-2026-109619, que implican un manejo inseguro de la memoria y del estado del ciclo de vida de las peticiones.
¿Se puede explotar PHP2Shell sin autenticación?
Sí. Los investigadores demostraron la ejecución remota de código sin autenticación contra despliegues de PHP afectados, incluidas configuraciones de Apache mod_php e instalaciones representativas de CMS.
¿Afecta PHP2Shell a WordPress?
Las instalaciones de WordPress que usan runtimes de PHP vulnerables pueden verse afectadas. El problema está en el propio PHP, no en el código de la aplicación WordPress. La explotabilidad real depende del despliegue y de la ruta de vulnerabilidad aplicable.
¿PHP-FPM evita PHP2Shell?
No. El ciclo de vida de los workers de PHP-FPM impide ciertas rutas demostradas relacionadas con el arranque, pero los investigadores han confirmado la ejecución remota de código a través de rutas que dependen de la aplicación. Las instalaciones de PHP-FPM también deben parchearse.
¿Se está explotando PHP2Shell en ataques reales?
Cloudflare informó de que observó tráfico de ataque dirigido a las vulnerabilidades antes de la divulgación pública. Eso confirma intentos de explotación, pero no un recuento verificado de compromisos exitosos en producción.
¿Puede un WAF evitar PHP2Shell?
Las protecciones de un WAF pueden bloquear técnicas conocidas, pero no remedian por completo las vulnerabilidades del runtime de PHP. Instalar una versión de PHP parcheada sigue siendo esencial.
¿Qué versiones de PHP corrigen PHP2Shell?
Las primeras versiones upstream corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Algunas distribuciones ofrecen parches con backport usando sus propios esquemas de versiones de paquetes.
¿Descubrió una IA PHP2Shell?
La investigación asistida por IA contribuyó de forma sustancial a identificar, desarrollar y validar las rutas de explotación. Investigadores humanos, mantenedores de PHP y organizaciones de seguridad realizaron la investigación, la coordinación y el desarrollo de los parches.
Referencias
- PHP Project — Critical Remote Code Execution Security Advisory, 21 de octubre de 2026
- CVE-2026-109618 — PHP Out-of-Memory Corruption Advisory
- CVE-2026-109619 — PHP Stale Global State Advisory
- Wiz Research — PHP2Shell Technical Analysis
- Calif Research — PHP2Shell
- The PHP Foundation — Today’s PHP Security Release and How We’re Strengthening PHP Security
- Cloudflare — Protections Against PHP2Shell
- OpenAI — Patch the Planet: Coordinated Disclosure of Critical Vulnerabilities
- Netherlands National Cyber Security Centre — PHP2Shell Operational Information
- ENISA — Joint Statement on Critical PHP Vulnerabilities
