Se ha publicado un repositorio de prueba de concepto (PoC) que ofrece herramientas de verificación y un entorno de laboratorio para analizar dos vulnerabilidades críticas de PHP denominadas php2shell. Estas fallas, identificadas como CVE-2026-109618 y CVE-2026-109619, afectan a la función session.upload_progress y podrían permitir la ejecución remota de código bajo ciertas condiciones.

Un repositorio público de prueba de concepto comparte herramientas de verificación y una configuración de laboratorio para probar dos vulnerabilidades críticas de PHP conocidas como php2shell. Se informa que los fallos, rastreados por los investigadores como CVE-2026-109618 y CVE-2026-109619, afectan a la función session.upload_progress de PHP y podrían provocar la ejecución remota de código bajo ciertas condiciones.

El lanzamiento añade detalles técnicos a un problema de seguridad que evoluciona rápidamente. El equipo de seguridad de PHP anunció que una versión de emergencia abordaría dos vulnerabilidades críticas, cada una calificada con 9.2 bajo CVSS v4.0, e instó a los usuarios a prepararse para la actualización.

Su aviso programó el lanzamiento para el 21 de octubre a las 14:00 UTC. En el momento de escribir esto, esa hora de lanzamiento aún no ha pasado, por lo que el aviso oficial de PHP no ha confirmado los detalles técnicos, las versiones afectadas o las compilaciones corregidas descritas en el repositorio de investigación.

El repositorio indica que las vulnerabilidades afectan a las versiones de PHP desde la 5.4.0 hasta la 8.5.11. Enumera las versiones PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12 como versiones corregidas planificadas, pero como administrador deberías verificar esto con el aviso de lanzamiento del equipo de PHP antes de actualizar. El aviso anticipado del proyecto PHP confirma la gravedad y el lanzamiento planificado, pero no esos detalles de versión.

; Immediate mitigation (does NOT fix all attack paths)
session.upload_progress.enabled = Off
session.use_only_cookies = On 

Exploit PoC de la Vulnerabilidad PHP2Shell

El análisis del investigador describe varias rutas hacia la ejecución de código, en lugar de un único exploit universal que funcione contra cualquier sitio web PHP. Una cadena combina la inyección de archivos de sesión con un fallo de inclusión de archivos locales en una aplicación.

Según el repositorio, esta ruta depende de que el progreso de carga esté habilitado y de un fallo en la aplicación que permita la inclusión de un archivo local. Un error de inclusión de archivos locales ocurre cuando se puede hacer que una aplicación cargue un archivo de su servidor de una manera no intencionada.

El repositorio afirma que el manejador de progreso de carga de PHP almacena un nombre de archivo proporcionado en los datos de sesión sin validarlo. También informa que un identificador de sesión enviado en un cuerpo POST puede saltarse la configuración session.use_only_cookies, cuya finalidad es restringir cómo se aceptan los ID de sesión.

Estas afirmaciones describen cómo una debilidad en el manejo de sesiones de PHP podría combinarse con un error de aplicación independiente. No debes interpretarlas como que cualquier sitio PHP es inmediatamente explotable a través de esta ruta.

Un segundo problema reportado involucra un use-after-free, un error de memoria que puede ocurrir cuando el software continúa utilizando datos después de que estos han sido liberados. El investigador afirma que la reentrada en un destructor var_destroy puede desencadenar esta condición e informa haberlo confirmado con AddressSanitizer, una herramienta utilizada para encontrar errores de memoria.

El repositorio también describe un estado del serializador de PHP-FPM que puede persistir entre solicitudes, y un desajuste del manejador que puede causar que un destructor se ejecute después de que falle la deserialización. Los investigadores dicen que algunas de estas rutas necesitan condiciones adicionales, como un gadget de aplicación o acceso a un archivo local.

Estas afirmaciones técnicas siguen siendo las del proyecto de investigación independiente hasta que puedan compararse con el aviso completo y los parches de PHP. Los equipos de seguridad deben evitar tratar cada ruta enumerada como confirmada independientemente para todas las versiones o configuraciones. El repositorio de verificación del proyecto proporciona la descripción general de la investigación y los archivos de laboratorio. Su propósito declarado es la realización de pruebas controladas, no su uso contra sistemas sin permiso.

PHP hace funcionar una amplia gama de sitios web y aplicaciones, por lo que un fallo en su manejo central de sesiones podría afectar a muchos tipos de despliegues. El riesgo puede ser mayor cuando una aplicación ya tiene una debilidad de inclusión de archivos o un comportamiento de deserialización inseguro.

Como ha demostrado la cobertura de seguridad previa de PHP, los errores de memoria en los componentes de PHP pueden tener un impacto grave, aunque las causas técnicas difieran. Este informe también cubre otro ejemplo de riesgo a nivel de aplicación en las vulnerabilidades de ScriptCase.

La puntuación reportada de 9.2 señala un problema crítico, pero no te dice si un servidor en particular está expuesto. Eso depende de la versión de PHP, la configuración, el comportamiento de la aplicación y de si existen las condiciones necesarias para una cadena específica. El repositorio público incluye un laboratorio de PHP-FPM y Nginx para pruebas. Las organizaciones deben usar tales entornos solo para validación autorizada y no deben ejecutar código de prueba de concepto contra sistemas de producción.

Debes hacer un inventario de las instalaciones de PHP en servidores web, contenedores y entornos de hosting gestionado, y luego revisar el lanzamiento oficial de seguridad de PHP para conocer las versiones afectadas y corregidas confirmadas. Una vez que haya una actualización adecuada disponible, aplícala rápidamente y reinicia PHP-FPM o el servicio web correspondiente para que los nuevos binarios surtan efecto.

Los sistemas que ejecuten ramas de PHP que han llegado al final de su vida útil requieren atención especial porque podrían no recibir correcciones oficiales. El repositorio identifica a PHP 5.x, 7.x, 8.0 y 8.1 como no compatibles, pero tú y tu equipo deberíais confirmar el estado de soporte con el proyecto PHP.

El investigador enumera la desactivación de session.upload_progress y la configuración de session.use_only_cookies en On como salvaguardas temporales. Estos ajustes pueden reducir la exposición a algunas de las rutas reportadas, pero el repositorio advierte que no solucionan todas las cadenas de ataque.

No son un sustituto de una actualización de seguridad. Revisa tus aplicaciones en busca de problemas de inclusión de archivos locales y deserialización insegura, y comprueba los registros del servidor para detectar solicitudes inusuales relacionadas con el manejo de sesiones de PHP mientras se revisa el aviso oficial.

Por ahora, lo mejor es tratar la prueba de concepto pública como una señal para prepararte y validar de forma segura. El siguiente paso clave es comparar las afirmaciones de la investigación con los detalles del lanzamiento oficial de PHP, y luego parchear los sistemas afectados tan pronto como el proyecto publique las versiones corregidas confirmadas.