PHP2Shell: el fallo de PHP que la IA explotó en horas

La semana en que el parcheo dejó de tener calendario

Dos vulnerabilidades de ejecución remota de código en PHP, con puntaje 9.2 sobre 10 en CVSS v4.0, pasaron de ser un secreto bajo embargo a estar siendo explotadas en la naturaleza en cuestión de horas. Entre el 19 y el 22 de octubre de 2026 se encadenaron al menos seis incidentes de seguridad de alto impacto, y lo que los une no es el daño: es la velocidad. Para un founder, eso rompe una premisa básica: la respuesta a un incidente ya no se planifica con el calendario de un sprint.

PHP2Shell: el fallo que tocó a buena parte de internet

PHP2Shell agrupa CVE-2026-109618 y CVE-2026-109619, dos fallos de ejecución remota de código (RCE) en el motor de PHP. Los encontraron dos equipos: uno de la firma californiana Calif, dentro del programa "Patch the Planet" de OpenAI, y otro de Wiz, la compañía de seguridad en la nube israelí-estadounidense que forma parte de Google Cloud. Ambos usaron modelos de frontera —GPT-5.6 Sol y Gemini 4 Argon— para hallar las vulnerabilidades y construir los exploits.

El detalle incómodo: uno de los dos fallos ya había aparecido en una auditoría que la PHP Foundation hizo en 2024 con financiamiento de la Sovereign Tech Agency. Se descartó porque nadie logró convertir el problema teórico en un exploit real. Convertir teoría en exploit es, justamente, lo que un LLM hace bien.

Según BleepingComputer, los fallos afectan a toda instalación de PHP que sirva peticiones web —PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed— y las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. El mismo medio recuerda que PHP mueve entre el 75% y el 80% de los sitios web y que VirusTotal estima más de 5,1 millones de hosts PHP expuestos.

Recorded Future aporta el mapa de exposición: Modat contó 4.384.302 servicios PHP en 1.886.612 hosts únicos, y cerca del 79% de los que declaran versión corren una rama sin soporte. PHP 7.4, sin soporte desde 2022, suma 878.761 servicios. La mayoría del parque instalado no va a recibir el parche oficial.

El parche llegó después de la filtración, no antes

La divulgación fue casi un manual de lo que no hay que hacer. Un usuario identificado como petecooper publicó los CVE en Hacker News sin saber que existía un embargo. Eso obligó a The PHP Group a adelantar el lanzamiento del jueves 22 al miércoles 21, con el parche todavía sin estar listo. La filtración incluía puntajes CVSS de 10.0 cuando el puntaje real era 9.2.

La PHP Foundation apuntó a Calif por filtrar un video del exploit en acción y a Chainguard por publicar correcciones seis horas antes de que venciera el embargo. Según Recorded Future, Patchstack ya había recibido reportes de explotación activa a las 07:34 UTC del 21 de octubre, horas antes de que saliera la versión corregida, y el CTO de Cloudflare, Dane Knecht, confirmó ataques tempranos contra ambos fallos.

Cuando el parche estuvo disponible, ya había ataques en curso. La NCSC británica pidió actualizar o apagar los sistemas con PHP y, según Techaeris, sitios de gobierno de Países Bajos y Finlandia se cayeron como precaución. Gina Peter Banyard, desarrolladora del core de PHP, fue tajante: ninguna mitigación bloquea los ataques por completo; parchear es la única defensa permanente.

LiteLLM: el ataque que entró por la cadena de suministro

El caso más relevante para una startup que usa IA es LiteLLM, el gateway open source que enruta pedidos entre proveedores de modelos. El 21 de octubre se publicó la versión 1.107.0 con un stealer de credenciales y un backdoor. BleepingComputer reporta que el proyecto acumula 61.800 estrellas en GitHub, 92 millones de descargas mensuales en PyPI y clientes como NVIDIA, Netflix, AT&T y Okta. SecurityWeek estima que los paquetes maliciosos estuvieron en línea unas tres horas y se descargaron más de 49.000 veces.

El vector es lo que importa: el código de la aplicación no se tocó. El ataque vivió entero en el empaquetado. Se agregaron tres archivos —cook.pth, cook.py y sitecustomize.py— al directorio de librerías de Python. Como Python ejecuta las líneas .pth e importa sitecustomize en cada arranque, el payload se disparaba con cualquier inicio del intérprete, usara o no LiteLLM. Recolectaba credenciales de AWS, Azure, Google Cloud, Kubernetes y Docker, claves de API de herramientas de IA, claves SSH, cookies de navegador e historial de shell.

El origen, según la investigación del propio proyecto, fue un token OAuth de GitHub CLI que Claude Code puede incrustar en el cuerpo de una respuesta y que terminó guardado en los logs de LiteLLM. Con esas credenciales, el atacante desactivó protecciones de rama y publicó artefactos firmados desde un repositorio con nombre casi idéntico al legítimo. Wiz observó el uso de las credenciales robadas unas 4,5 horas después de la exfiltración, consultando modelos de Amazon Bedrock: LLMjacking en estado puro. La última versión limpia es 1.106.2.

El resto de la semana: certificados, extorsión y CVEs de 10.0

• eMudhra: Mozilla bloqueó ocho certificados intermedios firmados por la autoridad certificadora india eMudhra después de que un investigador anónimo reportara que usaba claves privadas de calidad ridícula: números como "115", "56" y "4". El investigador Scott Helme señaló que con un solo prompt Claude recuperó las claves privadas de los certificados intermedios. eMudhra anunció su retiro del negocio de certificados SSL/TLS.
• Railway: al día siguiente, el proveedor de nube reportó que atacantes accedieron y descifraron variables de entorno de su plataforma, donde suelen vivir credenciales de bases de datos y claves de API. Dijo creer que era parte de un esfuerzo dirigido a comprometer empresas que ofrecen inferencia de IA.
• GitLab: el 12 de octubre advirtió de un fallo de severidad máxima en el parseo de expresiones regulares de su CI/CD, con CVSS 10.0, y el 21 de octubre sumó otro desbordamiento de entero en el mismo componente, también 10.0. Los tres reportes llegaron por su programa de bug bounty en HackerOne.
• PingCAP / TiDB: el grupo de extorsión FulcrumSec dijo haber exfiltrado 10,6 TB de datos y publicó un torrent con 200 GB como "primera etapa". Entre lo expuesto, claves de acceso de AWS dentro de tickets de Jira y logs sin censurar con claves de API de OpenAI, Anthropic, Gemini y xAI.
• Kernel de Linux: la Zero Day Initiative de Trend Micro reportó varios CVE de severidad alta a la lista de correo pública en lugar de la privada, en la noche del 21 al 22 de octubre.

¿Por qué el tiempo entre el fallo y el exploit se derrumbó?

Un LLM convierte una descripción teórica en un exploit funcional. El flujo es casi mecánico: se anuncia un parche, alguien apunta un agente al repositorio, el agente lee los diffs hasta encontrar el cambio que parece una corrección de seguridad, retrocede hasta la vulnerabilidad y sigue el rastro hasta un exploit. Como resume el análisis original, el momento en que anuncias un parche debería considerarse la última fecha posible en que el exploit completo no está circulando.

Eso no significa que todo lo que produce la IA sirva. El investigador LiveOverflow señala que los LLM generan "exploit slop" que no prueba nada y no funciona. Pero el argumento decisivo es otro: pueden existir 10.000 exploits malos y uno solo que funcione, y con ese alcanza. La escasez ya no está en generar intentos, sino en distinguir el bueno entre el ruido, y eso sigue requiriendo criterio técnico.

¿Qué significa esto para tu startup?

Tu superficie de riesgo ya no es tu código. PHP2Shell es un fallo del lenguaje, no de tu aplicación: Recorded Future advierte que incluso sitios con código seguro quedan expuestos porque la explotación depende del runtime y de la configuración del servidor. Si tu producto corre sobre un CMS, un framework o un contenedor que no controlas, la seguridad de tu código no te salva.

La cadena de suministro es el camino más corto hacia tus secretos. LiteLLM no fue hackeado en su código, sino en su pipeline de publicación. Un solo paquete comprometido puede darle al atacante la capacidad de empujar código malicioso hacia abajo. Y la ventana de reacción es de horas, no de días.

Acciones concretas para esta semana

• Inventaría tus versiones de PHP. Si corres PHP 8.2 o superior, actualiza a 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Si estás en 8.1 o anterior no habrá parche oficial: migra o busca backports de tu proveedor. Ojo con contenedores, paneles tipo cPanel o Plesk y appliances de proveedor, que suelen quedar atrás.
• Fija dependencias por digest, no por tag. LiteLLM publicó imágenes con los tags latest, main-latest y main-stable apuntando a artefactos maliciosos. Un tag es un puntero móvil; un digest es un compromiso verificable.
• Rota credenciales de forma preventiva. Si en algún entorno corrió LiteLLM 1.107.0, asume compromiso: aísla el host, reconstruye desde un backup limpio y rota todo secreto alcanzable. Borrar solo el directorio del paquete puede dejar el loader activo.
• Revisa qué guardas en tus herramientas internas. El caso PingCAP expuso claves de AWS dentro de tickets de Jira y logs sin censurar con claves de OpenAI, Anthropic, Gemini y xAI. Si tus secretos viven en tickets, wikis o logs, ya están expuestos.
• Define excepciones a la edad mínima de release. Esperar unos días antes de adoptar una versión nueva protege de paquetes maliciosos, pero también retrasa el parche que corrige un fallo en explotación activa. Los parches de seguridad críticos necesitan su propia vía rápida.

Conclusión

La semana del 19 al 22 de octubre de 2026 no fue una anomalía: fue un adelanto. La IA no inventó las vulnerabilidades —muchas las encontraron humanos con métodos tradicionales— pero comprimió el tiempo entre el hallazgo y la explotación, y eso reordena las prioridades. Para un founder, la conclusión es incómoda y simple: la seguridad dejó de ser un proyecto trimestral y pasó a ser una capacidad operativa. No se trata de tener el stack perfecto, sino de saber qué corres, en qué versión, con qué credenciales y cuánto tardas en reaccionar. Si no puedes responder esas cuatro preguntas hoy, ese es el trabajo de esta semana.

Fuentes

• Is this the new cyber normal? (fuente original)
• PHP ships emergency patches for critical PHP2Shell flaws
• PHP2Shell Exploitation: Two Critical PHP Flaws Explained
• PHP2Shell: The Emergency PHP Patch Is Out, and the Real Race Starts Now
• LiteLLM Suspects GitHub Token Leak in AI Gateway Logs Behind Malicious Package Release
• LiteLLM release pipeline hacked to distribute info-stealer malware
• LiteLLM Compromised in Fresh Supply Chain Attack