Vulnerabilidade na Google MCP Toolbox: o que os utilizadores de IA autoalojada devem verificar

Imagem de capa: Google Cloud — arquitetura do MCP Toolbox.

CVE-2026-93328 liga um aviso concreto sobre software a uma questão mais ampla dos servidores domésticos: um serviço de ferramentas de IA pode ter autoridade sobre ficheiros e armazenamento na cloud que excede a tarefa solicitada ao agente. Comece pelo componente exato afetado, em vez de presumir que todos os servidores MCP têm a mesma vulnerabilidade.

Este guia separa o acontecimento publicado da implementação prática. Explica o que a fonte comprova, onde terminam as provas e como avaliar um fluxo de trabalho com ficheiros privados sem presumir que um modelo impressionante ou um servidor mais recente eliminam a necessidade de acesso delimitado e revisão.

A que software se refere o aviso?

A entrada da GitHub Advisory Database descreve um problema de travessia de caminhos e falta de autorização na fonte de armazenamento na cloud do Google Cloud MCP Toolbox for Databases. O intervalo afetado é específico do componente. Uma implementação MCP não relacionada, um conector que nunca executa esta fonte ou uma versão diferente exige uma avaliação própria. Preserve o digest da imagem instalada, a etiqueta da versão e a configuração para que a comparação possa ser verificada, em vez de inferida a partir do nome apresentado pela aplicação.

A entrada da base de dados estava marcada como não revista quando foi consultada, pelo que não deve ser apresentada como um aviso completo sobre a implementação do fornecedor. Siga as referências até ao repositório a montante e compare-as com as notas de lançamento atuais. O pull request associado acrescenta restrições para buckets e caminhos locais, mas a data de fusão anterior não é a data de divulgação pública. Uma cronologia que afirme que o projeto corrigiu tudo pela primeira vez esta semana deturparia as provas.

Porque é que a atualização é apenas uma parte do perímetro de segurança?

Uma imagem atualizada pode incluir controlos e, ainda assim, ser executada com definições permissivas, montagens desnecessárias ou uma credencial de nuvem com privilégios excessivos. Reveja a configuração efetiva em vez de presumir que o nome de uma definição comprova que a implementação tem restrições. Uma ferramenta que pode ler o sistema de ficheiros do anfitrião e escrever num bucket remoto cria uma via de transferência de dados, mesmo quando o próprio modelo está alojado noutro local. É a identidade que executa a ferramenta que determina a que recursos esta pode aceder.

Faça o inventário das raízes locais, do acesso a buckets, dos utilizadores em execução e da exposição à rede. Prefira um diretório dedicado a tarefas e uma identidade de serviço específica para cada finalidade. Se o processo não puder aceder ao arquivo da família nem a buckets de nuvem sem relação com a tarefa, uma chamada incorreta à ferramenta terá menos autoridade para fazer uso indevido desses recursos. As restrições devem existir abaixo da camada das instruções: as permissões do sistema operativo, as montagens dos contentores e as políticas IAM da nuvem continuam a ser relevantes quando um agente interpreta mal um pedido ou recebe instruções hostis no conteúdo obtido.

O pull request da origem referenciado indica allowedBuckets e allowedLocalRoot e assinala valores predefinidos permissivos. Inspecione os valores efetivos da origem implementada; ver essas definições apenas num binário mais recente não demonstra que a implementação tenha restrições. O mesmo histórico refere a versão 1.5.0, lançada em junho, pelo que um aviso de segurança publicado recentemente não deve ser descrito como uma correção acabada de integrar em outubro.

Como pode verificar a exposição sem repetir um ataque?

Comece por ler a configuração e os metadados de execução. Identifique o tipo de origem implementado, a versão exata e se o endpoint está acessível a partir de redes não fidedignas. Em seguida, verifique as raízes locais e os buckets permitidos com dados de teste descartáveis num ambiente de preparação. Não precisa de enviar segredos de produção nem de reconstruir uma sequência de exfiltração para demonstrar que existe uma credencial ou montagem excessivamente abrangente.

Se os registos ou outras provas indicarem atividade não autorizada, preserve os registos relevantes antes da limpeza de rotina e altere as credenciais associadas ao serviço exposto. Uma atualização de versão não pode revogar uma chave copiada nem recuperar um ficheiro que já saiu do sistema. Mantenha os registos de correção separados dos testes exploratórios e valide os fluxos de trabalho normais após a alteração. O objetivo é um serviço de ferramentas com autoridade comprovadamente limitada, não apenas um contentor que reinicia com êxito.

O que deve medir antes de confiar neste fluxo de trabalho?

Crie um registo de exposição para cada instância implementada: digest da imagem, configuração de origem, identidade de execução, caminhos montados, identidade na nuvem e pontos de acesso disponíveis. Distinga entre um componente estar instalado e a origem afetada estar ativada. Uma etiqueta de contentor ou um pacote listado num ficheiro de bloqueio são pistas úteis, mas não indicam que configuração está ativa no processo em execução. Preserve as provas utilizadas para chegar a cada conclusão.

Avalie a aplicação dos controlos com dados de teste inofensivos. Uma operação permitida dentro de uma raiz de teste dedicada deverá funcionar; um pedido fora dessa raiz deverá ser recusado pelo controlo efetivo, sem exigir que o modelo decida que é inadequado. Aplique o mesmo raciocínio ao âmbito dos contentores e ao IAM. Não deduza que os controlos estão em vigor apenas com base num ficheiro de configuração no disco: confirme que o serviço carregou esse ficheiro e que as substituições da implementação não alargaram a restrição pretendida.

Como pode manter os resultados verificáveis e recuperáveis?

Trate uma suspeita de exposição como um incidente operacional com uma cronologia. Preserve os registos de acesso relevantes, os registos de implementação e os identificadores das credenciais antes da limpeza de rotina, restringindo ao mesmo tempo o acesso desnecessário a esses registos. Registe o que sabe e o que ainda não consegue determinar. A existência de uma versão vulnerável não prova que houve acesso a dados; a ausência de uma entrada conveniente nos registos não prova que o acesso fosse impossível.

A recuperação depende da autoridade afetada. Restrinja ou desative a origem exposta, substitua o software vulnerável, conforme adequado, altere as credenciais implicadas e, se necessário, restaure os ficheiros substituídos a partir de uma cópia conhecida. Em seguida, valide se as operações autorizadas habituais continuam a funcionar com as permissões reduzidas. Registe o digest implementado e as listas de permissões efetivas após a correção. Uma atualização pode alterar o código executável sem corrigir uma montagem demasiado abrangente, uma predefinição permissiva ou uma credencial já exposta.

Como pode testar o fluxo de trabalho antes de utilizar ficheiros importantes?

O seguinte é um protocolo de validação editorial, não uma afirmação de que a ZimaSpace testou o serviço. Execute-o com dados de teste descartáveis ou aprovados e registe as condições do teste juntamente com o resultado.

1. Faça um inventário do componente em execução e do código-fonte afetado. Compare a versão implementada com o intervalo indicado no aviso e registe o digest exato da imagem e a identidade da configuração.
2. Leia o aviso e a alteração a montante em conjunto. Separe a data da divulgação do histórico de implementação anterior e consulte as informações atuais sobre versões antes de escolher uma atualização.
3. Mapeie as permissões efetivas. Inspecione as raízes locais, as montagens de contentores, as permissões de execução, o âmbito dos contentores de armazenamento, o IAM e a acessibilidade dos pontos finais; identifique as permissões desnecessárias para a tarefa pretendida.
4. Valide as restrições com dados de teste descartáveis num ambiente de teste. Verifique os caminhos e contentores de armazenamento permitidos e proibidos sem incluir segredos de produção nos pedidos de teste.
5. Preserve as provas e trate das credenciais expostas se houver suspeitas de atividade. Mantenha as observações do incidente separadas dos pressupostos e dos testes exploratórios.
6. Repita o fluxo de trabalho autorizado habitual após a correção. Registe a versão final, a configuração carregada e o resultado da aplicação das restrições, para que a alteração possa ser analisada de forma independente.

Qual é o papel de um servidor ZimaOS?

Um NAS de nuvem pessoal ZimaCube 2 pode fornecer uma camada local de armazenamento e aplicações quando um projeto precisa realmente de várias unidades, de uma camada de trabalho SSD ou de acesso partilhado a um arquivo em crescimento. Escolha o hardware em função dos dados de origem a conservar, dos serviços ativos e da política de cópias de segurança. A recomendação do produto serve de contexto arquitetónico, não é prova de que este modelo de nuvem, serviço de pré-visualização ou sistema de investigação funcione localmente no NAS.

Separe a inferência da custódia dos dados. Um modelo alojado pode receber excertos aprovados, enquanto os originais oficiais permanecem no servidor. Os serviços opcionais de indexação local, conversão ou modelos mais pequenos requerem uma avaliação própria da memória e do poder de processamento. Mantenha uma segunda cópia recuperável fora do dispositivo principal e não considere o RAID ou um carregamento bem-sucedido uma estratégia de cópia de segurança completa. Um servidor existente mais pequeno continua a ser uma opção razoável quando já satisfaz as necessidades de carga de trabalho medidas.

Perguntas frequentes

Este aviso afeta todos os servidores MCP?

Não. A entrada citada descreve a origem de armazenamento na nuvem nas versões 1.2.0–1.4.0 de googleapis/mcp-toolbox. Outras implementações e implementações em produção precisam de uma avaliação própria.

A atualização da imagem conclui a correção?

Uma atualização é apenas parte da avaliação. Verifique as restrições efetivas da raiz local e do contentor, os caminhos montados, a identidade do ambiente de execução e as credenciais da nuvem. Um ficheiro binário mais recente pode continuar a ter permissões excessivas.

Devo reproduzir a exportação de ficheiros com dados de produção?

Avalie a exposição com base em provas de configuração e dados de teste inofensivos. Não são necessários segredos de produção nem ficheiros privados para validar um ponto de montagem, uma identidade ou uma lista de permissões demasiado abrangentes.

Devo expor todo o arquivo privado a uma ferramenta de IA?

Disponibilize apenas o material necessário para a tarefa, através de uma conta ou diretório de trabalho com restrições adequadas. Verifique o que o serviço específico carrega, regista e retém. Um local de armazenamento privado não garante que uma ferramenta ligada continue a processar os dados localmente.

Quando é que um NAS maior se torna útil?

Quando o crescimento medido dos dados de origem, o acesso partilhado, as aplicações ativas ou os requisitos de retenção justificarem a topologia de armazenamento. Isto não resolve automaticamente o acesso ao modelo, os ambientes de execução não suportados, os limites de carregamento na rede nem a incerteza de uma afirmação de investigação.

Qual é a condição para parar antes da utilização em produção?

Pare se não conseguir determinar a identidade do software/modelo, a autoridade sobre os dados de entrada, a disponibilidade das funcionalidades necessárias ou o processo de recuperação. Resolva primeiro essas condições e, depois, repita o pequeno teste. Não compense a falta de provas com uma recomendação mais assertiva.

Fontes e leituras complementares

• Anúncio ou aviso oficial
• Alterações ao controlo de acesso ao armazenamento na nuvem a montante
• Lançamentos de projetos a montante

Informações verificadas em 28 de outubro de 2026. A disponibilidade dos produtos, os planos de acesso e os avisos de segurança podem mudar. As afirmações de fontes externas são atribuídas; as recomendações de fluxo de trabalho e os exemplos de arquitetura são análises editoriais, não medições de um teste de hardware da ZimaSpace.

Guia relacionado: Um agente de IA alojado localmente pode operar através de uma vista do sistema de ficheiros só de leitura?.

Guia relacionado: Como testar se as permissões do agente abrangem apenas as ações necessárias das ferramentas.

Guia relacionado: Descoberta de vulnerabilidades com IA vs. aplicação automática de correções: que problema resolve cada uma?.