CVE-2026-75130: o servidor de documentação MCP do Context7 recebe pontuação 9,0 e o registro não indica qualquer versão corrigida

Em 18 de agosto de 2026, a VulnCheck publicou a CVE-2026-75130 contra o Context7, o servidor de documentação de bibliotecas que a Upstash opera para o Model Context Protocol e que os agentes de codificação consultam para obter documentação específica de versão. A falha está no recurso que a Upstash chama de Custom AI Instructions: o proprietário de uma biblioteca anexa orientações a uma entrada de documentação, o Context7 serve essas orientações na janela de contexto de todo agente que consulta a biblioteca, e nada nesse caminho as sanitiza. A Noma Security, cujo pesquisador sênior de vulnerabilidades de IA Eli Ainhorn é creditado como o descobridor, demonstrou que uma entrada envenenada pode fazer um agente conectado ler arquivos .env na raiz do projeto, enviar seu conteúdo para um repositório do GitHub controlado pelo atacante na forma de uma issue, e excluir pastas locais sob o pretexto de "limpeza" — tudo a partir de uma solicitação rotineira de documentação. Nenhuma vítima está registrada. O restante dos incidentes documentados envolvendo agentes, cada um com sua própria severidade, grau de confiança e sinalização de disputa, está em o arquivo de incidentes de IA, onde os registros vizinhos a este podem ser lidos ao lado dele.

O servidor do Context7 é pequeno, e é essa a parte que vale a pena entender primeiro. O texto de Noma observa que ele expõe duas ferramentas, resolve-library-id e query-docs, e que não consegue executar código, gravar arquivos nem acessar a rede por conta própria. Todo impacto documentado é realizado pelo agente do outro lado, que de fato tem acesso ao sistema de arquivos, ao shell e à rede na máquina do desenvolvedor. O registro npm mostra o tamanho da base instalada: @upstash/context7-mcp foi baixado 4,064,176 vezes nos trinta dias de 22 de julho a 20 de agosto de 2026, a janela em torno da publicação.

O mecanismo: uma biblioteca envenenada, todos os agentes que a consultam

A demonstração da Noma, descrita em seu relatório ContextCrush de 5 de março de 2026, foi executada em três etapas que o agente realiza, e não o servidor. Ela registrou uma biblioteca no registro do Context7 com regras envenenadas anexadas. As instruções nessas regras direcionaram o agente a procurar e ler todos os arquivos .env na raiz do projeto; outras instruções o direcionaram a publicar o conteúdo em um repositório GitHub controlado pelo atacante como uma issue; um conjunto final mandou-o excluir pastas e arquivos locais para “limpeza”. A solicitação que traz tudo isso para o contexto é comum — pedir a um assistente de programação ajuda com uma biblioteca.

O motivo de este ser um problema de cadeia de suprimentos, e não uma injeção de prompt comum, está em onde o payload reside. O atacante nunca chega à máquina da vítima e nunca precisa inserir texto em um documento que o usuário abra. As instruções envenenadas ficam no próprio registro do Context7, são hospedadas e servidas pela própria infraestrutura do Context7 e chegam pelo mesmo canal confiável que a documentação legítima, indistinguíveis dela. Noma observa que a pontuação de confiança do Context7, que avalia bibliotecas com base no histórico do GitHub por trás delas, não protege contra isso, porque uma conta de longa data pode ser comprada, sequestrada ou fabricada. O resumo da própria empresa sobre o ponto estrutural é direto: “A superfície de ataque não é o que o servidor MCP pode fazer. Está naquilo que ele pode induzir o agente de IA a fazer.”

Duas pontuações para um único bug

O alerta traz CVSS 3.1 9,0 (crítica) e CVSS 4.0 6,4 (média). Ambos os vetores foram fornecidos pela VulnCheck como a CNA atribuidora, e a NVD mantém ambos inalterados, atribuindo cada um à VulnCheck. A divergência não é um erro; são as duas estruturas contabilizando o mesmo dano em máquinas diferentes. O CVSS 3.1 marca o Escopo como Alterado — a injeção cruza do servidor para a máquina do desenvolvedor e além — e, por isso, contabiliza com peso total o impacto alto pleno de confidencialidade, integridade e disponibilidade das capacidades do agente. O CVSS 4.0 substitui o Escopo por métricas separadas para o sistema vulnerável e o subsequente: não registra nenhum impacto de confidencialidade, integridade ou disponibilidade para o próprio Context7 (VC:N/VI:N/VA:N) e impacto alto nos sistemas a jusante (SC:H/SI:H/SA:H), que sua fórmula pondera com menos peso. O servidor é o mensageiro, não a vítima.

A divisão propaga-se para as bases de dados. O aviso do GitHub, GHSA-97r6-3rgm-v39r, foi publicado às 18:32 UTC de 18 de agosto, meia hora depois da CVE, e a severidade resumida do registro indica média, embora o vetor CVSS 3.1 no mesmo registro pontue 9,0. A Base de Dados de Vulnerabilidades da UE da ENISA replica a entrada como EUVD-2026-61099 e armazena uma pontuação base de 6,4 apenas na versão 4.0. O registro de arquivo que este artigo segue classifica o incidente como alta — que não é nenhuma das duas pontuações publicadas — e é a classificação do arquivo, não uma medição própria.

Uma CVE publicada em agosto referente a uma divulgação de março

O identificador CVE foi reservado em 17 de agosto de 2026 e publicado às 18:02 UTC em 18 de agosto, que é a data que o registro traz. O contêiner CNA também traz uma segunda data que não aparece nas páginas do agregador: datePublic, 5 de março de 2026 — cinco meses e meio antes de o identificador existir, e no mesmo dia em que a Noma publicou o ContextCrush. A única referência técnica do aviso é esse texto de março, que a VulnCheck classifica tanto como descrição técnica quanto como exploit.

A cronologia de divulgação da Noma explica a lacuna. Ela relata a falha à Upstash em 18 de fevereiro de 2026 com um relatório completo e prova de conceito, registra que a Upstash aceitou as conclusões e começou a remediação em 19 de fevereiro, afirma que uma correção foi “implantada em produção com sanitização de regras e salvaguardas” em 23 de fevereiro, e data a divulgação pública e a verificação final pela Noma em 5 de março. Segundo o relato da Noma, o bug de fevereiro foi resolvido em poucos dias.

As datas do registro npm coincidem com essa linha do tempo de uma forma que faz o intervalo afetado parecer estranho. @upstash/context7-mcp 2.1.2 foi publicado em 23 de fevereiro de 2026 às 10:06 UTC, o dia em que Noma diz que a correção chegou à produção; sua linha do changelog diz “Remover aviso desnecessário e atualizar descrições de ferramentas.” 2.1.3 veio em 4 de março de 2026, o dia anterior ao texto de Noma, com notas sobre rejeitar solicitações GET em endpoints MCP e adicionar um campo source aos resultados de busca. Nenhuma das notas de versão menciona sanitização, salvaguardas ou a injeção. O intervalo afetado da CNA termina em 2.1.2, o que faz de 2.1.3 a primeira versão fora dele.

Três leitura se encaixam nessas datas, e nem a VulnCheck nem a Noma declaram qual é a correta. A primeira, defendida pela Digital Applied em seu artigo de 18 de agosto e repetida pela AI Security Wire em 22 de agosto, é que a correção regrediu: a compilação que trazia o patch de fevereiro está dentro do intervalo afetado de agosto. A segunda é que o intervalo está simplesmente ancorado na compilação que o pesquisador testou, e que a 2.1.3, lançada na véspera da divulgação, é o limite real — uma inferência que vários agregadores fazem mecanicamente, incluindo o Feedly, que lista “atualizar para a versão 2.1.3 ou posterior” como mitigação. A terceira é que a correção de fevereiro foi aplicada onde as regras são servidas, em vez de no pacote cliente, caso em que um intervalo de versões npm não descreve a correção de modo algum. Uma correção de segurança silenciosa é comum o suficiente para que a ausência de uma entrada correspondente no changelog não esclareça nada em nenhum dos sentidos.

O que está estabelecido e o que não está

• Estabelecido pelo registro primário. O identificador CVE, sua publicação em 18 de agosto, a VulnCheck como CNA, a classificação CWE-1427 por neutralização inadequada de entrada usada para prompting de LLM, o crédito a Eli Ainhorn, da Noma Security, e um intervalo afetado do Context7 até 2.1.2.

• Estabelecido pela pesquisa da Noma. O caminho de injeção por meio de Custom AI Instructions, a prova de conceito em três etapas, a observação de que o servidor expõe apenas resolve-library-id e query-docs, e a declaração de que nenhuma evidência de exploração na natureza foi observada para o bug de fevereiro.

• Estabelecido pelo registro. A data de publicação da versão 2.1.2, 23 de fevereiro de 2026, a data de publicação da versão 2.1.3, 4 de março de 2026, e uma linha de pacote que, desde então, ultrapassou a 4.0 e chegou à 4.4.4 em 19 de outubro de 2026.

• Não estabelecido: se as builds atuais são afetadas. Nenhuma fonte afirma que a linha 4.x é vulnerável, e nenhuma fonte afirma que ela está livre. O registro CVE, o boletim da VulnCheck e o boletim do GitHub não indicam nenhuma versão corrigida, e a lista de intervalos de versões vulneráveis do boletim do GitHub está vazia.

• Não estabelecido: qualquer vítima ou uso em ambiente real. O arquivo registra o dano real como falso. O enriquecimento do registro pela CISA em 19 de agosto pontuou Exploração como “nenhuma”, Automatizável como “não” e Impacto Técnico como “total”; a falha não está no catálogo KEV; o espelho da ENISA registra um EPSS de 0,49 por cento. A pesquisa da Noma é uma demonstração, não um relatório de incidente.

• Não comprovado: a própria interpretação como regressão. Baseia-se em uma coincidência de datas entre um cronograma de correção e uma publicação no npm, e nenhuma fonte primária afirma que o mesmo caminho de código falhou duas vezes.

Corroboração: reafirmação, e silêncio onde importa

Os documentos que concordam com o registro derivam, em grande parte, dele. O aviso da VulnCheck reitera o texto da CVE e acrescenta a classificação de fraqueza e o crédito ao pesquisador. O aviso do GitHub é um alias da mesma submissão, publicado na mesma noite, sem faixas de versão e sem revisão independente. A entrada da ENISA é um espelho. A Digital Applied, uma das duas fontes citadas pelo arquivo, publicou sua análise em 18 de agosto e a atualizou em 22 de agosto com novas consultas ao registro; a AI Security Wire publicou um segundo artigo em 22 de agosto. Ambos reiteram o aviso e repassam a inferência de regressão, e nenhum afirma tê-la verificado de forma independente.

Não encontramos nenhuma cobertura jornalística da CVE em 29 de outubro de 2026 — nenhum item do BleepingComputer, do The Register ou do SecurityWeek — e os resultados eram páginas agregadoras de CVE, e não reportagens. Essa ausência importa para a forma como o registro deve ser lido: o arquivo o classifica como A, bem documentado com fontes primárias que concordam entre si, e as fontes primárias de fato concordam, mas a concordância aqui se dá entre um registro CNA e a pesquisa que ele cita, não entre duas medições independentes. Várias páginas agregadoras acrescentam alegações que suas fontes não sustentam; a entrada do Feedly, por exemplo, afirma que há um patch disponível e nomeia a versão 2.1.3, o que nenhum comunicado de segurança faz, enquanto a página do VulDB retornou uma verificação de bot em vez de conteúdo e não pôde ser lida de forma alguma.

O que mudou e o que não mudou

Para o bug de fevereiro, a Upstash agiu em poucos dias: aceito em 19 de fevereiro, corrigido em 23 de fevereiro, segundo o relato de Noma. Para o registro de agosto, a única declaração do fornecedor referenciada pelo CVE é uma publicação no LinkedIn da Upstash, ali marcada como aviso do fornecedor, cujo conteúdo não conseguimos ler sem uma sessão. Nenhum aviso de segurança do GitHub com escopo no repositório traz uma versão corrigida, e a entrada do NVD está com status Adiado sem configurações de CPE e com última modificação em 22 de outubro de 2026, de modo que a análise do próprio NVD não consta no registro.

O próprio pacote continuou sendo distribuído. Entre 20 de abril de 2025 e 23 de outubro de 2026, o repositório upstash/context7 publicou 163 versões, e nenhuma de suas notas menciona esta CVE ou descreve a sanitização das instruções personalizadas que carregam a injeção. Isso é um registro daquilo que os mantenedores decidiram anotar, não uma prova de que nada foi corrigido.

O que o registro deixa a um operador é gestão de exposição, e não uma linha de correções. As recomendações da Noma concentram-se em revisar integrações MCP e inspecionar o que passa entre agente e servidor em tempo de execução; as ações sugeridas pela OpenCVE são atualizar, desativar ou restringir o recurso Custom AI Instructions e adicionar validação de entrada ao servidor. A versão operacional de tudo isso resume-se aos mesmos três passos: fixar a versão do servidor MCP em vez de flutuar na versão mais recente, manter credenciais de produção fora de arquivos de ambiente em texto simples que o agente possa ler e tratar respostas de ferramentas como entrada não confiável, e não como documentação que o agente possa seguir.

Dez semanas após a publicação, o registro público ainda termina onde terminava em 18 de agosto: um identificador, duas pontuações separadas por duas faixas, um intervalo afetado cujo limite superior é uma build lançada em fevereiro e nenhuma correção nomeada. Quem fizer a triagem de CVE-2026-75130 terá de decidir com base no que seus agentes conseguem alcançar, porque o registro não informa qual versão instalar.