Escaneamos servidores MCP de finanças de código aberto — aqui estão as quatro maneiras como tokens de API vazam

Em 2026, terminais de dados financeiros começaram a enviar interfaces MCP. Fornecedores de dados e wrappers de código aberto agora expõem dados de mercado, fundamentos e fluxos de fundos como ferramentas MCP que qualquer cliente de IA — Claude Code, Cursor, Copilot — pode chamar.

Isso é conveniente. Também significa que cada um desses servidores MCP mantém um token de API pago na memória: tokens de fornecedores de dados, chaves de fornecedores, credenciais de sessão. Ao contrário de um projeto aleatório de fim de semana, esses tokens carregam cotas medidas, relações de faturamento e, muitas vezes, acesso a feeds de dados não públicos.

Nós analisamos sete servidores MCP de finanças JS/TS de código aberto (pacotes npm e repositórios do GitHub) e executamos nosso scanner estático local, correctover-scan v1.7.2, sobre eles. Este post descreve os quatro padrões concretos de vazamento que vimos, com que frequência eles apareceram em código publicado e a lista de verificação pré-lançamento que captura todos eles. Nenhum projeto ou mantenedor é nomeado; as descobertas foram divulgadas privadamente aos mantenedores afetados.

Como escaneamos

O scanner roda inteiramente localmente — o código-fonte nunca sai da sua máquina:

npx correctover-scan --bundle ./path/to/mcp-server

Para pacotes npm, nós o executamos contra tarballs npm pack (a construção exata que os usuários instalem); para repositórios, escaneamos o código-fonte verificado. O modo de bundle analisa arquivos .js/.mjs/.cjs/.ts e executa duas camadas de verificações: uma camada de configuração (segredos hardcoded, execução de código dinâmico) e uma camada de código (endpoints de saída em texto claro, fluxo de credenciais para logs, flags de transporte MCP). Cada aviso gerado por máquina com um arquivo/linha foi então revisado manualmente contra o código-fonte real, porque algumas classes de problemas — política CORS e endereços de ligação de rede — o scanner apenas sinaliza indiretamente e um humano deve confirmar.

Nota honesta sobre o escopo: todos os sete alvos eram JS/TS, o território natal do scanner. O ecossistema fastmcp em Python (que inclui vários MCPs de finanças populares) estava fora do escopo; o scanner ainda não analisa arquivos .py, e não encobrimos essa lacuna. MCPs de fornecedores de código fechado não tinham código-fonte de servidor publicado para escanear também.

Como são os números

Dos sete alvos, cinco são enviados como pacotes npm publicados. Em dois desses cinco pacotes publicados (40%) — dois projetos distintos — confirmamos pelo menos um dos quatro padrões de vazamento de token abaixo no artefato exato que os usuários instalam. Um projeto tinha três dos padrões; outro tinha dois. Os outros três pacotes publicados, além dos dois alvos apenas de repositório, voltaram limpos na revisão manual.

Uma nota sobre rótulos de severidade: o scanner classifica credenciais hardcoded como fail, enquanto problemas de HTTP em texto claro, logging, CORS e de ligação são classificados como warn. Isso subestima-os — um token enviado por HTTP em texto claro é uma divulgação de token, ponto final. Optamos pela revisão manual, não pela pontuação.

Um detalhe que vale a pena destacar para qualquer um que mantenha um MCP: para um projeto, ambos os seus problemas já estavam corrigidos no branch principal do repositório — mas as correções nunca foram publicadas no npm. O código que seus usuários npx podem ficar atrás do seu próprio HEAD por meses.

Padrão 1: O token sai por HTTP em texto claro

O endpoint do fornecedor de dados foi hardcoded como uma URL http://, e o token é enviado no corpo do POST:

// cliente API em um servidor MCP de finanças (anonimizado)
export class DataClient {
  token: string;
  private apiUrl = "http://api.marketdata.example";

  constructor(token?: string) {
    this.token = token ?? process.env.DATA_TOKEN ?? "";
  }

  async call(apiName: string, params: Record<string, unknown>) {
    const response = await fetch(this.apiUrl, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        api_name: apiName,
        token: this.token,
        params,
      }),
    });
    // ...
  }
}

Vimos isso em 2 dos 5 pacotes publicados (40%) — em um caso em três módulos de ferramentas separados, cada um com seu próprio fetch hardcoded http://.

Risco: qualquer um posicionado no mesmo caminho de rede — Wi-Fi de cafeteria, um VLAN de escritório compartilhado, um salto comprometido — lê o token bearer diretamente do fio. O token é uma credencial paga e com cota.

Solução: use https://. O endpoint do fornecedor suportou HTTPS em todos os casos que vimos; este era um esquema de URL copiado e colado, não uma limitação de infraestrutura. Coloque a URL base em uma constante de configuração para que não possa mudar por arquivo.

Padrão 2: O token é registrado no stdout

No modo MCP stdio, stdout é o canal de protocolo — ele é capturado pelos arquivos de log do cliente MCP. Um pacote publicado registrou o objeto de requisição inteiro, incluindo o token, logo antes de enviá-lo:

// módulo de ferramenta em um pacote publicado (anonimizado)
const apiParams = {
  api_name: