El equipo de SuperTuxKart anunció el 24 de octubre que exigirá a todos los usuarios establecer una contraseña nueva cuando vuelva su servicio en línea. AWS, por su parte, registró un intento de PHP2Shell el 17 de octubre y más actividad el día 21; no pudo determinar si esos intentos habrían tenido éxito en sistemas reales.

Qué actividad registró AWS

MadPot, la red de honeypots de AWS (sistemas señuelo que registran actividad de ataque), detectó un intento de explotación el 17 de octubre de 2026. AWS identificó más intentos entre las 02:00 y las 08:00 UTC del 21 de octubre, antes de que el embargo terminara a las 14:00 UTC y se publicaran las correcciones de PHP.

Amazon Threat Intelligence describió variaciones en las cargas y en la infraestructura de anonimización empleadas. Según AWS, esa diversidad apuntaba a la participación de varios actores. La compañía no pudo determinar si los intentos habrían funcionado en sistemas reales.

Qué versiones de PHP corrigieron las vulnerabilidades

PHP identificó dos fallos del entorno de ejecución: CVE-2026-109618, relacionado con corrupción de memoria al gestionar una situación de falta de memoria, y CVE-2026-109619, relacionado con el uso de estado interno obsoleto entre solicitudes. El 21 de octubre, el proyecto publicó las versiones corregidas 8.5.12, 8.4.27, 8.3.36 y 8.2.35, una para cada rama correspondiente.

Las instalaciones web afectadas incluyen PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP señaló que mod_php era la configuración con mayor riesgo en la vulnerabilidad demostrada. El proyecto también indicó que las medidas temporales solo reducen la exposición a rutas concretas; actualizar a una versión corregida es la remediación completa.

La cobertura anterior de NeoTeo sobre el papel de la IA y la revisión humana en los fallos de PHP amplía el contexto del hallazgo.

Qué tendrán que hacer los usuarios de SuperTuxKart

En su publicación del 24 de octubre, el equipo de SuperTuxKart dijo que su servicio de complementos en línea estaba desconectado y que no tenía indicios de que su servidor hubiera sido vulnerado. Cuando el servicio vuelva, todos los usuarios deberán establecer una contraseña nueva.

La migración de las cuentas depende de que se complete la reescritura del sistema y una auditoría de seguridad.