O monitoramento contínuo detectou um vazamento de credenciais em um pacote MCP publicado. Seis republicações depois, ainda está lá.

Este é um relatório de divulgação. Ele descreve o caso apenas a nível de classe. Nenhum valor de credencial é citado em qualquer lugar neste post.

O que foi encontrado

O pacote é fa-mcp-sdk no npm. Ele é distribuído como um SDK do Protocolo de Contexto de Modelo, o que significa que é instalado por ferramentas de framework de agente (Claude, Cursor, agentes OpenAI, clientes MCP personalizados) normalmente via npm install fa-mcp-sdk ou npx -y fa-mcp-sdk. Como esse caminho de instalação é executado sem revisão manual na maioria das configurações de agente, qualquer coisa dentro do tarball publicado chega aos consumidores imediatamente na primeira instalação.

Em 2026-04-19, um scanner contínuo que eu executo sinalizou o pacote em uma nova publicação. A pontuação caiu drasticamente, e o tipo de descoberta foi hardcoded_secret com severidade crítica. Em uma revisão manual, encontrei um arquivo em package/config/local.yaml contendo credenciais reais de produção. As classes:

• Uma chave de API OpenAI / LiteLLM vinculada a um usuário nomeado em um gateway LLM interno
• Um nome de usuário e senha de conta de serviço do Active Directory cobrindo quatro controladores LDAP em dois domínios de produção em um ambiente de serviços financeiros
• Tokens ACL do Consul para centros de dados de dev e prod
• Uma senha de superusuário do Postgres
• Uma chave de criptografia JWT
• Uma senha de autenticação básica

A combinação é o que torna isso severo, não qualquer credencial única. A conta de serviço LDAP sozinha dá a um atacante acesso de ligação para enumerar todo o Active Directory da organização afetada. O token de produção do Consul provavelmente expõe mais segredos em seu armazenamento KV. A senha de superusuário do Postgres é acesso direto ao banco de dados em uma plataforma de serviços financeiros. Qualquer um que instalou o pacote e leu tinha tudo o que precisava para mapear a rede, escalar privilégios e exfiltrar dados.

Por que a cadeia de suprimentos MCP é estruturalmente diferente

A cadeia de suprimentos npm regular tem um histórico de 20 anos de orientações, arquivos de bloqueio, ferramentas de auditoria e cultura de revisão em torno dela. O MCP é novo, e quatro propriedades de como os pacotes MCP são tipicamente usados tornam o modelo de ameaça materialmente pior:

1. Sem arquivos de bloqueio na maioria das configurações de clientes MCP. Claude Desktop, Cursor e frontends de agente semelhantes lançam servidores MCP a partir de um arquivo de configuração que usa npx -y sem fixação de versão. A cada reinício, a versão mais recente é puxada. O ecossistema npm resolveu isso com package-lock.json há anos; o MCP ainda não o adotou.
2. Caminhos de instalação contornam a revisão. Quando um framework de agente inicia um servidor MCP, nenhum humano verifica o que foi instalado. O padrão é mais próximo de executar um comando de shell remoto do que instalar uma dependência. Qualquer código no tarball publicado é executado na máquina do consumidor na primeira vez que o agente é iniciado.
3. A superfície de capacidade é opaca. Uma dependência típica do npm expõe funções que um desenvolvedor escolhe importar. Um pacote MCP declara um conjunto de ferramentas que o agente pode decidir chamar autonomamente. Adicionar email_messaging ou shell_exec entre versões menores é uma mudança de escopo significativa que os consumidores raramente notam.
4. A postura do publicador é irregular. Muitos pacotes MCP não têm atestações de proveniência, nenhum link de repositório, nenhum contato de segurança publicado, nenhum pipeline de lançamento que exclua arquivos de configuração. Entre 880 pacotes MCP atualmente monitorados, a falta de proveniência é de longe o tipo de descoberta mais comum, representando 64% de todos os problemas sinalizados.

Juntas, uma instalação npx -y não fixada de um pacote MCP dá ao publicador mais autoridade sobre o tempo de execução do consumidor do que uma dependência típica do npm, com menos revisão e menos visibilidade.

A linha do tempo da divulgação

Eu segurei a divulgação pública por seis dias enquanto tentava a remediação privada através de vários canais. Nenhum funcionou.

Eu extraí o último tarball publicado (0.4.71) em 2026-04-25 para verificar antes de ir a público. Dez dos padrões de credenciais originais ainda estavam presentes em package/config/local.yaml. Mesmo arquivo, mesmos valores, seis republicações desde a primeira divulgação privada.

O que eu acho que aconteceu internamente

Isso é especulação, mas se encaixa no padrão visível. Alguém na organização do mantenedor adicionou _local.yaml (o template sanitizado com prefixo de sublinhado) ao diretório config/, provavelmente em resposta a um dos meus e-mails ou a uma revisão interna. Essa mesma pessoa, ou uma pessoa diferente, não notou ou não agiu sobre o original local.yaml que estava ao lado. O pipeline de publicação envia todo o diretório config/ incondicionalmente, então cada lançamento subsequente continua a vazar as credenciais, independentemente de quaisquer outras alterações de código enviadas junto.

Se essa leitura estiver correta, a correção real é uma linha em package.json:

"files": [
  "dist",
  "README.md"
]

Ou uma entrada em .npmignore:

config/local.yaml

Essa mudança de uma linha não foi implementada em seis versões e seis dias. Qualquer que seja o processo que a organização do mantenedor tenha para receber e agir sobre relatórios de segurança, não produziu uma remediação neste intervalo.

Onde isso se encaixa no ecossistema mais amplo do MCP

Números são do conjunto de dados de monitoramento ao vivo do AgentScore em 2026-04-25, cobrindo 880 pacotes MCP no npm e 9.129 varreduras registradas:

• Entre as 500 varreduras mais recentes, 87% dos pacotes MCP produzem pelo menos uma descoberta. A maioria dessas descobertas não são vulnerabilidades; são lacunas de verificabilidade (no_provenance,