A cadeia de ataque que quase sequestrou o Zapier

A 'Zapocalypse' não foi um zero-day, mas uma cadeia de cinco falhas conhecidas, cada uma trivial isoladamente, e todas ignoradas em conjunto. O ataque começou com os.system('env') rodando livremente no sandbox do 'Code by Zapier', o que já deveria ser impossível em qualquer ambiente de execução não confiável. A partir daí, os pesquisadores escanearam a memória heap do Lambda para recuperar tokens STS órfãos, porque o Zapier usava del os.environ[k], que apaga referências, mas não limpa bytes da memória. Depois, exploraram uma função IAM chamada allow_nothing_role (nome enganoso) com permissões reais para listar e baixar imagens do ECR via API direta, contornando totalmente o Docker e seus logs. Um token NPM com bypass_2fa: true foi extraído do histórico de build do contêiner, não do sistema de arquivos, mas dos metadados do Dockerfile, acessíveis via ARG/ENV. O ponto crítico final era a publicação forçada no pacote privado zapier-design-system: uma única versão adulterada injetaria JS nos navegadores de todos os usuários logados, transformando o Zapier em uma plataforma de pivô para controle total de contas.

O mais preocupante não é o que foi explorado, mas o que poderia ter sido: essa cadeia daria acesso indireto a centenas de serviços conectados (Gmail, Slack, Salesforce, etc.) sem precisar de tokens OAuth brutos, bastava agir como o usuário dentro das automações já autorizadas. Uma chave MCP encontrada acidentalmente em uma imagem LiteLLM, vinculada à conta pessoal de um co-fundador, mostrou que segredos embutidos em artefatos de build são um risco imediato, mesmo fora de cadeias planejadas.

Na cobertura anterior sobre a campanha TrapDoor (28/05), destacamos ataques baseados em dependências maliciosas; na 'Zapocalypse', não há pacote contaminado, o código malicioso é escrito pelo usuário final dentro da própria plataforma. Enquanto o incidente do Checkmarx KICS (03/06) envolvia substituição de tags Docker oficiais, aqui as imagens eram legítimas, mas acessadas via API com credenciais roubadas do heap. E diferentemente do caso do VSCode (04/06), onde um clique bastava para roubar um token GitHub, a 'Zapocalypse' exigia exploração ativa de múltiplas camadas de configuração incorreta, mas com o mesmo resultado prático: comprometimento de identidades privilegiadas em tempo real.

Plataformas como Zapier, Make e n8n deixaram de ser ferramentas auxiliares: viraram a camada de controle de identidade para integrações críticas. Um único bloco de código Python executado por um usuário pode agora pivotar para repositórios privados, imagens Docker, registros de pacotes e até interfaces web de administração. Isso muda radicalmente a superfície de ataque, não é mais só sobre proteger o CI/CD ou o repositório, mas também o sandbox de execução de código de terceiros. Empresas que delegam automações para essas plataformas estão, na prática, concedendo permissões IAM, ECR e NPM a ambientes que não controlam. A mitigação exige mais do que boas práticas isoladas: exige validação estrita de permissões IAM *antes* de atribuir funções, uso obrigatório de BuildKit secrets (não ARG/ENV), rotação programática de tokens NPM de CI e monitoramento de tráfego egress *com contexto*, não apenas volume.