# Boletim mensal de segurança em IA para programação com Miasma MCP e dependências comprometidas | Cultura Builder

_Source: [https://insights.culturabuilder.com/insights/boletim-mensal-de-seguranca-em-ia-para-programacao-com-miasma-mcp-e](https://insights.culturabuilder.com/insights/boletim-mensal-de-seguranca-em-ia-para-programacao-com-miasma-mcp-e)_

# Boletim mensal de segurança em IA para programação com Miasma MCP e dependências comprometidas

Publicado em 15 de junho de 202614 min de leitura

Este boletim é para quem está construindo software com IA, usando agentes de código, MCP, IDEs com automação, npm, PyPI, GitHub Actions e muita vontade de tirar uma ideia do papel rápido.

O alerta do mês é simples, mas desconfortável: a superfície de ataque saiu do código que você escreve e entrou no ambiente que ajuda você a escrever. Pacotes comprometidos, hooks de instalação, configurações de IDE, arquivos de agente, servidores MCP e tokens de CI/CD passaram a fazer parte do mesmo problema.

A regra prática para builders é simples: todo ganho de velocidade precisa vir com uma camada explícita de verificação.

## Apuração em 14 de junho de 2026

Este boletim foi fechado em 14 de junho de 2026 e cobre eventos confirmados entre maio e junho de 2026. A base de apuração inclui o boletim oficial da Red Hat sobre o comprometimento de pacotes `@redhat-cloud-services`, a análise da Microsoft sobre a campanha Miasma, os relatórios técnicos sobre Phantom Gyp em npm, a resposta pública da Vapi, os alertas sobre PyPI, as mudanças anunciadas pelo GitHub para npm v12 e validação de agentes, a orientação da NSA sobre MCP e a resposta da OpenAI ao caso TanStack.

Não é um relatório forense do seu ambiente. É um resumo operacional para você decidir o que verificar hoje, o que mudar no seu fluxo de vibe coding e onde colocar revisão humana antes de publicar.

## Resumo executivo

-   Em 1 de junho de 2026, a Red Hat publicou o [boletim RHSB-2026-006](https://access.redhat.com/security/vulnerabilities/RHSB-2026-006) sobre múltiplos pacotes npm comprometidos no namespace `@redhat-cloud-services`.
-   A Microsoft analisou a campanha Miasma e descreveu 32 pacotes maliciosamente modificados em mais de 90 versões, com uso de hooks de instalação, roubo de credenciais, abuso de GitHub Actions e propagação por pacotes com aparência legítima por meio de OIDC e proveniência [na análise técnica da campanha](https://www.microsoft.com/en-us/security/blog/2026/06/02/preinstall-persistence-inside-red-hat-npm-miasma-credential-stealing-campaign/).
-   Em 3 de junho de 2026, a StepSecurity descreveu uma segunda onda chamada Phantom Gyp, com 57 pacotes e mais de 286 versões maliciosas, usando `binding.gyp` e `node-gyp` para executar código sem depender de `preinstall` ou `postinstall` no `package.json` [no relatório técnico](https://www.stepsecurity.io/blog/binding-gyp-npm-supply-chain-attack-spreads-like-worm).
-   A Snyk também classificou a onda como comprometimento crítico de supply chain, cobrindo 57 pacotes afetados, centenas de versões maliciosas e roubo de credenciais de npm, GitHub, AWS, GCP, Azure, Vault e Kubernetes [na análise sobre node-gyp](https://snyk.io/blog/node-gyp-supply-chain-compromise-self-propagating-npm-worm-binding-gyp/).
-   A Vapi informou que quatro versões maliciosas de `@vapi-ai/server-sdk` foram publicadas, mas que tiveram zero downloads antes da remoção, sem evidência de acesso a dados ou credenciais de clientes [em seu comunicado de 4 de junho](https://vapi.ai/blog/our-response-to-june-3-supply-chain-incident).
-   Em PyPI, a campanha Shai-Hulud voltou em pacotes científicos e de ecossistema de agentes, com uso de arquivos `.pth` para executar código em inicializações futuras do Python, conforme relatado a partir da pesquisa da Socket [na cobertura sobre 19 pacotes PyPI](https://www.bleepingcomputer.com/news/security/new-shai-hulud-attack-trojanizes-19-science-focused-pypi-packages/amp/).
-   O GitHub anunciou mudanças no npm v12 para bloquear scripts de instalação por padrão e exigir aprovação explícita, com lançamento estimado para julho de 2026 [no changelog do npm v12](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/).
-   A NSA publicou orientação formal sobre MCP em maio de 2026, reforçando que agentes com tool use exigem isolamento, limites de permissão, validação de mensagens e revisão de fronteiras de confiança [no comunicado sobre segurança MCP](https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4496698/nsa-releases-security-design-considerations-for-ai-driven-automation-leveraging/).

## Incidentes do mês e por que eles importam

### Miasma no namespace Red Hat

O primeiro alerta relevante veio da Red Hat. O boletim oficial informa que um GitHub account comprometido foi usado para inserir código malicioso em pacotes mantidos em uma organização GitHub da Red Hat. Esses pacotes eram bibliotecas JavaScript de frontend usadas no Hybrid Cloud Console, e a Red Hat afirmou que, com base nas descobertas atuais, não havia ação exigida de clientes [no boletim RHSB-2026-006](https://access.redhat.com/security/vulnerabilities/RHSB-2026-006).

A parte mais importante para builders está na análise da Microsoft: os pacotes carregavam assinaturas de proveniência autênticas, mas continham um payload de roubo de credenciais. Isso reduz a confiança cega em uma ideia muito comum: “se o pacote veio de um namespace conhecido e tem assinatura, está seguro”.

Não é tão simples. Em supply chain moderno, a cadeia de publicação também vira alvo. Se o fluxo legítimo de CI/CD é usado para publicar malware, a embalagem pode parecer correta enquanto o conteúdo está comprometido.

### Phantom Gyp e o fim da verificação só pelo package.json

A onda Phantom Gyp foi mais perigosa para o dia a dia de desenvolvimento porque explorou um hábito técnico quase invisível. Em vez de declarar um hook `preinstall` ou `postinstall`, os pacotes traziam um `binding.gyp` que acionava `node-gyp rebuild` durante o `npm install`.

Isso importa porque muitas verificações simples procuram scripts suspeitos em `package.json`. A técnica descrita pela StepSecurity abusou de um arquivo de build de 157 bytes para acionar `node index.js` sem parecer um hook tradicional [na investigação sobre Phantom Gyp](https://www.stepsecurity.io/blog/binding-gyp-npm-supply-chain-attack-spreads-like-worm).

A Snyk reforçou o ponto operacional: um lockfile ou pin exato que ainda aponte para uma versão maliciosa pode continuar baixando a versão comprometida mesmo que o `latest` já tenha voltado para uma versão limpa [na análise de remediação](https://snyk.io/blog/node-gyp-supply-chain-compromise-self-propagating-npm-worm-binding-gyp/).

Não confie no `latest` como sinal de segurança. Um pacote pode ter sido corrigido no dist-tag e ainda existir no lockfile de um projeto.

### O caso Vapi e a diferença entre impacto e exposição

O comunicado da Vapi é um bom exemplo de como ler incidentes sem pânico. A empresa confirmou a publicação de quatro versões maliciosas de `@vapi-ai/server-sdk`: `0.11.1`, `0.11.2`, `1.2.1` e `1.2.2`. Também afirmou que essas versões tiveram zero downloads antes da remoção e que não encontrou evidência de acesso a dados ou credenciais de clientes [no comunicado público](https://vapi.ai/blog/our-response-to-june-3-supply-chain-incident).

Mesmo assim, a orientação prática permanece válida: revisar manifests, lockfiles e mirrors internos. Exposição não é o mesmo que impacto, mas só dá para separar uma coisa da outra olhando versões instaladas, logs e ambientes onde havia credenciais.

### PyPI, arquivos.pth e execução atrasada

A onda em PyPI mostra que o problema não é só de JavaScript. Segundo a cobertura baseada na pesquisa da Socket, 19 pacotes PyPI foram comprometidos em 37 releases maliciosos, muitos voltados a ferramentas científicas e bioinformática. O ponto técnico mais importante é o uso de arquivos `*-setup.pth`, que podem executar código quando o Python inicializa, sem exigir que o pacote malicioso seja importado diretamente [no relato sobre a onda PyPI](https://www.bleepingcomputer.com/news/security/new-shai-hulud-attack-trojanizes-19-science-focused-pypi-packages/amp/).

Para builders, isso muda o raciocínio. Não basta perguntar “eu usei essa biblioteca no meu código?”. A pergunta certa é “essa versão entrou no ambiente em algum momento, inclusive por dependência transitiva, notebook, teste, kernel ou CI?”.

O rastreamento da Socket também conecta Miasma ao histórico Mini Shai-Hulud e lista artefatos npm e PyPI relacionados, incluindo pacotes associados ao ecossistema MCP [no tracker da campanha](https://socket.dev/supply-chain-attacks/miasma-mini-shai-hulud-supply-chain-attack).

### Agentes de código, prompt injection e CI/CD

O risco de IA para programação não está apenas na dependência. Também está no agente que processa conteúdo não confiável.

Em 5 de junho de 2026, a Microsoft publicou uma análise do Claude Code GitHub Action. O achado foi direto: conteúdo controlado por terceiros em issues, pull requests e comentários poderia influenciar o agente, e o uso da ferramenta Read permitia acesso a `/proc/self/environ`, expondo `ANTHROPIC_API_KEY` e potencialmente outras credenciais no runner. A Microsoft afirma que a mitigação foi aplicada no Claude Code 2.1.128 [na análise sobre CI/CD agentic](https://www.microsoft.com/en-us/security/blog/2026/06/05/securing-ci-cd-in-agentic-world-claude-code-github-action-case/).

Quando um agente consegue instalar pacotes, ler arquivos, abrir pull requests e acessar variáveis de ambiente, ele deixa de ser apenas um assistente. Ele passa a fazer parte do perímetro de segurança do projeto.

Esse é o ponto que muita gente ainda subestima. Issue, comentário, descrição de PR, README, diff e arquivo de configuração são dados não confiáveis. Para um modelo, porém, dados podem parecer instruções. O builder precisa desenhar o fluxo assumindo que qualquer texto lido pelo agente pode tentar direcionar a ação dele.

### Respostas de plataforma

O GitHub anunciou três movimentos relevantes.

Primeiro, em 5 de maio de 2026, tornou disponível de forma geral o secret scanning no GitHub MCP Server, permitindo que agentes e IDEs compatíveis com MCP peçam varreduras de secrets antes de commit ou pull request [no changelog do MCP Server](https://github.blog/changelog/2026-05-05-secret-scanning-with-github-mcp-server-is-now-generally-available/).

Segundo, em 9 de junho de 2026, anunciou validação automática para código criado por agentes de terceiros, incluindo Claude e OpenAI Codex. A validação usa CodeQL, GitHub Advisory Database e secret scanning, e tenta resolver problemas antes de finalizar o pull request [no changelog de validação de agentes](https://github.blog/changelog/2026-06-09-security-validation-for-third-party-coding-agents/).

Terceiro, também em 9 de junho, antecipou mudanças no npm v12. A partir da nova versão, scripts de instalação deixam de rodar automaticamente por padrão, dependências Git e URLs remotas passam a exigir permissão explícita, e projetos podem preparar allowlists com `npm approve-scripts` [nas mudanças do npm v12](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/).

Essas mudanças ajudam, mas não substituem arquitetura. A NSA foi clara ao dizer que MCP exige implementação cautelosa por causa de riscos de serialização, fronteiras de confiança, uso indevido de agentes, tool invocation dinâmica e compartilhamento de contexto [na orientação pública sobre MCP](https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4496698/nsa-releases-security-design-considerations-for-ai-driven-automation-leveraging/).

## Impacto para builders que usam IA para programar

O impacto real não é “pare de usar IA”. Isso seria uma leitura pobre.

O impacto é que o fluxo builder precisa crescer em maturidade. Se você usa IA para criar um app, gerar integração, montar um SaaS interno ou automatizar uma rotina, provavelmente seu ambiente tem três coisas valiosas: tokens, acesso a repositórios e automações que publicam ou implantam código.

Em projetos pequenos, o risco costuma estar justamente no excesso de conforto. O agente está no seu editor. O terminal está aberto. O `.env` está por perto. O GitHub está autenticado. O npm ou o PyPI confiam no lockfile. A IA sugere instalar uma lib para resolver rápido. Parece produtividade. Também pode ser o caminho mais curto para vazar credenciais.

A lógica do mês é esta: dependência comprometida mais agente com permissão ampla mais CI/CD com secrets é uma cadeia de ataque completa.

Vibe coding seguro não é escrever mais devagar. É construir com trilhos: escopo pequeno, dependências conhecidas, agente com permissão mínima, revisão humana e logs preservados.

## Como verificar se você foi afetado

Comece pelos repositórios que tiveram `npm install`, `pnpm install`, `yarn install`, `pip install` ou execução de agente entre 1 e 14 de junho de 2026. Priorize ambientes com secrets, runners de CI/CD, máquinas de founders, máquinas de devs e projetos que usam agentes de código.

### 1\. Verifique lockfiles e manifests npm

Procure referências aos namespaces e pacotes citados nas campanhas. Não olhe só `package.json`. O lockfile é onde o risco costuma sobreviver.

```bash
grep -RniE '@redhat-cloud-services|@vapi-ai/server-sdk|ai-sdk-ollama|autotel|awaitly|executable-stories|node-env-resolver|wrangler-deploy' package.json package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null
```

Se aparecer `@vapi-ai/server-sdk`, confira especificamente as versões `0.11.1`, `0.11.2`, `1.2.1` e `1.2.2`, que foram listadas pela Vapi como maliciosas.

### 2\. Procure sinais de Phantom Gyp

O padrão mais importante não é só a existência de `binding.gyp`. Muitos pacotes legítimos usam esse arquivo. O alerta é a presença de comando shell inesperado, `node index.js`, `stub.c`, download de Bun ou arquivo `index.js` grande demais para o pacote.

```bash
find node_modules -name "binding.gyp" -print 2>/dev/null
grep -Rni '<!(' node_modules 2>/dev/null
grep -Rni 'stub.c' node_modules 2>/dev/null
find node_modules -maxdepth 3 -name "index.js" -size +1M -print 2>/dev/null
```

Se você encontrar esse padrão em pacote sem motivo legítimo para build nativo, pare a execução, preserve evidências e trate como possível incidente.

### 3\. Revise arquivos de agentes e IDEs

As campanhas recentes miraram configurações de assistentes e IDEs. Procure arquivos criados ou alterados sem explicação clara.

```bash
ls -la.claude.cursor.gemini.vscode 2>/dev/null
find. -path "./.claude/*" -o -path "./.cursor/*" -o -path "./.gemini/*" -o -path "./.vscode/*"
grep -RniE 'setup.mjs|folderOpen|bun run|oven-sh/bun|SessionStart'.claude.cursor.gemini.vscode 2>/dev/null
```

Não aprove mudanças nesses diretórios só porque “parecem configuração de produtividade”. Configuração de agente também é código executável no fluxo de trabalho.

### 4\. Verifique ambientes Python

Em PyPI, a atenção vai para arquivos `.pth` suspeitos e payloads que rodam quando o interpretador inicia.

```bash
find. -name "*-setup.pth" -print 2>/dev/null
grep -RniE 'bun|_index.js|site-packages|LaunchAgents|systemd'. 2>/dev/null
pip freeze
```

Se a máquina ou o runner instalou pacotes científicos, ferramentas MCP, SDKs de agentes ou dependências recentes de IA, aumente a prioridade dessa verificação.

### 5\. Olhe os logs de CI/CD

Procure sinais que não combinam com uma instalação normal:

-   `node-gyp rebuild` rodando em pacote que não deveria compilar addon nativo.
-   `curl` ou `unzip` durante `npm install`.
-   Download de `github.com/oven-sh/bun/releases`.
-   Chamadas inesperadas para `api.github.com`.
-   Criação de repositórios desconhecidos.
-   Publicações npm, PyPI ou RubyGems fora da rotina.
-   Leituras de `/proc` ou memória de runner.
-   Mudanças em workflows com permissões amplas.

Se você encontrou uma versão afetada em um ambiente com credenciais, trate o ambiente como comprometido até provar o contrário.

## Mitigação prática para projetos com IA

A mitigação precisa cobrir quatro camadas: dependências, agentes, secrets e publicação.

### Dependências

Congele versões conhecidas como boas. Use lockfiles com integridade. Revise diffs de lockfile como se fossem código. Evite atualização automática em pacote sensível sem janela mínima de idade, análise e teste em ambiente isolado.

Antes de instalar algo sugerido pela IA, pergunte: quem mantém, quando publicou a versão, o pacote tem scripts, o pacote tem build nativo, o pacote precisa mesmo existir no projeto?

### Agentes de código

Separe ambientes. Um agente que lê issue pública não deve ter acesso simultâneo a secrets e capacidade de escrever ou publicar. Use permissões mínimas e revisão humana para PRs criados por agentes.

Se o agente precisa rodar comandos, limite diretórios, rede, arquivos sensíveis e variáveis de ambiente. Logs precisam ser preservados. Sem logs, não existe investigação confiável depois.

### MCP

Trate cada servidor MCP como uma integração com privilégio. Não instale servidor MCP aleatório porque ele economiza cinco minutos. Avalie permissões, escopo de dados, origem do pacote, método de autenticação e capacidade de chamada externa.

A orientação da NSA reforça que autenticação e autorização continuam necessárias, mas não bastam. MCP adiciona risco porque o agente descobre ferramentas, compartilha contexto e pode invocar ações em cadeia. O controle precisa estar no desenho do ambiente, não só no prompt.

### Secrets

Remova secrets de máquinas de desenvolvimento quando possível. Use tokens curtos, escopo mínimo, rotação frequente e separação por ambiente. Um token de desenvolvimento não deve publicar pacote, alterar infra e acessar produção ao mesmo tempo.

Se um pacote comprometido rodou em uma máquina ou runner com secrets, rotacione. Não espere o atacante “provar” que usou. Em supply chain, tempo é parte da defesa.

### Publicação e CI/CD

Reduza privilégios de `GITHUB_TOKEN`, npm publish tokens e OIDC trust relationships. Exija aprovação manual para publicação quando houver mudança de dependência, workflow ou arquivo de agente. Bloqueie egress desnecessário em runners, especialmente durante etapas de instalação.

Prepare sua stack para npm v12. Rode `npm approve-scripts --allow-scripts-pending` em projetos críticos e transforme scripts permitidos em política explícita, não em confiança implícita.

## Checklist de 30 minutos para hoje

-   Procurar pacotes afetados em `package.json`, `package-lock.json`, `yarn.lock` e `pnpm-lock.yaml`.
-   Procurar `binding.gyp` suspeito, `stub.c`, `node index.js`, downloads de Bun e `index.js` grande demais.
-   Revisar `.claude`, `.cursor`, `.gemini` e `.vscode` em todos os repositórios ativos.
-   Procurar arquivos `*-setup.pth` em ambientes Python recentes.
-   Revisar logs de CI/CD entre 1 e 14 de junho de 2026.
-   Verificar publicações inesperadas em npm, PyPI, RubyGems e GitHub Releases.
-   Rotacionar tokens de ambientes onde versões afetadas foram instaladas.
-   Reduzir permissões de agentes que processam issues, comentários, PRs e arquivos de usuários externos.
-   Colocar revisão humana obrigatória antes de merge, publicação e deploy feitos por agente.
-   Documentar quais agentes, MCP servers e scripts de instalação são permitidos no projeto.

## O que muda na formação de builders

A nova competência não é decorar nomes como Miasma, Phantom Gyp ou Shai-Hulud. Esses nomes mudam. O padrão fica.

Builders precisam aprender a construir com IA sem entregar o ambiente inteiro para a automação. Isso inclui entender lockfile, dependência transitiva, hook de instalação, secret, runner, MCP, prompt injection, permissão de agente e revisão humana.

Construir antes de pedir permissão técnica continua sendo uma vantagem. Mas publicar sem entender o que o agente instalou, leu, executou e enviou deixou de ser coragem. Virou risco operacional.

O builder moderno não precisa virar especialista em malware. Precisa saber fazer três perguntas antes de rodar algo sugerido pela IA:

-   De onde veio essa dependência?
-   O que ela pode executar no meu ambiente?
-   Que credenciais estão disponíveis se ela for maliciosa?

Se a resposta for vaga, o próximo passo não é instalar. É isolar, verificar e só então avançar.

## Referências

Referências usadas na apuração do texto.

1.  [Red Hat RHSB-2026-006 Supply chain compromise](https://access.redhat.com/security/vulnerabilities/RHSB-2026-006)
2.  [Microsoft Security Blog on Red Hat npm Miasma campaign](https://www.microsoft.com/en-us/security/blog/2026/06/02/preinstall-persistence-inside-red-hat-npm-miasma-credential-stealing-campaign/)
3.  [StepSecurity analysis of Phantom Gyp Miasma npm attack](https://www.stepsecurity.io/blog/binding-gyp-npm-supply-chain-attack-spreads-like-worm)
4.  [Snyk analysis of node-gyp supply chain compromise](https://snyk.io/blog/node-gyp-supply-chain-compromise-self-propagating-npm-worm-binding-gyp/)
5.  [Vapi response to June 3 supply chain incident](https://vapi.ai/blog/our-response-to-june-3-supply-chain-incident)
6.  [GitHub Changelog on npm v12 breaking changes](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/)
7.  [GitHub Changelog on security validation for third-party coding agents](https://github.blog/changelog/2026-06-09-security-validation-for-third-party-coding-agents/)
8.  [GitHub Changelog on secret scanning with GitHub MCP Server](https://github.blog/changelog/2026-05-05-secret-scanning-with-github-mcp-server-is-now-generally-available/)
9.  [NSA release on MCP security design considerations](https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4496698/nsa-releases-security-design-considerations-for-ai-driven-automation-leveraging/)
10.  [Microsoft Security Blog on Claude Code GitHub Action case](https://www.microsoft.com/en-us/security/blog/2026/06/05/securing-ci-cd-in-agentic-world-claude-code-github-action-case/)
11.  [BleepingComputer report on Shai-Hulud PyPI packages](https://www.bleepingcomputer.com/news/security/new-shai-hulud-attack-trojanizes-19-science-focused-pypi-packages/amp/)
12.  [Socket Miasma Mini Shai-Hulud attack tracker](https://socket.dev/supply-chain-attacks/miasma-mini-shai-hulud-supply-chain-attack)

## Conteúdo relacionado

[

Insight23 de jun. de 2026

### Agentes de IA para programação em junho de 2026 e o novo workflow prático de engenharia

A semana de 17 de junho consolidou uma virada silenciosa para quem constrói software com IA. O assunto deixou de ser apenas qual modelo responde melhor no ...

](/insights/agentes-de-ia-para-programacao-em-junho-de-2026-e-o-novo)[

Insight20 de jun. de 2026

### Curso de IA para iniciantes: 3 critérios para escolher uma formação que gera resultado

Um bom curso de IA para iniciantes não vende mágica. Ele entrega uma forma de pensar, testar, medir e melhorar. Essa diferença importa porque inteligência ...

](/insights/curso-de-ia-para-iniciantes-3-criterios-para-escolher-uma-formacao-que)[

Insight14 de jun. de 2026

### Formação em IA para empresas falha sem liderança ativa: o plano para virar adoção real

A formação em IA para empresas não falha porque a aula é ruim. Ela falha quando a liderança trata IA como conteúdo, não como mudança de trabalho. Esse é o ...

](/insights/formacao-em-ia-para-empresas-falha-sem-lideranca-ativa-o-plano-para)