MCP: compare as dependências entre duas inicializações
Uma versão fixa do servidor pode esconder mudanças nas dependências transitivas. Compare o ambiente realmente instalado antes de aceitar a próxima inicialização.
Read in EnglishPor Pentesty
O achado e seus limites
Em 10 de novembro de 2026, a Corelight descreveu um servidor MCP cujo mesmo commit produziu 15 conjuntos de dependências em cinco semanas: 23 dos 69 pacotes mudaram. O estudo começou numa estação administrativa sem comprometimento identificado. O problema observado era a reconstrução do ambiente pelo lançador sem consumir o arquivo de dependências travadas do projeto, não uma falha intrínseca do protocolo MCP. Isso demonstra deriva de código, não roubo confirmado de credenciais.
Descubra qual instalação a configuração realmente executa
Comece pelo caminho de execução de um servidor conectado a um sistema empresarial. Registre a entrada do assistente, o comando iniciado, seu diretório de trabalho, o executável final e a conta utilizada. Identifique onde termina a preparação do ambiente e onde começa a execução do serviço. Essa distinção permite atribuir a uma mudança o responsável e o momento corretos.
Compare o comando com o procedimento de instalação aprovado. Um arquivo de lock presente no repositório só é evidência útil quando o procedimento o consome. Solicite uma execução registrada da instalação, a lista resultante de pacotes e a identificação do artefato entregue. Repetir apenas o commit da aplicação deixa a árvore transitiva fora do aceite.
A documentação do uv diferencia manter o lock atualizado e sincronizar o ambiente. Transforme essa distinção num requisito: a etapa de preparação deve recusar mudanças não aprovadas, e o lançamento operacional deve executar o ambiente preparado. Não troque parâmetros mecanicamente sem testar como o projeto instala seus componentes.
Monte uma comparação que sobreviva ao cache
Escolha um servidor e duas condições de teste autorizadas: reiniciar o ambiente já preparado e reconstruí-lo numa máquina de validação equivalente. Guarde versão do interpretador, plataforma, pacotes e versões, hashes dos arquivos aprovados e comando efetivo. Compare conjuntos normalizados, para que a ordem da listagem não produza diferenças artificiais.
Uma reinicialização sem alterações é apenas uma amostra. O ensaio de reconstrução verifica se os mesmos insumos produzem a instalação esperada. Quando houver diferença, identifique o pacote, a regra que permitiu sua seleção e a etapa responsável. Exija uma explicação reproduzível antes de atribuir a mudança a ataque ou a atualização legítima.
Use registros de rede para localizar candidatos e eventos de processo para ligá-los ao assistente e ao instalador. Uma consulta a um registro de pacotes deve abrir uma investigação, não disparar uma conclusão de código alterado. O inventário instalado e os arquivos efetivamente executados são a evidência decisiva do teste.
Aceite um artefato completo e teste suas funções
Para uma instalação Python, o modo de hashes do pip exige hashes também das dependências e versões fixadas. Aplique esse princípio ao artefato completo aprovado, incluindo os componentes transitivos. Um hash confirma correspondência com os bytes escolhidos; a decisão sobre confiar nesses bytes exige revisão de origem e conteúdo.
Registre separadamente o resultado funcional: o servidor inicia, negocia a sessão MCP e oferece as ferramentas esperadas? Execute uma operação de leitura com dados de teste e uma tentativa que deveria ser recusada. Compare respostas e registros. Um ambiente estável que perdeu uma função necessária também precisa de correção antes do aceite.
Associe essa verificação à avaliação de proveniência de arquivos PyPI. São perguntas complementares: quem publicou o arquivo e qual conjunto de arquivos chegou a executar. Guarde o identificador aprovado na configuração operacional e mantenha uma versão anterior utilizável para retorno.
Defina quando o conjunto poderá mudar
Designe um responsável por revisar atualizações e uma janela para reconstruir, comparar e promover o próximo ambiente. Estabeleça também um caminho para correções urgentes. Travar a instalação deve tornar a mudança deliberada e rastreável, sem abandonar a atualização dos componentes.
Entregue ao proprietário do serviço um pacote de aceite com configuração, inventário, hashes, diferenças justificadas e resultados funcionais. Acrescente a conta utilizada e os sistemas alcançáveis para dimensionar a prioridade de uma divergência. Esses registros permitem decidir entre aprovar uma atualização, corrigir o procedimento ou investigar execução inesperada.
Perguntas frequentes
Fixar a versão do servidor MCP basta?
O aceite deve abranger a instalação completa. Confira quais versões transitivas foram efetivamente escolhidas e se o procedimento usa o lock aprovado, em vez de confiar apenas na identificação do servidor.
Acesso ao PyPI comprova comprometimento?
Não. Trate o contato como um ponto de investigação e correlacione processo, arquivos instalados e mudança observada. O estudo da Corelight não identificou comprometimento na estação analisada.
Um hash aprovado garante que o pacote é seguro?
Ele permite verificar correspondência com o arquivo escolhido. Avaliação de origem, revisão, testes e acompanhamento de vulnerabilidades continuam sendo decisões separadas do controle de integridade.
Qual evidência encerra o teste?
Uma instalação reproduzida com inventário esperado, funções necessárias preservadas e diferenças explicadas. Registre os resultados da preparação e da reinicialização, além do responsável pela próxima atualização.
Fontes e referências
- Corelight: pesquisa sobre dependências de servidores MCP, 10 de novembro de 2026
- Astral: criação do lock e sincronização no uv
- pip: instalação com verificação obrigatória de hashes
Análise original da Pentesty, publicada em 11 de novembro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.