PHP2Shell, explicado: cómo dos fallas en el núcleo de PHP pasaron de una auditoría en 2024 a un parche de emergencia

PHP es el lenguaje que ejecuta del lado del servidor buena parte de la web, desde gestores de contenido como WordPress hasta tiendas en línea y servicios gubernamentales. Su intérprete procesa cada petición HTTP en un ciclo que reserva memoria, analiza los datos que envía el cliente, ejecuta la aplicación y luego limpia todo para dejar el proceso listo para la siguiente. PHP2Shell, el nombre con el que se conoce al par de vulnerabilidades CVE-2026-109618 y CVE-2026-109619, ataca justamente ese ciclo, y por eso afecta a casi cualquier instalación que atienda tráfico web, sin importar qué aplicación corra encima.

La primera falla aparece cuando una petición agota el límite de memoria configurado en un momento muy concreto. PHP interrumpe el trabajo y puede dejar estructuras internas a medio construir; después, la rutina de limpieza las trata como si fueran válidas y termina corrompiendo memoria. La segunda tiene que ver con la persistencia de estado entre peticiones: un error fatal en el lugar equivocado puede dejar referencias internas apuntando a memoria que pertenecía a una petición anterior y que ya fue liberada, de modo que una petición posterior atendida por el mismo proceso la reutiliza. Son dos ejemplos clásicos de corrupción de memoria, con la particularidad de que residen en la gestión de memoria y en el manejo de errores, dos piezas que toca prácticamente cada petición. Según php.net, en Apache con mod_php se demostró la ejecución remota de código con una petición sin autenticar antes de que corra el código de la aplicación, y también se confirmó en PHP-FPM a través de rutas de la aplicación.

La historia empieza bastante antes de octubre. La PHP Foundation cuenta que en 2024 el lenguaje pasó por su primera auditoría externa en años, financiada por la Sovereign Tech Agency alemana, organizada por OSTIF y ejecutada por Quarkslab. Al corregir uno de los hallazgos, un desarrollador del núcleo detectó los primeros indicios del problema de memoria que hoy es CVE-2026-109618. En ese momento se teorizó un posible exploit, pero no se encontró una vía concreta. El equipo de seguridad desarrolló varias soluciones, cada una con costos en compatibilidad, en riesgo de denegación de servicio o en la necesidad de cambiar muchas extensiones de terceros, y, como decidía por consenso, el trabajo se detuvo y reinició durante meses. La propia fundación califica esa demora como un fallo estructural, causado por su proceso de decisión y por la falta de recursos.

El panorama cambió el 11 de agosto de 2026, cuando un investigador de la firma Calif, que auditaba PHP dentro del programa Patch the Planet, reportó una ejecución remota de código con la misma causa raíz. OpenAI reportó la misma causa ese mismo día, y Wiz y de nuevo OpenAI aportaron más vectores de ataque en las semanas siguientes. A partir de ahí la corrección se convirtió en la prioridad del equipo de seguridad financiado por la fundación. La fundación también describe cómo la investigación asistida por IA multiplicó los reportes que recibe y cómo usa herramientas de varias empresas para validarlos, con la aclaración de que una persona toma cada decisión y trabaja cada parche.

La divulgación coordinada estaba prevista para el 22 de octubre, pero el 20 de octubre los identificadores CVE se filtraron en foros y redes sociales. El proyecto publicó ese mismo día un aviso anticipado y adelantó la publicación al 21 de octubre a las 14:00 UTC. En las horas siguientes circuló un video de prueba de concepto publicado por error y luego borrado, y Chainguard distribuyó imágenes con el parche antes de la hora acordada, según la fundación. Amazon informó después que su red de señuelos registró un intento de explotación el 17 de octubre, antes de cualquier divulgación, y que tras la publicación del parche la explotación pasó a ser amplia.

Para quien administra servidores, el aviso oficial es claro en que solo actualizar resuelve el problema: las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35, las ramas 8.1 y anteriores dependen de distribuciones o proveedores con soporte extendido, y las medidas de configuración solo reducen la exposición a algunas rutas de ataque. Amazon recomienda además buscar indicios de compromiso desde el 17 de octubre. Como análisis, el episodio deja dos preguntas abiertas para el ecosistema: cómo financiar el trabajo de seguridad de un componente del que dependen tantas organizaciones, y cómo sostener la divulgación coordinada cuando una filtración o un proveedor que se adelanta reducen a horas el margen de los defensores.