Para saber se um plugin de Claude Code é seguro, revise o que vai executar antes de instalá-lo: seus hooks, seus mods, seus servidores MCP e sua pasta bin/, porque tudo isso roda na sua máquina com suas permissões de usuário. ModVet, um scanner de segurança open source publicado no PyPI esta semana, automatiza a primeira passada dessa revisão: funciona offline, sem LLM, e reporta cada linha suspeita com seu código do OWASP MCP Top 10. Testamos junto ao validador que já traz o Claude Code, sobre plugins e mods oficiais da Anthropic. Detecta bem as primitivas de ataque clássicas, faz barulho com código legítimo e não consegue te dizer qual é a intenção de um fragmento de código.
yoDEV Tested · 20 de outubro de 2026 Executamos ModVet 0.2.2 e
claude plugin validate(Claude Code 2.1.304) no Linux com Python 3.13 em 13 plugins e 4 mods oficiais da Anthropic, os fixtures do próprio ModVet e o repositóriodsh-our-free-model. Os resultados que reportamos como nossos saem dessa prova.
Como testamos. Digitalizamos os fixtures de teste limpo e malicioso que vêm no repositório de ModVet; os 13 plugins de plugins/ e os quatro mods integrados de mods/ do repositório anthropics/claude-code, no commit a6e289a (19 de outubro de 2026); e o repositório dsh-our-free-model no commit 49171b9, que já tínhamos revisado manualmente. Nenhuma das duas ferramentas executa o que analisa, e nós também não: não instalamos nada do que foi digitalizado nem escrevemos código malicioso para o teste. O fixture malicioso é do autor e é inerte: sua URL de download usa o domínio reservado evil.example e seu payload em base64 se decodifica como echo "bad".
Por que é preciso revisar um plugin de Claude Code antes de instalá-lo?
Porque a própria documentação da Anthropic diz que um plugin que você instala pode executar código arbitrário na sua máquina com suas permissões de usuário. Um plugin pode trazer:
- Hooks: comandos de shell que se executam em diferentes momentos do ciclo de vida do Claude Code, por exemplo antes ou depois de uma chamada a uma ferramenta.
- Monitores: comandos de shell em segundo plano que o Claude Code inicia por conta própria.
- Mods: código JavaScript que se executa dentro do Claude Code com suas permissões.
- Servidores MCP e LSP: um servidor MCP stdio roda como um processo que o Claude Code inicia na sua máquina.
- Uma pasta
bin/: é adicionada aoPATHdo shell da ferramenta Bash. - Skills, comandos e agentes: entram no contexto do Claude como instruções.
O mais importante é o que não fica coberto. As regras de permissões e o sandbox do Claude Code se aplicam às chamadas de ferramentas que o Claude faz, não ao código que o plugin executa por conta própria: os hooks, os monitores, os servidores MCP e LSP e os processos que um mod inicia rodam fora do sandbox. E se a atualização automática estiver ativada para o marketplace, os arquivos que você revisou podem mudar no disco após a instalação.
O que é um mod de Claude Code?
Um mod é um plugin que muda a aparência e o comportamento do Claude Code por meio de manipuladores de eventos escritos em JavaScript ou TypeScript. O Claude Code os chama quando ocorre um evento, como uma chamada de ferramenta, um prompt enviado ou uma parte da interface que está sendo desenhada, e o manipulador pode observar o evento, modificá-lo ou respondê-lo por si mesmo. Os mods exigem Claude Code v2.1.287 ou posterior e vêm ativados por padrão; algumas funcionalidades do próprio Claude Code, como /diff, são mods.
Por isso são o componente que mais convém revisar. De acordo com a documentação, uma vez carregado um mod pode ler e escrever arquivos onde você conseguir fazer isso, ler suas variáveis de ambiente e API keys, ver cada prompt e cada chamada de ferramenta, reescrevê-los, aprovar uma chamada de ferramenta antes de ser perguntado a você e chamar um modelo com seu plano. Não se executa em um sandbox.
Esse é exatamente o terreno de ModVet, cujo README se apresenta como a forma de revisar seus mods de Claude Code antes de instalá-los. Vários de seus detectores apontam para o que apenas um mod consegue fazer, como reescrever o prompt antes de enviá-lo ou os argumentos de uma chamada de ferramenta.
Como revisar um plugin de Claude Code sem instalá-lo?
O Claude Code já inclui um caminho de revisão manual, e vale a pena percorrê-lo antes de recorrer a qualquer ferramenta de terceiros:
- Execute
claude plugin marketplace listno seu shell para ver de onde vem cada marketplace. - Em uma sessão, execute
/plugine selecione o plugin. O painel de detalhes mostra, em Will install, seus comandos, agentes, skills, hooks e servidores MCP e LSP. - O painel indica que existe um hook, mas não o que executa. Para isso, leia
hooks/hooks.json,.mcp.jsone cada arquivo debin/. - Com o repositório clonado,
claude --plugin-dir <diretório do plugin> plugin details <nome do plugin>imprime umComponent inventorysem iniciar uma sessão. - Se o plugin traz um mod,
claude plugin validate <diretório do plugin>lista, sem executá-lo, quais eventos manipula e o que pede ao Claude Code.
O passo 5 é o mais revelador. No mod integrado diff, a saída inclui estas linhas (recortadas):
> ./register.ts hooks: session.start, ui.render{component=PromptHint}, ui.render{component=Pane}, command.run{command=diff}, ... tool.call{tool=?|?}, prompt.submit
> ./register.ts calls: $.clock.after, ... $.env.get, $.fs.list, $.fs.read, $.fs.stat, $.process.run, $.session.id, $.session.messages, ...
> ./register.ts env writes: nothing
> ./register.ts env reads: CLAUDE_CODE_DISABLE_FILE_CHECKPOINTING
Um mod só consegue ler arquivos, iniciar processos ou fazer solicitações de rede por meio da API de mods, e por isso o Claude Code consegue listar essas chamadas antes de você instalá-lo. Se um mod que diz desenhar um painel aparece chamando $.process.run e lendo variáveis de ambiente, você já sabe o que perguntar.
Apenasmarketplaces que vêm de github.com/anthropics/ conseguem usar os nomes oficiais ou da comunidade, então um catálogo de terceiros não consegue se passar por um da Anthropic. Mas o nome de um marketplace te diz quem publica o catálogo, não o que cada plugin faz.
O que é ModVet?
ModVet é um scanner de segurança determinístico para revisar mods e plugins de Claude Code antes de instalá-los. Foi escrito em Python por Jörg Michno, tem licença Apache-2.0, não tem dependências e seu mecanismo vem de um projeto anterior do mesmo autor, ClawGuard. Percorre o diretório de um plugin e procura três tipos de problema:
- Injeção de prompt e instruções que tentam anular as do agente: cerca de 400 padrões em inglês e alemão, com normalização de homoglifos, leetspeak, base64, caracteres de largura zero e texto invertido.
- Capacidades perigosas em combinação: um
fetchou uma leitura deprocess.envpor si só são trabalho normal de um plugin, então apenas reporta combinações na mesma expressão, como ler variáveis de ambiente e além disso enviar um POST. Também marca diretamente primitivas de ataque: downloads encadeados a um shell, base64 decodificado para um shell, reverse shells, hooks que elevam permissões, reescrita de configuração, arquivos.envinclusos no repositório e scripts de ciclo de vida do npm. - Segredos hardcodeados: padrões de API keys e tokens.
Cada descoberta leva uma referência do OWASP MCP Top 10 (de MCP01 a MCP10) no campo owasp_mcp do relatório JSON. A saída pode ser legível, JSON ou SARIF 2.1.0 para GitHub Code Scanning, e os códigos de saída permitem usá-lo em CI.
Sem conta, sem rede e sem LLM. É a decisão de design que faz sentido aqui: o que você escaneia não é confiável, e pedir a um modelo que o julgue dá ao plugin a oportunidade de conversar com o juiz.
Como se instala e se usa ModVet?
Se instala desde o PyPI (requer Python 3.9 ou superior):
pip install modvet
Para escanear o diretório de um plugin:
modvet scan ./mi-plugin # relatório legível
modvet scan ./mi-plugin --json # relatório para máquinas
modvet scan ./mi-plugin --format sarif # para GitHub Code Scanning
modvet scan ./mi-plugin --fail-on CRITICAL # falhar apenas com descobertas CRITICAL
Códigos de saída: 0 limpo, 1 descobertas iguais ou superiores a --fail-on (padrão HIGH), 2 erro de uso.
Para escanear um plugin que você já instalou, aponte para a cópia instalada, que o Claude Code guarda em ~/.claude/plugins/cache/<marketplace>/<plugin>/<versão>/.
Para as atualizações, ModVet tem dois comandos a mais: modvet snapshot ./mi-plugin registra uma linha de base após uma instalação limpa, e modvet diff ./mi-plugin --against .modvet-snapshot.json faz auditoria novamente apenas do que mudou. Como a atualização automática consegue mudar arquivos depois que você os revisou, é a ideia mais útil da ferramenta. O autor a resume em uma frase: “the update is the attack”.
O que ModVet detecta? Injeção de prompt, segredos e comandos perigosos
No fixture malicioso do autor, tudo que esperávamos. O fixture limpo retorna 0 descobertas e código de saída 0. O malicioso retorna 9 descobertas, uma pontuação de risco de 10/10 e código de saída 1:
| Descoberta | Severidade | OWASP MCP |
|---|---|---|
Ignore previous instructions em um system prompt |
CRITICAL | MCP01 |
Chave sk-… hardcodeada |
CRITICAL | MCP03 |
| Leitura de variáveis de ambiente + HTTP POST (rota de exfiltração) | HIGH | MCP03 |
curl … | sh |
CRITICAL | MCP05 |
base64 -d | sh |
CRITICAL | MCP03 |
mcpServers declarado em .mcp.json |
MEDIUM | MCP08 |
Para cada um, o relatório mostra o texto detectado, a linha e uma ação recomendada. Em um plugin construído para ativar as regras, as ativa todas.
Um detalhe: esse fixture é sintético e não segue o formato documentado de um mod de Claude Code. claude plugin validate o rejeita porque não tem .claude-plugin/plugin.json. Isso não diminui o valor dos detectores, que procuram padrões em qualquer arquivo, mas significa que a demonstração do autor não diz nada sobre como ModVet se comporta com mods reais. Para isso fizemos o seguinte teste.
ModVet marca como perigosos os plugins e mods oficiais de Claude Code?
Sim, em uma parte. Dos 13 plugins oficiais, nove saíram limpos, entre eles code-review, feature-dev e pr-review-toolkit. Dos quatro mods integrados, dois saíram limpos: agents-md e telemetry. Estes falham com o limiar padrão:
| Plugin ou mod | Descobertas | Máxima severidade |
|---|---|---|
hookify (plugin) |
5 | HIGH |
ralph-wiggum (plugin) |
4 | HIGH |
plugin-dev (plugin) |
11 | CRITICAL |
security-guidance (plugin) |
83 | CRITICAL |
diff (mod integrado) |
4 | HIGH |
sec-default (mod integrado) |
5 | CRITICAL |
As descobertas HIGH e CRITICAL que revisamos eram falsos positivos:
- Em
plugin-deveralph-wiggum, linhas de shell comoecho "$SYSTEM_PROMPT"se interpretam como “instruction replay”, e um cabeçalho Markdown**Critical rules:**ativa uma regra de “instruction header injection”. - Nos mods
diffesec-default, todos os alertas saem de comentários de código e de arquivos de teste: uma frase sobre uma regra de git, a descrição de uma ferramenta mencionada em um comentário, um fixture de testes. security-guidanceé o caso extremo: documenta padrões perigosos (eval(),verify=False,!!python/object) para alertar sobre eles, e o scanner não distingue entre a documentação de um risco e o risco em si.
É o custo da detecção por padrões determinísticos, e convém sabê-lo antes de colocar ModVet em CI: com o --fail-on HIGH padrão, teria bloqueado quatro plugins e dois mods da Anthropic. O autor reporta que os falsos positivos em 12 repositórios caíram de 1.815 para menos de 300 entre o mecanismo v0.1 e o atual. É seu próprio benchmark, sobre repositórios que ele escolheu, e é coerente com o que vimos: faz barulho, mas já não é inutilizável.
ModVet ou claude plugin validate?
Os dois, porque respondem perguntas diferentes. claude plugin validate é um inventário de capacidades: te diz quais eventos um mod manipula e o que pedirá ao Claude Code, como ler arquivos, iniciar processos ou ler variáveis de ambiente, e não te dá uma opinião sobre se isso é malicioso. ModVet é um detector de padrões: procura no texto formas de ataque conhecidas, como curl | sh ou uma instrução para ignorar o system prompt, mas não faz um inventário das chamadas à API de mods.
Em nosso teste se complementaram bem. O validador mostrou que o mod diff chama $.process.run e lê variáveis de ambiente, algo que faz sentido para um painel que mostra mudanças de git e que ModVet não mencionou. ModVet, por sua vez, julga o que o validador não pretende julgar: se há segredos hardcodeados, comandos de shell perigosos ou texto de injeção de prompt em qualquer arquivo do plugin.
O que um scanner de segurança como ModVet não consegue ver?
A intenção. No início desta semana lemos manualmente o código de dsh-our-free-model, um plugin para DeepSeek Harness, e encontramos que seu index.js importa um “channel pack” empacotado em cada inicialização, sem nenhum ajuste para desativá-lo. Essa importação foi a descoberta central de nossa revisão.
ModVet não a marca. Nesse mesmo index.js reporta três descobertas, duas delas CRITICAL do tipo “Secret Assignment” sobre templates de texto em exemplos de código (api_key="${shownKey}"), que são falsos positivos. A importação importante é uma linha de JavaScript completamente normal. Uma observação justa: esse plugin não é de Claude Code, então fica fora do alcance declarado de ModVet. Mas a limitação é geral. Um scanner por padrões reconhece formas de ataque conhecidas; não consegue te dizer que uma importação de aparência legítima carrega 2,9 MB de código que opera pools de contas contra outros provedores.
Também apareceram dois limites práticos:
- A velocidade depende do tamanho. O “em milissegundos” do README não se cumpriu em nossa máquina.
code-reviewdemorou cerca de 0,6 segundos incluindo a inicialização do Python, os mods integrados entre 3 e 26 segundos, esecurity-guidancecerca de 11 segundos. Um único arquivo JavaScript de 500 KB demorou 15 segundos, e o repositório completo dedsh-our-free-model, de 25 MB, não havia terminado após 10 minutos, então o paramos. - Parte da saída está em alemão. As linhas “Context” e “Action” de muitas descobertas, e metade do README, estão em alemão. A severidade, o nome do padrão e o código OWASP se entendem em qualquer idioma, mas pode ser que você precise de um tradutor para a explicação.
ModVet ou Snyk?
Segundo a tabela comparativa do próprio README de ModVet, a diferença é de modelo: Snyk escaneia servidores MCP e skills dentro de uma plataforma DevSecOps mais ampla, com conta na nuvem e preços SaaS, enquanto ModVet roda local e offline, sem conta, e cada regra é visível no código aberto. ModVet soma snapshot e diff para auditar apenas as mudanças de cada atualização. Não testamos Snyk para este artigo, então tome como a comparação do autor, não como a nossa.
ModVet escaneia skills e servidores MCP?
Ainda não de forma específica, em 20 de outubro de 2026. A versão 0.2.2 escaneia diretórios de mods e plugins; seus padrões de injeção de prompt leem qualquer arquivo de texto, mas o README apresenta a digitalização dedicada de SKILL.md e de servidores MCP como o próximo passo, e menciona uma possível oferta Pro ou de auditoria “depois da tração”, sem mais detalhes. O projeto tem dias: enviou três versões ao PyPI em 19 de outubro, não tem releases no GitHub e não há documentação além do README e da pasta specs/. Se o que você precisa revisar são skills, SkillSpector da NVIDIA ataca esse problema: SkillSpector: NVIDIA Quiere Escanear tus Skills Antes de que los Instales.
Então, como você decide se um plugin de Claude Code é seguro?
Use ModVet como primeiro filtro, não como veredicto:
- Revise de onde vem com
claude plugin marketplace liste o painel de detalhes de/plugin. - Se traz um mod, execute
claude plugin validatee compare as chamadas que lista com o que o plugin diz fazer. - Execute
modvet scansobre o plugin clonado. Um resultado limpo significa que não encontrou nenhuma das primitivas de ataque conhecidas. Um CRITICAL porcurl | sh,base64 -d | shou leitura de ambiente mais POST merece uma revisão cuidadosa. - Leia cada descoberta em seu contexto. Muitas serão comentários, documentação, exemplos ou arquivos de teste.
- Leia você mesmo os hooks,
.mcp.json,bin/e o código do mod de qualquer forma. Aí é onde nenhuma das duas ferramentas consegue julgar a intenção. - Tire um snapshot após instalar com
modvet snapshote executemodvet diffapós cada atualização, ou desative a atualização automática para esse marketplace.
Em CI, considere usar --fail-on CRITICAL em vez do valor padrão, para que um plugin que documenta riscos não bloqueie seu pipeline.
E você? O que é a primeira coisa que você revisa antes de instalar um plugin de Claude Code?
- Instalo se o marketplace parece confiável
- Leio os hooks, os scripts e o código do mod
- Passo por um validador ou um scanner
- Faço outra coisa (conte-nos qual)
Comente abaixo ou, se este artigo chegou a você por e-mail, responda diretamente ao email: sua resposta será publicada aqui.
Relacionado: É seguro dsh-our-free-model? O que encontramos ao ler o código do plugin “grátis” para DeepSeek Harness