No dia 19 de abril de 2026, a Vercel, empresa por trás do Next.js e referência absoluta em deploy de aplicações front-end, publicou um boletim de incidente confirmando acesso não autorizado a sistemas internos. Poucas horas antes, um ator de ameaça usando o codinome ShinyHunters havia listado num novo domínio do BreachForums um pacote supostamente roubado da empresa. O preço pedido era de US$ 2 milhões, cerca de R$ 9 milhões na cotação atual.

A oferta incluía bancos de dados internos, chaves de acesso, código-fonte e registros de aproximadamente 580 funcionários. Além disso, o vendedor escreveu uma frase que deixou a comunidade dev em alerta máximo: “este pode ser o maior ataque à cadeia de suprimentos de todos os tempos, se feito da forma certa”.

Posteriormente, o post foi deletado e o grupo ShinyHunters original negou envolvimento. Ainda assim, o incidente é real, foi confirmado pela Vercel e merece atenção redobrada de qualquer desenvolvedor que dependa da plataforma — direta ou indiretamente.

Anatomia do ataque: nem firewall, nem zero-day

Antes de tudo, é importante destacar o que não aconteceu: ninguém invadiu o perímetro da Vercel por força bruta. Não houve exploração de CVE. Tampouco foi quebrada a criptografia da plataforma. O ataque seguiu um caminho muito mais sutil — e, justamente por isso, mais perigoso.

A cadeia se desenrolou da seguinte forma:

Primeiro, em fevereiro de 2026, um funcionário da Context.ai , startup que oferece uma suíte de produtividade baseada em IA — foi infectado pelo malware Lumma Stealer. Segundo a Hudson Rock, especializada em inteligência sobre infostealers, o vetor inicial pode ter sido o download de scripts auto-farm do Roblox.

Em seguida, o atacante usou as credenciais roubadas para se mover dentro do ambiente AWS da Context.ai. Entretanto, o prêmio principal não estava ali. O verdadeiro tesouro eram os tokens OAuth conectados ao Google Workspace dos clientes da Context.ai.

Por fim, um funcionário da Vercel havia instalado a extensão do Chrome da Context.ai, autenticando-se com sua conta corporativa do Google e concedendo permissão “Allow All”. Com o token OAuth comprometido, o atacante simplesmente entrou no Google Workspace desse funcionário, sem precisar de senha, sem precisar burlar MFA, sem disparar alertas óbvios.

Por que variáveis “não sensíveis” se tornaram o calcanhar de Aquiles

Aqui está a parte que todo dev que usa Vercel precisa entender direito.

A plataforma da Vercel armazena variáveis de ambiente com criptografia completa em repouso quando elas são marcadas como “sensitive”. No entanto, existe também a categoria “non-sensitive”, projetada por conveniência para dados que supostamente não exigem essa proteção. Foi exatamente nessa zona cinzenta que o atacante atuou.

O CEO Guillermo Rauch foi direto ao reconhecer o problema. “A Vercel armazena todas as variáveis de ambiente dos clientes com criptografia completa em repouso”, afirmou em postagem no X. Contudo, ele acrescentou: “temos uma funcionalidade que permite designar variáveis de ambiente como ‘não sensíveis’. Infelizmente, o invasor obteve acesso adicional por meio dessa enumeração”.

Em outras palavras, muitas equipes deixaram tokens, chaves de API e credenciais auxiliares marcadas como não sensíveis — provavelmente por simples descuido ou pela falsa sensação de que aquele dado específico “não era tão crítico assim”. Como resultado, o atacante pôde lê-las em texto puro pelo dashboard e pela API.

A Vercel já anunciou uma mudança importante: a partir de agora, novas variáveis de ambiente são criadas com o flag “sensitive” por padrão. Ainda assim, todo o histórico anterior continua sendo um campo minado em potencial.

OAuth: a porta dos fundos que ninguém audita

Esse caso escancara um problema que vai muito além da Vercel. A cada nova ferramenta SaaS de IA que um desenvolvedor instala, novos tokens OAuth são gerados — e raramente alguém volta para revogá-los ou auditar suas permissões.

Vale destacar alguns pontos críticos:

Primeiramente, o OAuth permite acesso de longa duração e independente de senha. Trocar a senha do Google não invalida o token. Em segundo lugar, escopos como “Allow All” concedem leitura total ao Google Drive, Gmail e outros serviços, sem que o usuário sequer perceba o tamanho da permissão. Por fim, raramente esses grants passam por revisão de segurança formal, especialmente em empresas onde a adoção de IA acontece de forma orgânica e bottom-up.

Aliás, foi justamente esse padrão que se repetiu em 2025 com Salesloft Drift, Gainsight e outros. Agora, é a vez da dupla Context.ai e Vercel.

O que fazer agora se você usa Vercel

Se você ou sua equipe deployam aplicações na Vercel, algumas ações são prioridade imediata.

Primeiro, faça a rotação de todas as variáveis de ambiente que não estavam marcadas como sensíveis. Isso inclui chaves de API, tokens de banco de dados, secrets de assinatura JWT e qualquer credencial que tenha trafegado pela plataforma. Em seguida, audite os logs de atividade do seu projeto Vercel em busca de deploys ou acessos anômalos nas últimas semanas.

Adicionalmente, revise quais aplicações OAuth estão conectadas ao seu Google Workspace corporativo. Procure especialmente extensões de IA instaladas pelos times — muitas vezes elas têm permissões que ninguém aprovou formalmente. Caso encontre algo duvidoso, revogue o acesso imediatamente.

Por outro lado, se você mantém pacotes npm ou repositórios GitHub conectados à Vercel, vale fazer um scan completo em busca de commits suspeitos. A Vercel já confirmou, em colaboração com GitHub, Microsoft, npm e Socket, que Next.js, Turbopack, AI SDK e demais pacotes oficiais não foram comprometidos. Mesmo assim, a vigilância da comunidade segue essencial.

A lição maior: o perímetro da sua aplicação não é mais o seu perímetro

Talvez o aprendizado mais importante seja conceitual. Durante anos, a segurança em desenvolvimento focou em hardening da própria aplicação — injection, XSS, CSRF, dependências vulneráveis. Esses problemas continuam existindo, claro. Entretanto, hoje o ataque mais provável não vem por aí.

Hoje, ele vem por uma extensão do navegador que um colega instalou. Vem por um token OAuth concedido há seis meses para uma ferramenta de IA esquecida. Vem por uma variável de ambiente marcada como “não sensível” porque, naquela sexta-feira corrida, ninguém quis pensar muito sobre classificação.

Em síntese, a superfície de ataque do desenvolvedor moderno é definida pelas integrações que ele aceita — não pelo código que ele escreve. A Vercel é apenas o caso mais visível dessa nova realidade. Não será o último.

Por enquanto, a investigação segue em andamento, com participação da Mandiant e outras firmas. Conforme novas informações forem divulgadas pela Vercel, é provável que a comunidade descubra ainda mais detalhes técnicos sobre como o atacante operou dentro do ambiente. Até lá, vale aplicar o princípio do menor privilégio em tudo: tokens, escopos, variáveis e, principalmente, na confiança que se deposita em qualquer ferramenta terceirizada.