PHP publica los parches de PHP2Shell y Amazon detecta un intento de explotación cuatro días antes de la divulgación

El proyecto PHP publicó el miércoles 21 de octubre las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen las dos vulnerabilidades críticas cuyo aviso anticipado cubrimos el día anterior. Lo que cambió desde entonces es sustancial: ahora se conocen los detalles técnicos de las fallas, ya existen versiones corregidas y Amazon afirma que detectó un intento de explotación el 17 de octubre, cuatro días antes de que el problema se hiciera público, y que el conjunto de vulnerabilidades, conocido como PHP2Shell, ya se explota de forma amplia.

Las dos fallas son CVE-2026-109618 y CVE-2026-109619, ambas con una puntuación de 9.2 en CVSS 4.0. La primera está en el manejo de la falta de memoria: si una petición alcanza el límite memory_limit en un momento concreto, PHP puede dejar datos internos inicializados a medias y luego tratarlos como válidos durante la limpieza, lo que corrompe la memoria. La segunda tiene que ver con estado global que sobrevive a la petición que lo creó: tras un error fatal, un proceso puede quedarse con referencias a memoria ya liberada y reutilizarlas al atender la petición siguiente. Según el aviso de php.net, están en riesgo todas las instalaciones que sirven peticiones web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo considera que el riesgo es mayor con mod_php, donde se demostró un ataque en el que una petición sin autenticar dispara la falla antes de que se ejecute cualquier código de la aplicación.

El calendario se alteró por una filtración. De acuerdo con el relato de la PHP Foundation, hacia las 15:00 UTC del 20 de octubre los dos identificadores CVE empezaron a circular en foros y redes sociales, con una hora de publicación y una puntuación equivocadas, aunque sin detalles técnicos. El proyecto adelantó el aviso previo y movió la publicación del 22 al 21 de octubre a las 14:00 UTC, un día antes de lo previsto, para dar tiempo a que las distribuciones terminaran de empaquetar el arreglo. La fundación añade que una de las firmas que había reportado las fallas, Calif, publicó por error un video con su prueba de concepto que luego fue borrado pero siguió circulando, y que Chainguard publicó imágenes con el parche a las 07:41 UTC del 21 de octubre, más de seis horas antes de la fecha coordinada, lo que permitía estudiar el arreglo en forma binaria antes que el resto de usuarios.

El dato más relevante para quienes administran servidores llegó de Amazon. En una publicación firmada por CJ Moses, el equipo de inteligencia de amenazas de la empresa afirma que su red de señuelos MadPot registró un intento de explotación de PHP2Shell el 17 de octubre desde una dirección asociada a una red comercial de anonimización, y aclara que no sabe cómo obtuvo el atacante la información antes de la divulgación. Amazon añade que el 21 de octubre, entre las 02:00 y las 08:00 UTC, observó más intentos con cargas e infraestructuras distintas, lo que sugiere varios actores, y que no está claro si alguno habría tenido éxito contra sistemas reales. Tras la publicación del parche, según la misma fuente, aparecieron nuevas pruebas de concepto en cuestión de horas, y la compañía concluye que PHP2Shell se explota ya de forma amplia. Por eso recomienda investigar posibles compromisos desde el 17 de octubre y no desde la fecha del aviso. Cloudflare, por su parte, informó que desde las 03:02 UTC del 21 de octubre sus clientes con el firewall de aplicaciones web, incluido el plan gratuito, quedaron protegidos por defecto con reglas específicas, y que observó tráfico de ataque contra sus clientes.

La única solución completa, según php.net, es actualizar. Las ramas 8.1 y anteriores ya no reciben versiones del proyecto, aunque el equipo de seguridad publicó adaptaciones mínimas del código para 7.4, 8.0 y 8.1 dirigidas a quien compila desde el código fuente, y algunas distribuciones ofrecen sus propias correcciones. Para quien no pueda actualizar de inmediato, el aviso describe medidas que reducen la exposición a rutas de ataque concretas, como desactivar session.upload_progress.enabled o reducir post_max_size, pero advierte expresamente que no hacen segura una instalación.

Como análisis, el caso confirma la tendencia que la propia Amazon describe: el tiempo entre la publicación de un parche y la aparición de un exploit funcional se mide ya en horas, en parte porque el análisis asistido por IA abarata convertir un parche en un ataque. Queda por saber cuántos servidores siguen sin actualizar, en especial los que ejecutan ramas sin soporte, y si los intentos detectados antes de la divulgación derivaron en compromisos reales.