Em abril de 2026, a Vercel confirmou um incidente de segurança originado em um fornecedor terceiro, a Context.ai, cujo aplicativo OAuth no Google Workspace foi comprometido após um funcionário ser infectado pelo malware Lumma Stealer. A partir daí, o atacante chegou à conta corporativa de um funcionário da Vercel e conseguiu enumerar variáveis de ambiente de um subconjunto limitado de projetos de clientes — especificamente aquelas que não tinham sido marcadas como "sensitive", flag que na plataforma vinha desligado por padrão. O caso expõe três problemas estruturais que qualquer empresa de software no Brasil precisa olhar com atenção: a fragilidade dos relacionamentos OAuth com terceiros, o risco de configurações inseguras por padrão em plataformas de deploy, e a latência entre detecção e notificação em incidentes de plataforma.A Vercel publicou em 19 de abril de 2026 um boletim de segurança confirmando acesso não autorizado a sistemas internos da empresa.
O ponto de entrada não foi a Vercel diretamente.
Foi a Context.ai, uma fornecedora de analytics com IA que tinha um aplicativo OAuth autorizado no Google Workspace de funcionários da Vercel.
Em fevereiro de 2026, um funcionário da Context.ai foi infectado pelo Lumma Stealer — segundo a Hudson Rock e a CyberScoop, depois de baixar scripts de exploit para Roblox.
O malware exfiltrou credenciais, tokens de sessão e tokens OAuth corporativos.
Com isso, o atacante acessou o ambiente AWS da Context.ai em março, pegou tokens OAuth de usuários do produto Context AI Office Suite, e usou um desses tokens para entrar na conta Google Workspace de um funcionário da Vercel.
A partir da conta do Workspace, o atacante pivoteou para sistemas internos da Vercel e começou a enumerar variáveis de ambiente de projetos de clientes.
O CEO Guillermo Rauch descreveu a escalada como “uma série de manobras” a partir da conta comprometida, sem detalhar se a movimentação lateral foi via SSO federado, credenciais coletadas do e-mail, ou outra ferramenta OAuth interna.
Aqui entra o detalhe técnico que amplifica o impacto.
Na Vercel, variáveis de ambiente têm um flag chamado “sensitive”.
Quando a flag está ligada, o valor é criptografado em repouso e fica restrito — inclusive contra leitura por sistemas internos.
Quando está desligada — e essa era a configuração padrão no momento do incidente — a variável fica acessível via APIs internas, sem a mesma camada de proteção.
Isso significa que qualquer DATABASE_URL, STRIPE_SECRET_KEY, AWS_SECRET_ACCESS_KEY ou OPENAI_API_KEY que um desenvolvedor cadastrou sem explicitamente marcar como sensitive estava vulnerável a quem tivesse acesso interno.
Controle de segurança que exige opt-in manual, variável por variável, tem baixa adoção na prática — esse é o padrão observado em toda a indústria, e o incidente confirma o diagnóstico.
A Vercel já anunciou mudanças: o flag sensitive agora vem ligado por padrão em novas variáveis, a página de gerenciamento ficou mais clara, e o log de atividades ganhou melhorias.
Ainda assim, a comparação com outras plataformas mostra o tamanho da distância arquitetural.
HashiCorp Vault trata todos os segredos como criptografados com ACL por padrão.
AWS Secrets Manager e SSM Parameter Store usam tipos distintos (SecureString) com APIs separadas.
GitHub Actions mascara todos os segredos em logs automaticamente.
A tendência da indústria é clara: segredos deveriam viver em um secret manager dedicado, injetados em runtime, não armazenados como variáveis de ambiente numa plataforma de deploy.
Um dado adicional que apareceu nas respostas ao CEO no X: um cliente da Vercel, Andrey Zagoruiko, relatou ter recebido em 10 de abril uma notificação da OpenAI informando que uma chave de API estava exposta — uma chave que, segundo ele, só existia dentro da Vercel.
Isso cria uma janela de nove dias entre a primeira evidência pública de exposição e a divulgação oficial do incidente.
Não é prova de que a Vercel sabia do problema em 10 de abril.
Mas é um dado que importa para reguladores — sob GDPR, o prazo de 72 horas começa quando o controlador toma ciência — para auditores de SOC 2 e ISO 27001 que avaliam latência de detecção, e para clientes que precisam saber que a janela de exposição pode ter começado bem antes de 19 de abril.
Vale registrar que o próprio artigo da Trend Micro foi atualizado em 21 de abril para corrigir pontos importantes: o dwell time não foi de 22 meses como reportado inicialmente, mas de aproximadamente dois meses; o vetor inicial foi o Lumma Stealer na Context.ai, não um mecanismo desconhecido; e o impacto foi limitado a equipes cujo acesso foi comprometido, não uma exposição plataforma-wide.
O caso Vercel não é um evento isolado.
Em 24 de março, pacotes maliciosos do litellm (nas versões 1.82.7 e 1.82.8) foram publicados no PyPI usando credenciais de CI/CD roubadas do Trivy, da Aqua Security — o LiteLLM tem cerca de 3,4 milhões de downloads diários.
Em 31 de março, o pacote axios do npm (70 a 100 milhões de downloads semanais) foi comprometido por sequestro de conta de mantenedor, com uma versão maliciosa injetando um RAT cross-platform.
Em 19 de abril, a Vercel.
Três ataques em três semanas, três vetores diferentes, um alvo único: credenciais armazenadas em ferramentas de desenvolvedor.
Isso não é coincidência estatística.
É convergência — múltiplos atores descobrindo em paralelo a mesma fraqueza estrutural na fronteira de confiança entre registries de pacotes, CI/CD, provedores OAuth e plataformas de deploy.
Para quem constrói software no Brasil, especialmente quem opera SaaS hospedado em plataformas como Vercel, Netlify, Railway, Render e similares, o caso traz algumas lições práticas que transcendem a Vercel em si.
A primeira é tratar aplicativos OAuth autorizados no Google Workspace como fornecedores formais.
Cada OAuth app com escopo amplo (Drive, Gmail, Calendar) é um vendor com acesso persistente aos seus dados corporativos — deveria passar por revisão de risco, ter autorização periódica renovada, e ser monitorado contra uso anômalo.
A segunda é parar de tratar variáveis de ambiente como local adequado para segredos de longa duração.
Um projeto Vercel típico tem entre 10 e 30 variáveis de ambiente, e uma organização com 50 projetos pode ter entre 500 e 1.500 credenciais armazenadas nesse modelo.
Cada uma é um ponto de pivô potencial para um sistema downstream com seu próprio raio de impacto — banco de dados, provedor de pagamentos, cloud, autenticação, observabilidade, cadeia de supply.
Migrar para um secret manager dedicado (Vault, AWS Secrets Manager, Doppler, Infisical) com injeção em runtime deixa de ser paranoia e passa a ser arquitetura básica.
A terceira é operacional e quase nunca está no checklist: rotacionar credencial não invalida deploys antigos na Vercel.
Deploys anteriores continuam usando o valor antigo da variável até serem re-deployados ou explicitamente desativados.
Rotação sem redeploy deixa a credencial comprometida viva em qualquer artefato de deploy anterior que ainda esteja alcançável.
Toda rotação precisa ser seguida de redeploy completo ou desativação explícita dos deploys antigos.
A quarta é cultural: notificações não solicitadas de vazamento de credencial (OpenAI, Anthropic, GitHub, AWS, Stripe) não são ruído de fundo.
Elas são, na prática, o canal de early warning mais efetivo para esse tipo de incidente — na ausência de SIEM com regras calibradas para detectar enumeração anômala de segredos, uma mensagem automatizada de um provedor upstream pode ser o primeiro sinal de que algo está errado dentro da sua infraestrutura.
Há também uma afirmação do Rauch que merece atenção separada.
Ele disse acreditar que o grupo atacante “se moveu com velocidade surpreendente e entendimento profundo da Vercel” e que suspeita fortemente de aceleração por IA.
Atribuição baseada em velocidade é interpretativa por natureza, mas a categoria em si — operações adversárias aumentadas por IA — não é mais apenas especulativa.
A Microsoft publicou em abril de 2026 uma análise sobre campanhas de phishing de device-code usando IA generativa para gerar lures hiper-personalizados e orquestrar backend dinamicamente.
Se a velocidade de enumeração e movimentação lateral está sendo comprimida por ferramentas de IA, regras de detecção calibradas em janelas de dwell time e velocity de incidentes mais antigos podem estar gerando falsos negativos contra atacantes mais rápidos.
O caminho defensivo que se forma a partir dos três incidentes é objetivo.
Parar de armazenar credenciais de longa duração em variáveis de ambiente de plataforma; usar secret managers dedicados com injeção em runtime.
Parar de confiar implicitamente em aplicativos OAuth; auditar, monitorar, re-autorizar periodicamente.
Parar de assumir que a postura de segurança interna do seu provedor de plataforma é impenetrável; projetar o sistema para o cenário em que ele é comprometido.
Rotacionar proativamente e redeployar sempre.
E tratar notificação de vazamento vinda de provedor terceiro como sinal de alta prioridade, não como ruído de processo.
As organizações que vão atravessar bem o próximo incidente de plataforma — porque ele vai acontecer — são as que construíram sua arquitetura de credenciais assumindo que ele já aconteceu.
Fontes: Boletim de Segurança da Vercel (19-21 de abril de 2026); análise da Trend Micro Research “Vercel April 2026 breach”; declarações de Guillermo Rauch no X; Context.ai security bulletin; Hudson Rock; CyberScoop.
