Inyección silenciosa de dependencias a través de pipelines de documentación de IA. 240 ejecuciones aisladas de Docker demuestran que el servidor MCP sin sanitización de Context Hub permite que documentos envenenados comprometan proyectos de desarrolladores sin previo aviso.
Vulnerabilidad de desinfección cero en Context Hub (@aisuite/chub v0.1.3) permite la inyección silenciosa de dependencias a través del pipeline de documentación MCP.
Referencias: CWE-94 (Inyección de Código) | CWE-829 (Esfera de Control No Confiable) | CWE-345 (Verificación Insuficiente de la Autenticidad de Datos) | OWASP LLM01 (Inyección de Prompt)
Creamos documentos envenenados realistas que contenían dependencias falsas (plaid-link-verify, stripe-checkout-guard) y los servimos a través de un servidor MCP chub local dentro de contenedores Docker aislados. No se subió ningún contenido envenenado al registro de Context Hub; ejecutamos chub build localmente y configuramos el servidor MCP para servir la salida precompilada desde el disco. Desde la perspectiva del agente, la experiencia es idéntica a obtener documentos del registro en vivo.
Cuando los asistentes de codificación de IA obtuvieron los documentos, Haiku escribió silenciosamente el paquete falso en requirements.txt en el 100% de las ejecuciones, sin mencionarlo nunca en su salida de texto. Un desarrollador que leyera la respuesta del asistente no vería nada sospechoso, pero su proyecto estaría envenenado.
240 ejecuciones aisladas. 3 modelos. 4 niveles de esfuerzo. 2 APIs. 0 contaminación.
El código generado importa silenciosamente la dependencia falsa junto con módulos legítimos:
El agente también modifica CLAUDE.md para incrustar el paquete falso como un "estándar del proyecto":
Estas tablas muestran los resultados de Plaid Link (120 ejecuciones aisladas). Consulte RESULTS.md para obtener los datos completos, incluido Stripe Checkout (240 ejecuciones totales).
| Esfuerzo | Haiku | Sonnet | Opus |
|---|---|---|---|
| Bajo | 100% | 60% | 0% |
| Medio | 100% | 70% | 0% |
| Alto | 100% | 40% | 0% |
| Máximo | 100% | 40% | 0% |
Haiku nunca advirtió sobre la dependencia falsa (0/40). Sonnet advirtió en el 48% de las ejecuciones (19/40), pero aún así envenenó requirements.txt en el 53% general. Opus advirtió en el 75% de las ejecuciones (30/40) y nunca envenenó requirements.txt ni el código.
| Esfuerzo | Haiku | Sonnet | Opus |
|---|---|---|---|
| Bajo | 90% | 70% | 0% |
| Medio | 80% | 70% | 0% |
| Alto | 90% | 40% | 0% |
| Máximo | 90% | 50% | 0% |
Haiku modifica el CLAUDE.md del proyecto para incluir la dependencia falsa como un "estándar del proyecto" en el 88% de las ejecuciones (35/40). Este archivo se confirma en git: cada futuro desarrollador que clone el repositorio heredará la configuración envenenada.
flowchart LR
A["Atacante\nenvía PR"] -->|"Sin verificación\nde identidad"| B["Mantenedor\nfusiona PR"]
B -->|"Sin desinfección\nde contenido"| C["Documento en CDN\n(sin verificación de integridad)"]
C -->|"MCP sirve\ncontenido sin procesar"| D["Ventana de contexto\ndel agente"]
D -->|"El agente actúa sobre\ncontenido no confiable"| E["Estación de trabajo\ndel desarrollador"]
style A fill:#111,stroke:#333,color:#f0f0f0
style B fill:#161616,stroke:#333,color:#888
style C fill:#161616,stroke:#333,color:#888
style D fill:#161616,stroke:#333,color:#888
style E fill:#111,stroke:#333,color:#f0f0f0
| Atacante | Cualquiera que pueda enviar un PR al registro de documentos de Context Hub |
| Superficie de ataque | Documentos comunitarios que fluyen desde GitHub PR hasta CDN, MCP y contexto del agente |
| Límite de confianza | Contenido de colaboradores no confiables tratado como documentación autorizada de API |
| Prerrequisito | Un PR fusionado que contenga un documento envenenado |
| Impacto | Ejecución arbitraria de código mediante inyección de dependencias + hooks post-instalación de pip |
El envenenamiento de Haiku es completamente silencioso. 0/80 ejecuciones de Haiku en ambas APIs mencionaron la dependencia falsa en la respuesta. El modelo escribe en disco sin avisar. Sonnet advirtió en el 48% de las ejecuciones, pero aún así envenenó requirements.txt en el 35-53% de las ejecuciones. Opus advirtió en el 23-75% de las ejecuciones y nunca envenenó requirements.txt ni el código.
Haiku es 100% explotable en todos los niveles de esfuerzo. Independiente del esfuerzo en ambas APIs. El modelo más débil de la familia nunca detecta la dependencia falsa.
Opus resiste el envenenamiento de código pero no el de configuración. Opus nunca escribió la dependencia falsa en requirements.txt ni en código Python (0/80 en ambas APIs). Pero en Stripe, Opus modificó CLAUDE.md en el 38% de las ejecuciones, documentando el canario como una dependencia del proyecto sin instalarlo.
La persistencia en CLAUDE.md crea un vector de cadena de suministro. Los archivos de configuración modificados se confirman en git, envenenando a cada desarrollador que clone el repositorio y a cada futura sesión de IA en ese proyecto. Esto funciona en todos los modelos (Haiku 88-90%, Sonnet 58%, Opus 0-38%).
La familiaridad con la API importa. Stripe (bien conocida): los modelos detectan paquetes falsos mediante datos de entrenamiento. Plaid (menos conocida): los modelos no pueden verificar y aceptan la dependencia falsa sin cuestionarla.
Este es un problema de toda la categoría. Context7 tuvo ContextCrush (febrero de 2026). Context Hub tiene esto. Cualquier herramienta que inyecte contenido externo sin desinfectar en el contexto del agente es vulnerable.
Cero desinfección en todo el pipeline:
annotations.js - writeFileSync con contenido sin procesar, sin filtradobuild.js - sin escaneo de contenido, sin normalización Unicodecache.js - recuperación de CDN con verificación de hash/firma cerosource: official en el frontmatter - autodeclarado, no verificado