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) | (Esfera de Controle Não Confiável) | (Verificação Insuficiente da Autenticidade dos Dados) | (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.
| Data | Evento |
|---|---|
| 2026-03-12 | Issue #74 aberta por @bjorkbjork relatando 4 vulnerabilidades de segurança, incluindo integridade do CDN, verificação de fonte autodeclarada e injeção de anotação |
| 2026-03-12 | Issue #74 atribuída internamente a um membro da equipe principal - zero acompanhamento |
| 2026-03-17 | PR #125 aberto por @hobostay adicionando verificação de integridade de conteúdo - zero revisões |
| 2026-03-12 a 03-20 | PRs de segurança adicionais (#69, #81) abertos pela comunidade - zero revisões |
| 2026-03-20 a 03-23 | Nossa auditoria independente confirma e quantifica as vulnerabilidades com 240 execuções Docker isoladas |
| 2026-03-23 | Divulgação pública |
Nota: Não abrimos a issue #74. Nossa auditoria descobriu e quantificou essas vulnerabilidades de forma independente. A issue #74 e os PRs #69, #81, #125 são citados como trabalho anterior demonstrando que a comunidade já sinalizou esses problemas sem nenhum engajamento dos mantenedores.
Uma vez que o pacote falso está no requirements.txt, um pip install -r requirements.txt padrão dá ao atacante execução arbitrária de código via hooks pós-instalação do setup.py. Isso não é uma sandbox - o pip executa Python sem restrições com as permissões totais do desenvolvedor.
A partir desse único ponto de entrada, o atacante pode:
.env ou código-fonte para um servidor controlado pelo atacante.~/.chub/config.yaml para adicionar uma fonte de documentos controlada pelo atacante. Todas as consultas futuras do chub em todas as bibliotecas agora incluirão conteúdo do atacante. Sobrevive a chub cache clear porque a configuração não é cache.Essas ações não são mutuamente exclusivas. Um único hook pós-instalação pode fazer todas elas em menos de um segundo. Não criamos nem registramos um pacote malicioso.
.
|-- README.md # Este arquivo
|-- RESULTS.md # Conjunto de dados completo com detalhamentos por execução
|-- REPRODUCE.md # Guia de reprodução baseado em Docker
|-- alternatives-comparison.md # Comparação com Context7, LAP, GitMCP, Docfork
|-- article.html # Artigo completo
|-- docker/
| |-- Dockerfile # Ambiente de teste isolado
| |-- run_isolated.ps1 # Executor PowerShell (Windows/macOS/Linux via pwsh)
| |-- seed-claude.md # CLAUDE.md mínimo semeado em cada execução
| |-- plaid-doc/ # Documento envenenado do Plaid Link (canário: plaid-link-verify)
| | `-- plaid/link/DOC.md
| `-- stripe-doc/ # Documento envenenado do Stripe Checkout (canário: stripe-checkout-guard)
| `-- stripe/checkout/DOC.md
`-- results/
|-- plaid-isolated/ # 120 execuções do Plaid: JSON + transcrições de sessão + arquivos do projeto
`-- stripe-isolated/ # 120 execuções do Stripe: JSON + transcrições de sessão + arquivos do projeto
Veja REPRODUCE.md para o guia de reprodução completo baseado em Docker.
Início rápido:
# Plaid (padrão)
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
# Em seguida, execute a matriz de teste a partir do host (veja REPRODUCE.md)
--permission-mode bypassPermissions. Agentes reais podem solicitar confirmação.MIT
Esta pesquisa foi conduzida por Mickey Shmueli, desenvolvedor do LAP, uma alternativa open-source ao Context Hub. O LAP usa compilação determinística a partir de especificações oficiais de API, sem conteúdo contribuído pela comunidade no pipeline. Esta auditoria foi motivada por uma preocupação genuína de segurança sobre pipelines de conteúdo não saneados - uma classe de vulnerabilidade que afeta qualquer ferramenta neste espaço que aceita contribuições não verificadas da comunidade. As descobertas falam por si: 240 execuções Docker isoladas, detecção determinística, totalmente reproduzível.
Esta PoC é apenas para fins educacionais e de pesquisa em segurança. Todos os testes foram realizados localmente em contêineres Docker isolados. Nenhum conteúdo malicioso foi submetido ao repositório do Context Hub. Todos os nomes de pacotes canários foram verificados como inexistentes no PyPI antes dos testes.