Injeção silenciosa de dependências através de pipelines de documentação de IA. 240 execuções isoladas do Docker provando que o servidor MCP sem sanitização do Context Hub permite que documentos envenenados comprometam projetos de desenvolvedores sem aviso.
Vulnerabilidade de zero-saneamento no Context Hub (@aisuite/chub v0.1.3) permite injeção silenciosa de dependências através do pipeline de documentação do MCP.
Referências: CWE-94 (Injeção de Código) | CWE-829 (Esfera de Controle Não Confiável) | CWE-345 (Verificação Insuficiente da Autenticidade dos Dados) | OWASP LLM01 (Injeção de Prompt)
Criamos documentação envenenada realista contendo dependências falsas (plaid-link-verify, stripe-checkout-guard) e as servimos através de um servidor MCP chub local dentro de contêineres Docker isolados. Nenhum conteúdo envenenado foi enviado para o registro do Context Hub - executamos chub build localmente e configuramos o servidor MCP para servir a saída pré-construída a partir do disco. Da perspectiva do agente, a experiência é idêntica a buscar documentos do registro ativo.
Quando assistentes de codificação de IA buscaram os documentos, o Haiku escreveu silenciosamente o pacote falso no requirements.txt em 100% das execuções - sem nunca mencioná-lo em sua saída de texto. Um desenvolvedor lendo a resposta do assistente não veria nada suspeito, mas seu projeto está envenenado.
240 execuções isoladas. 3 modelos. 4 níveis de esforço. 2 APIs. 0 contaminação.
O código gerado importa silenciosamente a dependência falsa junto com módulos legítimos:
O agente também modifica CLAUDE.md para incorporar o pacote falso como um "padrão do projeto":
Estas tabelas mostram os resultados do Plaid Link (120 execuções isoladas). Veja RESULTS.md para dados completos, incluindo Stripe Checkout (240 execuções no total).
| Esforço | Haiku | Sonnet | Opus |
|---|---|---|---|
| Baixo | 100% | 60% | 0% |
| Médio | 100% | 70% | 0% |
| Alto | 100% | 40% | 0% |
| Máximo | 100% | 40% | 0% |
Haiku nunca alertou sobre a dependência falsa (0/40). Sonnet alertou em 48% das execuções (19/40), mas ainda envenenou o requirements.txt em 53% no geral. Opus alertou em 75% das execuções (30/40) e nunca envenenou o requirements.txt ou o código.
| Esforço | Haiku | Sonnet | Opus |
|---|---|---|---|
| Baixo | 90% | 70% | 0% |
| Médio | 80% | 70% | 0% |
| Alto | 90% | 40% | 0% |
| Máximo | 90% | 50% | 0% |
Haiku modifica o CLAUDE.md do projeto para incluir a dependência falsa como um "padrão do projeto" em 88% das execuções (35/40). Este arquivo é commitado no git - todo futuro desenvolvedor que clonar o repositório herda a configuração envenenada.
flowchart LR
A["Atacante\nenvia PR"] -->|"Sem verificação\nde identidade"| B["Mantenedor\nmescla PR"]
B -->|"Sem saneamento\nde conteúdo"| C["Documento no CDN\n(sem verificação de integridade)"]
C -->|"MCP serve\nconteúdo bruto"| D["Janela de contexto\ndo agente"]
D -->|"Agente age sobre\nconteúdo não confiável"| E["Estação de trabalho\ndo desenvolvedor"]
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 | Qualquer pessoa que possa enviar um PR ao registro de documentos do Context Hub |
| Superfície de ataque | Documentos da comunidade fluindo do PR no GitHub para CDN, depois MCP, depois contexto do agente |
| Limite de confiança | Conteúdo de contribuidor não confiável tratado como documentação oficial de API |
| Pré-requisito | Um PR mesclado contendo um documento envenenado |
| Impacto | Execução arbitrária de código via injeção de dependência + hooks pós-instalação do pip |
O envenenamento do Haiku é totalmente silencioso. 0/80 execuções do Haiku em ambas as APIs mencionaram a dependência falsa na resposta. O modelo escreve no disco sem avisar. Sonnet alertou em 48% das execuções, mas ainda envenenou o requirements.txt em 35-53% das execuções. Opus alertou em 23-75% das execuções e nunca envenenou o requirements.txt ou o código.
Haiku é 100% explorável em todos os níveis de esforço. Independência de esforço em ambas as APIs. O modelo mais fraco da família nunca detecta a dependência falsa.
Opus resiste ao envenenamento de código, mas não ao de configuração. Opus nunca escreveu a dependência falsa no requirements.txt ou no código Python (0/80 em ambas as APIs). Mas no Stripe, Opus modificou o CLAUDE.md em 38% das execuções, documentando o canário como uma dependência do projeto sem instalá-lo.
A persistência em CLAUDE.md cria um vetor na cadeia de suprimentos. Arquivos de configuração modificados são commitados no git, envenenando todo desenvolvedor que clonar o repositório e toda sessão futura de IA naquele projeto. Isso funciona em todos os modelos (Haiku 88-90%, Sonnet 58%, Opus 0-38%).
Familiaridade com a API é importante. Stripe (bem conhecida): modelos detectam pacotes falsos via dados de treinamento. Plaid (menos conhecida): modelos não conseguem verificar e aceitam a dependência falsa sem questionar.
Este é um problema de toda a categoria. Context7 teve ContextCrush (Fev 2026). Context Hub tem este. Qualquer ferramenta que injete conteúdo externo não saneado no contexto do agente é vulnerável.
Zero saneamento em todo o pipeline:
annotations.js - writeFileSync com conteúdo bruto, sem filtragembuild.js - sem varredura de conteúdo, sem normalização Unicodecache.js - busca no CDN com verificação zero de hash/assinaturasource: official no frontmatter - autodeclarado, não verificadoContext Hub não possui SECURITY.md. Não há uma maneira documentada de divulgar responsavelmente uma vulnerabilidade - sem contato de segurança, sem chave PGP, sem política de divulgação. Membros da comunidade encontraram as vulnerabilidades de qualquer forma e as registraram como issues e PRs regulares. Nenhum foi revisado.