Vulnerabilidades do Google Mcp Toolbox For Databases

Existe uma vulnerabilidade de travessia de diretório (path traversal) no construtor de URL de ferramentas HTTP do googleapis/mcp-toolbox. Ao construir requisições para APIs downstream, o construtor de URL substitui pathParams controlados pelo usuário no caminho configurado da ferramenta e interpreta a string resultante como uma URL relativa. Embora verifique que a entrada não altera o esquema, o host ou as informações de usuário, ele depende de ResolveReference para a resolução final da URL. Como segmentos de ponto (../) são normalizados nessa etapa de resolução, um atacante pode fornecer parâmetros de caminho contendo sequências de travessia de diretório para sair do escopo de caminho configurado pelo operador. Isso permite que o cliente force o toolbox a fazer requisições a endpoints não pretendidos no mesmo host alvo, encaminhando as credenciais configuradas do toolbox (por exemplo, contornando um caminho restrito como /api/v1/users/{{.id}} para alcançar /admin/secrets).

Existe uma vulnerabilidade de bypass de autenticação no caminho genérico de validação de tokens opacos (validateOpaqueToken) do googleapis/mcp-toolbox. Quando o toolbox valida um token opaco por meio de um endpoint de introspecção OAuth 2.0 (RFC 7662), ele decodifica a resposta em uma struct introspectResp. No entanto, a lógica subsequente de verificação de claims (validateClaims) avalia a condição do emissor como a.issuer != "" && iss != "". Se a resposta de introspecção do provedor OAuth externo omitir completamente o campo opcional iss (emissor), a variável iss assume por padrão uma string vazia. Isso faz com que o bloco condicional seja avaliado como falso e ignorado silenciosamente. Consequentemente, a aplicação aceita tokens emitidos por provedores de identidade de terceiros não autorizados ou não pretendidos.

Existe uma vulnerabilidade de bypass de autenticação no caminho genérico de validação de tokens opacos (validateOpaqueToken) do googleapis/mcp-toolbox. Ao verificar um token opaco não analisado por meio de um endpoint de introspecção OAuth 2.0 (RFC 7662), o toolbox decodifica a resposta em uma struct introspectResp na qual o campo Active é declarado como um ponteiro para booleano (*bool). O código só rejeita explicitamente um token se a resposta contiver um campo active preenchido com o valor false (if introspectResp.Active != nil && !*introspectResp.Active). Se um endpoint de introspecção responder com um payload que omita completamente a chave obrigatória active, a variável interna permanece nil, fazendo com que a verificação condicional entre em curto-circuito. Como resultado, o Toolbox aceita tokens de autorização sem o campo "active", concedendo acesso a ferramentas protegidas e às fontes de dados subjacentes.

The Model Context Protocol has a security warning advising servers to validate the "Origin" header on all incoming connections to prevent DNS rebinding attacks. Prior to the v0.25.0 release, users had no way to validate the origin's host. In v0.25.0, a new "--allowed-hosts" flag was introduced alongside the existing "--allowed-origins" flag, enabling users to specify permitted hosts at server startup. Both flags default to "*", allowing users to implement strict access controls as needed without breaking existing setups. If either flag is set to "*", the server will output a startup warning about potential vulnerabilities. Documentation has also been updated to highlight these security considerations.

Vulnerable to DNS rebinding attacks when using SSE (http://b/499408790). During the beta phase, we implemented `allowed-origins` and `allowed-hosts` flags to align with MCP security guidelines. However, the hardcoded `Access-Control-Allow-Origin: *` header in the SSE initialization handler was inadvertently retained. This vulnerability specifically impacts users connecting via Toolbox using SSE under specification v2024-11-05.