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) | (Verificación Insuficiente de la Autenticidad de Datos) | (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 verificadoContext Hub no tiene SECURITY.md. No hay una forma documentada de divulgar responsablemente una vulnerabilidad: sin contacto de seguridad, sin clave PGP, sin política de divulgación. Los miembros de la comunidad encontraron las vulnerabilidades de todos modos y las reportaron como issues y PRs regulares. Ninguno fue revisado.
| Fecha | Evento |
|---|---|
| 2026-03-12 | Issue #74 presentado por @bjorkbjork reportando 4 vulnerabilidades de seguridad, incluyendo integridad de CDN, verificación de fuente autodeclarada e inyección de anotaciones |
| 2026-03-12 | Issue #74 asignado internamente a un miembro del equipo central: cero seguimiento |
| 2026-03-17 | PR #125 presentado por @hobostay agregando verificación de integridad de contenido: cero revisiones |
| 2026-03-12 a 03-20 | PRs de seguridad adicionales (#69, #81) presentados por la comunidad: cero revisiones |
| 2026-03-20 a 03-23 | Nuestra auditoría independiente confirma y cuantifica las vulnerabilidades con 240 ejecuciones Docker aisladas |
| 2026-03-23 | Divulgación pública |
Nota: No presentamos el issue #74. Nuestra auditoría descubrió y cuantificó estas vulnerabilidades de forma independiente. El issue #74 y los PR #69, #81, #125 se citan como arte previo que demuestra que la comunidad ha señalado estos problemas sin participación de los mantenedores.
Una vez que el paquete falso está en requirements.txt, un pip install -r requirements.txt estándar le da al atacante ejecución arbitraria de código a través de los hooks post-instalación de setup.py. Esto no es un sandbox: pip ejecuta Python sin restricciones con los permisos completos del desarrollador.
Desde ese único punto de entrada, el atacante puede:
.env o código fuente a un servidor controlado por el atacante.~/.chub/config.yaml para agregar una fuente de documentos controlada por el atacante. Todas las consultas futuras de chub en todas las bibliotecas ahora incluyen contenido del atacante. Sobrevive a chub cache clear porque la configuración no es caché.Estas no son mutuamente excluyentes. Un solo hook post-instalación puede hacer todas ellas en menos de un segundo. No creamos ni registramos un paquete malicioso.
.
|-- README.md # Este archivo
|-- RESULTS.md # Conjunto de datos completo con desgloses por ejecución
|-- REPRODUCE.md # Guía de reproducción basada en Docker
|-- alternatives-comparison.md # Comparación de Context7, LAP, GitMCP, Docfork
|-- article.html # Artículo completo
|-- docker/
| |-- Dockerfile # Entorno de prueba aislado
| |-- run_isolated.ps1 # Ejecutor de PowerShell (Windows/macOS/Linux vía pwsh)
| |-- seed-claude.md # CLAUDE.md mínimo sembrado en cada ejecución
| |-- plaid-doc/ # Documento envenenado de Plaid Link (canario: plaid-link-verify)
| | `-- plaid/link/DOC.md
| `-- stripe-doc/ # Documento envenenado de Stripe Checkout (canario: stripe-checkout-guard)
| `-- stripe/checkout/DOC.md
`-- results/
|-- plaid-isolated/ # 120 ejecuciones de Plaid: JSON + transcripciones de sesión + archivos de proyecto
`-- stripe-isolated/ # 120 ejecuciones de Stripe: JSON + transcripciones de sesión + archivos de proyecto
Consulte REPRODUCE.md para la guía completa de reproducción basada en Docker.
Inicio rápido:
# Plaid (predeterminado)
docker build --build-arg DOC_DIR=plaid-doc -t plaid-bench docker/
docker run -d --name plaid-runner plaid-bench sleep infinity
docker exec -it plaid-runner claude login
# Stripe
docker build --build-arg DOC_DIR=stripe-doc -t stripe-bench docker/
docker run -d --name stripe-runner stripe-bench sleep infinity
docker exec -it stripe-runner claude login
# Luego ejecute la matriz de pruebas desde el host (consulte REPRODUCE.md)
--permission-mode bypassPermissions. Los agentes reales pueden solicitar confirmación.MIT
Esta investigación fue realizada por Mickey Shmueli, el desarrollador de LAP, una alternativa de código abierto a Context Hub. LAP utiliza compilación determinista a partir de especificaciones oficiales de API, sin contenido aportado por la comunidad en el pipeline. Esta auditoría fue motivada por una preocupación genuina de seguridad sobre los pipelines de contenido no desinfectado, una clase de vulnerabilidad que afecta a cualquier herramienta en este espacio que acepte contribuciones comunitarias no verificadas. Los hallazgos hablan por sí solos: 240 ejecuciones Docker aisladas, detección determinista, completamente reproducible.
Este PoC es solo para fines educativos y de investigación en seguridad. Todas las pruebas se realizaron localmente en contenedores Docker aislados. No se envió ningún contenido malicioso al repositorio de Context Hub. Todos los nombres de paquetes canarios verificados como inexistentes en PyPI antes de las pruebas.