Cadeia Zapocalypse: O Efeito Dominó que Quase Comprometeu o Zapier

Estágio 2: O Role da AWS com Nome Enganoso

Com os tokens em mãos, os pesquisadores assumiram o que parecia ser um papel (role) de privilégios mínimos na AWS, ironicamente chamado de allow_nothing_role (algo como "cargo que não permite nada"). Na prática, o nome era uma farsa. O role concedia quatro permissões para o serviço de registro de containers, o ECR: ecr:DescribeRepositories, ecr:ListImages, ecr:BatchGetImage e ecr:GetDownloadUrlForLayer .

Essas quatro permissões de leitura foram suficientes para listar e baixar imagens de container diretamente pela API da AWS. Os pesquisadores mapearam 1.111 repositórios de produção e começaram a baixar as imagens .

Estágio 3: O Segredo Escondido na Imagem Docker

Ao analisar o histórico de uma das imagens de container baixadas, eles encontraram um verdadeiro tesouro: um token de publicação do NPM, o gerenciador de pacotes do Node.js. O token havia vazado porque foi passado para o processo de build através de uma instrução ARG no Dockerfile. Esse tipo de instrução fica gravado para sempre no campo history[] da imagem, tornando-a um registro imutável e acessível a qualquer pessoa que consiga baixá-la .

Estágio 4: Acesso de Escrita sem Autenticação de Dois Fatores

O token do NPM recuperado era ainda mais perigoso do que parecia. Ele possuía três propriedades críticas:

action: write

name: null

bypass_2fa: true

Estágio 5: O Acesso à Máquina do Usuário

O último elo revela o impacto devastador. O pacote zapier-design-system é carregado em toda sessão autenticada no site zapier.com. Os pesquisadores confirmaram esse caminho usando as ferramentas de desenvolvedor do navegador e pararam por aí, sem publicar nenhum código malicioso .

Se um invasor tivesse seguido adiante, uma versão envenenada do pacote executaria código JavaScript malicioso dentro da origem autenticada do Zapier. A partir dessa posição, um criminoso poderia criar Zaps, Tabelas e servidores MCP, além de operar integrações existentes em nome de usuários legítimos. Embora tokens de acesso a serviços de terceiros não fossem expostos diretamente, o estrago operacional ainda seria imenso .

Importante: Essa descoberta de pesquisa é diferente de um ataque real à cadeia de suprimentos que o Zapier sofreu em novembro de 2025, quando o worm Shai Hulud 2.0 comprometeu sua conta NPM e infectou 425 pacotes .

A Resposta Rápida do Zapier

Diante da gravidade, o Zapier agiu com agilidade:

• 12 de fevereiro de 2026: A Token Security enviou o relatório com a descoberta .
• Em até quatro dias: A empresa já havia analisado o problema, revogado o token NPM vazado e restringido as permissões do role da AWS .
• 5 de março de 2026: A correção foi confirmada como completa. O Zapier declarou não ter encontrado evidências de exploração maliciosa dessa falha específica .

Os pesquisadores receberam a recompensa máxima do programa de bugs, no valor de US$ 3.000, e a empresa se comprometeu a revisar esse limite máximo futuramente .

A Grande Lição: O Buraco Entre os Times

Yair Balilti, líder da equipe de pesquisa da Token Security, capturou a essência do problema em uma frase:

"Cada elo da corrente era um padrão conhecido. A vulnerabilidade estava na composição, e a composição é exatamente o que fica no vácuo entre as equipes. O sandbox da Lambda, o ECR e IAM, o token do GitLab CI, a publicação no NPM, o navegador — cada parte pertence a um grupo diferente, e cada um pode olhar para seu pedaço e, com razão, concluir que está tudo bem. O risco só aparece quando você traça um caminho que cruza todos eles."

A grande lição do caso Zapocalypse é que nenhum time era dono de uma vulnerabilidade individual. Para a equipe da Lambda, vasculhar a memória em busca de um token que já deveria ter sido removido não era um problema. Para a equipe de identidade e acesso (IAM), o role era somente leitura para o ECR. Para o time de build, passar o token como ARG era um processo normal. Cada decisão foi individualmente razoável. Mas a soma delas, conectando cinco sistemas diferentes, foi catastrófica .

Isso demonstra que as revisões de segurança precisam abandonar a análise isolada de cada componente. É fundamental realizar auditorias que cruzem as fronteiras dos sistemas, mapeando como configurações aparentemente inofensivas podem se compor em perigosas cadeias de ataque quando interagem entre si .