Vou ser direto: Vercel acaba de revelar uma das brechas de supply chain mais instrutivas que vimos em anos, e a causa raiz não foi um zero-day, um firewall mal configurado nem uma cadeia de exploits sofisticada. Foi um funcionário concedendo permissões OAuth “Permitir Tudo” a uma pequena ferramenta de produtividade com IA. Esse único clique escalou até comprometer ambientes internos completos, expor credenciais de clientes e gerar uma demanda de resgate de $2M por parte de um ator que opera sob a marca ShinyHunters no BreachForums.
Se você implanta na Vercel — ou se sua equipe usa ferramentas de IA conectadas ao seu Google Workspace — esta é a história que você precisa entender agora mesmo.
A Kill Chain: De Cheats de Roblox a Brecha Enterprise
A perícia pinta um quadro notavelmente detalhado, e cada elo dessa cadeia vale a pena examinar.
Passo 1 — O infostealer. Em fevereiro de 2026, um funcionário da Context.ai baixou scripts de auto-farm de Roblox e exploits de jogos no que parece ter sido uma máquina de trabalho. Esses downloads traziam um payload de Lumma stealer. O malware colheu credenciais corporativas do Google Workspace, Supabase, Datadog e Authkit — o toolkit completo de alguém com acesso de nível admin na Context.ai.
Passo 2 — O pivô para tokens OAuth. Context.ai é uma plataforma de IA empresarial que também oferecia um produto consumer chamado “AI Office Suite” — um workspace para construir apresentações e documentos com agentes de IA. Esse suite se conectava às contas do Google Workspace dos usuários via OAuth. Quando os atacantes comprometeram o ambiente AWS da Context.ai (detectado em março de 2026), também obtiveram tokens OAuth de usuários consumer desse suite.
Passo 3 — A conexão com Vercel. Vercel nunca foi cliente da Context.ai. Mas pelo menos um funcionário da Vercel se havia registrado no AI Office Suite usando sua conta enterprise do Google e concedeu permissões “Permitir Tudo”. Essa única concessão de OAuth deu aos atacantes um caminho direto ao Google Workspace da Vercel — e daí, aos ambientes da Vercel.
Passo 4 — Enumeração de variáveis de ambiente. Vercel distingue entre variáveis de ambiente “sensitive” (encriptadas em repouso, ilegíveis) e padrão. O atacante enumerou as variáveis não sensíveis, que — apesar do nome — continham API keys, tokens, credenciais de bases de dados e chaves de assinatura que os clientes não haviam marcado como sensíveis. Vercel descreve o atacante como “altamente sofisticado” com conhecimento profundo de seus sistemas e velocidade operacional notável.
Passo 5 — O resgate. Um threat actor que diz pertencer a ShinyHunters publicou no BreachForums oferecendo o suposto dataset — access keys, código-fonte, bases de dados internas, tokens do GitHub, tokens do NPM e 580 registros de funcionários — por $2 milhões começando com $500K em Bitcoin. Atores vinculados a ShinyHunters negaram participação nessa brecha específica, então a atribuição continua incerta.
O Que CrowdStrike Não Viu
Há uma camada incômoda aqui. Context.ai contratou CrowdStrike após o incidente de AWS em março. CrowdStrike investigou e Context.ai encerrou o ambiente afetado. Mas o comprometimento de tokens OAuth não foi identificado naquele momento — veio à tona apenas quando Vercel forneceu informações adicionais a Context.ai em 19 de abril. A inteligência de cibercrime de Hudson Rock havia sinalizado a infecção de infostealer do funcionário da Context.ai mais de um mês antes da divulgação da Vercel. Se essa exposição de credenciais tivesse sido detectada e revogada imediatamente, toda essa cascata de supply chain poderia ter sido prevenida.
Três Falhas, Não Uma
The Register colocou bem: todos os atores nessa história cometeram erros.
Context.ai tinha um funcionário cuja máquina foi comprometida por um Lumma stealer entregue através de downloads de exploits de jogos — sugerindo segurança de endpoint fraca e nenhum monitoramento efetivo de credenciais.
A investigação de CrowdStrike parece ter passado por alto o comprometimento de tokens OAuth durante a revisão forense inicial, detectando-o apenas depois que Vercel trouxe à tona a conexão semanas depois.
Vercel não restringiu as concessões de escopo OAuth no seu Google Workspace enterprise. Um funcionário individual pôde conceder permissões “Permitir Tudo” a uma ferramenta de IA externa — uma configuração que nunca deveria ter sido possível sob um Workspace adequadamente governado.
O Que Você Deveria Fazer Agora Mesmo
Se sua equipe implanta na Vercel ou usa ferramentas de IA conectadas ao Google Workspace, estas são as ações imediatas:
Verifique o IOC. Vá ao seu Google Admin Console → Security → Access and Data Control → API Controls → Manage Third-Party App Access. Procure por este OAuth Client ID: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Se aparecer, revogue imediatamente e inicie seu protocolo de response a incidentes.
Rotacione seus secrets da Vercel. Revise todas as variáveis de ambiente. Qualquer coisa armazenada como “non-sensitive” que na verdade contenha API keys, tokens ou credenciais de base de dados deveria ser rotacionada agora e re-marcada como sensitive. Vercel liberou novas funcionalidades no dashboard para facilitar isso.
Audite seus grants de OAuth. Liste cada app de terceiros conectada ao Google Workspace da sua organização. Para cada uma, pergunte a si mesmo: essa app precisa desses escopos? O grant foi revisado? Você pode restringi-lo a read-only ou escopos específicos? Se você é admin, considere configurar Google Workspace para exigir aprovação de admin para grants OAuth de escopo alto.
Revise sua classificação de variáveis de env. A distinção entre “sensitive” e “non-sensitive” na Vercel não é cosmética — determina a encriptação em repouso. Se você vinha sendo preguiçoso ao marcar variáveis como sensitive, essa brecha é a razão para arrumar isso hoje.
A Lição Mais Grande
Esta não é apenas uma história de Vercel. É uma história sobre a superfície de ataque crescente que criam as ferramentas de IA que pedem acesso OAuth ao seu workspace. Cada popup de “Conectar ao Google Drive,” “Acessar seu Gmail,” “Permitir todos os permissões” é um potencial caminho de movimento lateral para um atacante. E a maioria das organizações não governa esses grants em absoluto.
O playbook de 2024 era “tenha cuidado com quais pacotes npm você instala.” O playbook de 2026 precisa adicionar: “tenha o mesmo cuidado com quais ferramentas de IA você conecta às suas contas enterprise — e bloqueie os escopos quando o fizer.”
Um download de cheats de Roblox. Um grant de OAuth não revisado. Uma exposição de credenciais não monitorada. Isso é tudo o que foi necessário.
A investigação de Vercel está em andamento. Se surgirem detalhes adicionais, atualizaremos este artigo. Se você implanta na Vercel, verifique suas variáveis de ambiente hoje — não espere.