Fixar a versão do servidor MCP no uvx trava as dependências? Em cinco semanas, 23 de 69 mudaram

Fixar a versão do servidor MCP na config do uvx trava o servidor. Mas não trava o que vem embaixo dele.

O que aconteceu

James Lagermann, da Corelight, olhou a estação de um administrador onde assistentes de código rodavam servidores MCP com credenciais de firewall, SIEM e outros sistemas de gestão. Um dos servidores estava preso a uma release e a um commit específicos. Em cinco semanas, ele rodou com 15 conjuntos diferentes de dependências. Dos 69 pacotes, 23 mudaram de versão, incluindo a biblioteca de criptografia, a de JWT e o próprio SDK do MCP. Ninguém tinha alterado a configuração.

Não foi um caso isolado. A Corelight revisou 35 servidores MCP de dois catálogos de fornecedores e do próprio laboratório. Em 23, a instalação recomendada puxava dependências do registry público a cada launch, instalação ou build de imagem.

Por que acontece

O autor do servidor tinha feito a parte difícil: dependências diretas fixas e um lockfile com hash publicado no repositório. Só que o uvx instala a partir das dependências declaradas no pacote, que são faixas de versão, e ignora o lockfile do projeto. A documentação do uv diz isso com outras palavras: o ambiente de uma ferramenta rodada com uvx fica no cache e é “descartável”.

Pense numa receita com a marca do fermento anotada, mas a lista de compras só diz “farinha”. Cada ida ao mercado traz uma farinha diferente.

O cache esconde o problema. A maioria dos launches reaproveitava o ambiente. Mas o cache tinha 19 builds da mesma release e do mesmo commit, mais ou menos um a cada dois dias. E uma release sequestrada pode ficar no ar por poucas horas. Foi o que aconteceu com o LiteLLM comprometido, que ficou menos de duas horas no PyPI.

O que eu faria

A correção que a Corelight testou: fixar um commit, instalar uma vez a partir do lockfile com hash, lançar o binário direto e desligar checagem de atualização. Cinco servidores congelados assim foram iniciados 457 vezes em duas semanas, e a lista de pacotes bateu sempre com a do dia da instalação.

Com uv, em um projeto que publica uv.lock, fica parecido com isto:

git clone https://github.com/<owner>/<server> /opt/mcp/<server>
cd /opt/mcp/<server> && git checkout <commit>
uv sync --locked --no-dev   # instala o que está no uv.lock, com os hashes dele

# na config do cliente MCP, aponte o binário instalado, sem uvx:
# "command": "/opt/mcp/<server>/.venv/bin/<server>"

Pera. Congelado também envelhece. Num dos servidores congelados, 40 pacotes ficaram mais antigos do que o uvx teria baixado naquele dia, alguns sensíveis para segurança. Então congelar vira tarefa de manutenção: alguém precisa reabrir o lock, revisar e atualizar quando o mantenedor publicar correção.

O que muda para você

Eu começaria pelo inventário. Abra a config de MCP de cada dev e liste as entradas que começam com uvx, npx ou usam latest. Segundo a reportagem, qualquer uma delas pode trazer código novo do registry na próxima sessão do assistente. Depois, priorize as que carregam credencial de produção.

Quantos servidores MCP na sua máquina têm acesso a algo que você não gostaria de ver num log de atacante?

Sou Tech Lead de IA e governança de agentes e MCP é o tipo de problema que eu gosto de discutir. Se quiser conversar sobre o seu caso, me chama aqui.

Fontes

• The supply-chain risk hiding in your MCP servers, James Lagermann, Corelight, 10 de novembro de 2026
• Your pinned MCP server may not be as pinned as you think, Help Net Security, 13 de novembro de 2026
• Tools, documentação do uv