Vulnerabilidades de segurança do MCP: verifique se há exposição antes de aplicar a correção

Quando uma vulnerabilidade MCP aparece no seu feed, a primeira questão operacional não é “qual é a gravidade do problema mencionado no título?”. É: esse aviso diz respeito a um componente que está realmente em execução no meu caminho de agente? Responda a isso antes de executar um exploit, atualizar em massa todos os pacotes ou declarar que uma verificação sem problemas é suficiente. Um veredicto fundamentado reúne cinco elementos de prova: 1. a identificação exata do aviso e do pacote; 2. a versão instalada e executada ; 3. o resultado da faixa afetada divulgado pela editora consultiva; 4. a acessibilidade do ponto de entrada vulnerável e qualquer medida de mitigação temporária; 5. uma sonda de avaliação pós remediação, além de um comprovante do resultado esperado para a tarefa. Essa junção produz um pequeno conjunto de estados úteis: absent , unknown , not affected , affected not reachable , exposed , patched unverified , remediation regression ou remediated . Além disso, ela impede dois atalhos perigosos: tratar a presença do pacote como exposição confirmada e tratar um comando de atualização bem sucedido como recuperação. Crie a junção de exposição antes de escolher a resposta Um catálogo de vulnerabilidades é útil para a detecção, mas não constitui seu inventário em tempo de execução. O aviso pode mencionar um pacote que aparece apenas em um arquivo de bloqueio, em um ambiente abandonado, em uma camada de contêiner que nunca é iniciada ou em uma dependência transitiva de desenvolvimento. O problema inverso é ainda pior: um cliente MCP pode iniciar um pacote por meio de um wrapper ou de uma instalação global que a verificação do seu repositório nunca inspecionou. Colete as evidências do ambiente de execução responsável pelo processo MCP. Não envie prompts, argumentos de ferramentas, tokens, caminhos absolutos ou dados comerciais. Um relatório resumido pode ter a seguinte aparência: O matchStatus deve ser obtido por meio de um gerenciador de pacotes, uma ferramenta SBOM ou um feed de alertas estruturado que compreenda a sintaxe de versões do ecossistema. Não compare as sequências de caracteres das versões lexicalmente. O alerta revisado GitHub para mcp remote , por exemplo, registra = 0.0.5, < 0.1.16 como afetado e 0.1.16 como a primeira versão corrigida. O comunicado revisado para @modelcontextprotocol/server filesystem contém tanto uma linha de versão legada quanto uma linha baseada em data, sendo 2025.7.1 a primeira versão corrigida dessa linha. Um comparador escrito manualmente não é o local adequado para normalizar ambos os esquemas. As informações sobre o pacote e a versão ainda não determinam a acessibilidade. A versão atual Melhores práticas de segurança para o MCP ilustra por que a configuração é importante. Sua análise do “adjunto confuso” lista várias condições que devem coincidir, incluindo um proxy que utilize um ID de cliente estático de terceiros, registro dinâmico de clientes, um cookie de consentimento e a ausência de consentimento por cliente. A mesma orientação e o Especificação de autorização MCP proibir o repasse de tokens e exigir que o servidor de recursos verifique se foi emitido um token para ele. Esses controles devem se tornar campos em um registro específico da exposição, e não uma caixa de seleção genérica do tipo “segurança ativada”. Para um aviso de autorização, colete a validação do público alvo, a correspondência de redirecionamento, a titularidade do consentimento e o comportamento do proxy. Para um aviso relacionado ao sistema de arquivos, colete a versão do servidor executado, os diretórios raiz permitidos, a superfície de ferramentas acessível e a mitigação exata que torna o ponto de entrada afetado indisponível. Para um aviso de injeção de comando, colete o wrapper do cliente, a versão, o limite de confiança do servidor remoto e se essa rota de conexão pode ser invocada. Um componente afetado com um ponto de entrada desativado e verificado é o affected not reachable , e não o not affected . Essa é uma evidência útil de contenção, mas tem validade limitada. Registre um responsável e um prazo para a aplicação do patch, pois uma alteração na configuração, um revertimento da implantação ou um novo cliente podem tornar o caminho acessível novamente. Execute um classificador sem conteúdo, não um exploit Não é necessário que a carga seja maliciosa para encaminhar o incidente. A regra de decisão a seguir é deliberadamente conservadora: Os nomes dos estados indicam a próxima decisão: Estado O que as evidências comprovam Próxima ação limitada absent O componente mencionado não está presente no limite de tempo de execução inspecionado Registrar o escopo do inventário e o encerramento para este limite unknown Faltam ou há conflitos em relação à identidade, versão, correspondência de aviso ou acessibilidade Manter a incerteza; preencher o primeiro campo em branco not affected O componente instalado está fora do escopo afetado pelo editor Mantenha a origem e o frescor; não deduza que o produto está protegido apenas por causa de um nome de embalagem semelhante affected not reachable O código afetado existe, mas o ponto de entrada mencionado está bloqueado por uma contenção verificada Manter a contenção, designar o responsável pela correção e definir uma data de validade exposed A versão afetada e o ponto de entrada acessível coincidem Limitar o caminho, revogar permissões desnecessárias e aplicar patches patched unverified A versão saiu da área de cobertura, mas as evidências funcionais estão incompletas Execute um teste com a ferramenta Canary e verifique se o destino está correto remediation regression A correção ou a contenção prejudicou a ferramenta ou o resultado pretendido Limite o alcance do caminho de risco; corrija a compatibilidade ou utilize uma reversão revisada remediated A versão, o comportamento seguro da ferramenta e o resultado esperado foram todos aprovados Acompanhe a validade e finalize o processo com o comprovante de recebimento Apliquei essa regra a oito casos sem conteúdo, um para cada estado. Todos os oito corresponderam ao resultado esperado. O caso atípico é o mais valioso: @modelcontextprotocol/server filesystem está na versão corrigida do comunicado, mas a verificação da ferramenta de segurança falha. O classificador retorna remediation regression , e não remediated . Essa distinção é importante porque as tarefas de segurança podem gerar um incidente relacionado à integridade do agente. Uma atualização de dependência pode alterar um comando de inicialização, um esquema de recursos, o root permitido, o fluxo OAuth ou a compatibilidade do cliente. O código vulnerável pode ter sido removido, mas a funcionalidade necessária do agente ainda pode estar comprometida. O comprovante tem limitações. Ele não comprova que uma vulnerabilidade desconhecida não possa afetar o componente. Ele não substitui as evidências forenses após uma suspeita de comprometimento. Além disso, depende da identificação precisa do pacote e dos dados atualizados dos alertas; caso duas fontes apresentem informações divergentes, retorne unknown e mantenha ambas as referências. O Registro NVD para CVE 2025 6514, por exemplo, fornece um registro adicional com data referente ao problema de injeção de comando mcp remote , mas o intervalo de pacotes ainda deve estar vinculado ao aviso específico analisado utilizado pelo seu comparador. Aplique uma correção em uma sequência que preserve a integridade do agente A contenção e a remediação exigem aprovações distintas, pois seus raios de explosão são diferentes. Uma sequência prática é: 1. Registrar a identidade. Anote o ID do aviso, o pacote, a versão lançada, o proprietário do cliente ou do servidor e a data e hora do registro. 2. Contém o caminho indicado. Desative o servidor, a conexão remota, a ferramenta ou a rota de autorização vulnerável com a menor alteração reversível possível. 3. Reduzir os privilégios. Revogar credenciais e permissões desnecessárias associadas a esse componente. Fazer a rotação de um segredo somente quando houver indícios de exposição ou quando a política assim o exigir; a rotação pode destruir evidências úteis e causar interrupções não relacionadas. 4. Instale a correção fornecida pelo desenvolvedor. Use a versão corrigida especificada, e não uma versão mais recente aleatória, e mantenha o resultado do gerenciador de pacotes. 5. Reinicie o proprietário real. Atualizar um arquivo de bloqueio ou uma tag de imagem não é suficiente se um cliente do agente em execução prolongada ainda for o proprietário do processo antigo. 6. Execute um teste de segurança da ferramenta. Use um alvo sintético com o mínimo de privilégios. Não repita a exploração nem direcione o canário para dados de produção. 7. Verifique o resultado final. Confirme se o arquivo, o ticket, o registro, a mensagem ou qualquer outro resultado esperado existe e está correto. 8. Fique atento à janela de estabilidade. Verifique se o componente permanece acessível quando esperado, se não volta a entrar na faixa de vulnerabilidade e se não apresenta falhas repetidas após a aplicação do patch. Mantenha a sonda da ferramenta separada do comprovante de resultado. Uma ferramenta de sistema de arquivos pode retornar sucesso ao gravar na raiz permitida errada. Uma ferramenta de tickets pode aceitar uma solicitação, embora o registro seja rejeitado posteriormente. Um transporte MCP pode permanecer em bom estado, embora o produto final do agente esteja faltando. O primeiro comprovante atesta que a funcionalidade reparada pode ser executada com segurança; o segundo atesta que o trabalho do usuário realmente chegou ao destino. Feche o incidente somente quando as evidências mais sólidas disponíveis confirmarem que: o aviso não corresponde mais ao componente lançado, a rota anteriormente vulnerável está controlada, o canário de segurança foi aprovado e o resultado pretendido foi alcançado. Se algum campo estiver desatualizado ou apresentar contradições, mantenha o status explícito em vez de marcá lo como verde. A Sidewisp está atualmente em prévia privada. A direção desse produto é uma camada de saúde para os ambientes de execução de agentes existentes: apresentar evidências concretas, distinguir entre estado ativo, em espera ou travado, manter a aprovação humana no limite da ação e verificar os resultados após a intervenção. A experiência pública atual é uma demonstração em acesso antecipado, não um scanner MCP lançado, um adaptador de monitoramento ou um mecanismo de recuperação automatizado.