PHP2Shell: Cuando falla el motor de ejecucion de un lenguaje entero

El equipo de seguridad de PHP liberó el 21 de octubre de 2026 parches de emergencia para dos vulnerabilidades de ejecucion remota de codigo (RCE) que afectan virtualmente a todo servidor PHP activo en internet. Las vulnerabilidades, catalogadas como CVE-2026-109618 y CVE-2026-109619 y bautizadas por la comunidad como "PHP2Shell", residen directamente en el motor de runtime del PHP — no en ningun framework o CMS — lo que significa que incluso una pagina de "Hola Mundo" de tres lineas en PHP puede ser comprometida remotamente sin autenticacion, incluso cuando el codigo de la aplicacion esta completamente seguro.

El descubrimiento fue hecho de forma colaborativa por investigadores de seguridad de las empresas Wiz, Calif y OpenAI, y la gravedad del problema fue evaluada como 9.2 en la escala CVSS v4.0. El alcance es tan amplio que la NSA de EE. UU. recomendo que los sitios incapaces de aplicar el parche inmediatamente desconectaran sus servidores, mientras el Centro Nacional de Ciberseguridad del Reino Unido (NCSC) emito una alerta similar a las organizaciones británicas.

Que paso

Todo comenzo con una fuga en la noche del 20 de octubre. Un mensaje en Hacker News anuncio que dos vulnerabilidades RCE en PHP, clasificadas como CVSS 10.0, serian divulgadas el 22 de octubre. El mensaje no proporcionaba evidencia tecnica, limitandose a una fuente citada como "confia, hermano". El equipo de seguridad de watchTowr confirmo que la informacion era real, que los hallazgos estaban bajo embargo y que no podia revelar detalles antes de la fecha acordada. PHP publico su propio aviso esa misma noche, anticipando la fecha de lanzamiento para el 21 de octubre — un dia antes de lo planeado — con la advertencia de que podria liberar correcciones aun mas si surgiera evidencia de explotacion activa.

La confirmacion llego a las 14:00 UTC: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 fueron lanzados con los parches. La desarrolladora principal de PHP Gina Peter Banyard advirtio que ninguna mitigacion parcial bloquearia completamente los ataques, y que la actualizacion era la unica defensa permanente.

Los mecanismos de explotacion

Las dos vulnerabilidades pertenecen a la categoria Use-After-Free (CWE-416), pero explotan mecanismos diferentes dentro de PHP.

La CVE-2026-109618 es causada por corruption de memoria cuando el interprete enfrenta una situacion de agotamiento de memoria (OOM). Cuando la memoria se agota, PHP aborta la solicitud usando una funcion longjmp(). Si esto ocurre mientras los datos internos de la solicitud no han sido totalmente inicializados, el procedimiento de cierre trata datos invalidos como si fueran validos. En configuraciones con Apache mod_php, esto es particularmente peligroso: el procedimiento de cierre es llamado incondicionalmente, incluso si la inicializacion de la solicitud falla, y el analisis automatico del cuerpo de la solicitud puede agotar el limite de memoria antes de que cualquier codigo de aplicacion empiece a ejecutarse. Un exploit demostrado funciona con configuraciones estandar de memoria y limites de entrada.

La CVE-2026-109619 implica un estado global obsoleto en la memoria. La vulnerabilidad permite que un atacante lea la memoria de un proceso worker de PHP — incluyendo contraseñas, tokens de autenticacion, claves de API y certificados de solicitudes anteriores — sin antes lograr la ejecucion remota de codigo. El camino de explotacion confirmado pasa por session.upload_progress.enabled, que esta activado por defecto y puede acceder al manejo de sesiones antes de que PHP termine de configurar una solicitud.

Ambos bugs estan presentes en el codigo desde PHP 5.4 — mas de una decada de codigo. La clase de vulnerabilidad que los engloba (Use-After-Free) fue identificada como area de preocupacion decadas atras, pero ninguna accion fue tomada en ese momento porque no se creia que un exploit seria viable en el contexto de PHP.

El impacto en internet

La proporcion del problema es dificil de sobrestimar. Segun datos del W3Techs, el PHP es usado en el 69,3% de los sitios web cuya lenguaje de servidor es conocida — lo que significa que aproximadamente el 70% de toda la internet publica esta expuesta. Investigadores de Mallory analizaron mas de 7 millones de sitios web PHP y descubrieron que el 46,1% de los sitios que revelan su version de PHP estan ejecutando una version EOL (fin de vida). El investigador de seguridad Silas Cutler estimó que mas de 1,3 millones de hosts expuestos a internet estan potencialmente vulnerables; una busqueda en Shodan hecha por Henk Poley encontro mas de 1,9 millones de hosts.

Las consecuencias fueron inmediatas. Antes incluso de que los parches fueran lanzados, Cloudflare actualizo sus reglas de WAF para mitigar los ataques y ya observaba intentos activos de explotacion. La CERT-EU emito recomendaciones de contencion, y organizaciones en multiples paises tomaron medidas drásticas:

- Gobierno holandes (Overheid.nl): sitio web desconectado preventivamente - Gobierno finlandes: todos los servicios publicos desconectados - Ministerio del Interior frances: todos los sitios desactivados - Plataforma de comunicacion escolar danesa: fuera de linea - Universidades de Viena y Freiburg (Alemania): servicios no disponibles - Wikimedia Foundation: servicios de soporte desactivados - 4chan y Something Awful: sitios offline - Japon: Final Fantasy XIV, Umamusume: Pretty Derby y diversos e-commerce desligados

La NSA reforzó que, si no es posible actualizar inmediatamente, la unica alternativa segura es colocar el sitio fuera de linea.

Que hacer

La actualizacion del runtime para PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35 es la unica solucion completa. Pero el cuadro se complica para administradores con versiones mas antiguas: PHP 8.1 y versiones anteriores ya no reciben mas actualizaciones del proyecto PHP (8.1 ya alcanzo el fin del soporte en noviembre de 2025, y 8.2 llega al EOL el 31 de diciembre de 2026).

El equipo de PHP publico backports de codigo fuente para PHP 7.4, 8.0 y 8.1 para quienes necesitan compilar desde el source o no tienen acceso a un proveedor LTS. Distribuciones Linux que embuten paquetes PHP mas antiguos pueden tener los parches backportados — organizaciones con PHP via paquete de distribucion deben verificar los avisos de sus proveedores.

Las medidas de mitigacion temporal compartidas por el equipo de PHP son parciales y no protegen contra todos los vectores de ataque:

- Para CVE-2026-109618: definir `memory_limit=-1` via php_admin_value en el pool del FPM o configuracion del Apache (no puede ser sobrescrito por la app), `post_max_size` bajo (8M para uploads innecesarios, 32M cuando los uploads son necesarios), y usar limites de container/cgroup con politica que mate solo el worker afectado. No use `RLIMIT_AS` o `RLIMIT_DATA` como substituto — PHP alerta que ellos pueden desencadenar el mismo camino vulnerable. - Para CVE-2026-109619: desactivar `session.upload_progress.enabled=0` y reiniciar todos los workers. En PHP 8.5, tambien definir `fatal_error_backtraces=0`. Sin embargo, desactivar el progreso del upload puede romper funcionalidades legitimas de subida de archivos que dependen del seguimiento de progreso.

La Corelight libero reglas de deteccion open source (Zeek y Suricata) para equipos defensivos que no pueden aplicar parches inmediatamente.

Que significa esto

El PHP2Shell es una de las vulnerabilidades de motor de lenguaje mas ampliamente impactantes jamas descubiertas — comparable en escala al Heartbleed, pero en vez de afectar un protocolo criptografico usado por servidores especificos, golpea el lenguaje de programacion que corre el blog de tu vecino, la tienda online local, el portal del gobierno y el sistema de salud. El hecho de que la clase de bug (Use-After-Free) era conocida hace decadas, pero no fue considerada explotable en PHP, muestra que la seguridad de runtimes interpretados necesita atencion continua, no solo verificaciones puntuales.

El descubrimiento por investigadores de IA (Wiz, OpenAI, Calif) tambien plantea una pregunta en abierto: a medida que los modelos de IA y agentes autonomos se vuelven herramientas de descubrimiento de vulnerabilidades, ¿donde termina el analisis de seguridad legitimo y comienza la generacion de exploits? El propio PHP2Shell fue encontrado por investigadores que usaron IA como parte de su proceso — y la misma IA que descubrio la falla ahora esta ayudando a mitigarla.

Fuentes: BleepingComputer, The Hacker News, CyberSecureFox

✓ Fuentes independientes cruzadas y verificadas antes de la publicación