Em 19 de abril de 2026, a Vercel, plataforma de cloud amplamente utilizada por desenvolvedores e criadora do popular framework Next.js, confirmou publicamente um incidente de segurança envolvendo acesso não autorizado a sistemas internos da empresa. A confirmação veio após um ator de ameaça, utilizando o pseudônimo ShinyHunters, publicar em um fórum hacker a venda de dados supostamente roubados da companhia por US$ 2 milhões. O que torna este incidente particularmente alarmante não é apenas a escala da exposição, mas sim a cadeia de ataque: tudo começou com o comprometimento de uma ferramenta de inteligência artificial de terceiros chamada Context.ai, cujo aplicativo OAuth do Google Workspace foi explorado para escalar o acesso até os ambientes internos da Vercel. A investigação revela que o tempo de permanência do atacante pode ter sido de aproximadamente 22 meses, desde a primeira fase do comprometimento até a divulgação pública.
Este incidente é um caso exemplar de ataque à cadeia de suprimentos via OAuth e expõe fragilidades fundamentais na forma como empresas de tecnologia gerenciam integrações com ferramentas de IA, permissões de aplicativos OAuth e armazenamento de segredos em plataformas de deployment.
A Origem: Context.ai e o Comprometimento Inicial
A Context.ai é uma empresa que oferecia, entre outros produtos, o “AI Office Suite”, uma ferramenta de produtividade voltada para consumidores que permitia trabalhar com agentes de IA para criar apresentações, documentos e planilhas. Esse produto consumidor foi lançado em junho de 2025 e oferecia um recurso que permitia aos usuários habilitar agentes de IA para executar ações em seus aplicativos externos, facilitado por um serviço de terceiros.
O ponto crucial é que a Context.ai mantinha em sua página de segurança (context.ai/security) certificações SOC 2 Type II e ISO 27001, o que em teoria atestava a maturidade e a adequação de seus controles de segurança. Essas certificações são frequentemente exigidas por empresas na hora de avaliar fornecedores e parceiros, e muitas organizações confiam nelas como indicadores de que os dados estarão protegidos adequadamente. No entanto, como este incidente demonstra de forma contundente, uma certificação SOC 2 não é garantia de imunidade contra ataques. O SOC 2 avalia se controles existem e operam conforme projetado durante um período auditado, mas não necessariamente cobre todos os cenários de ataque, nem garante que funcionários individuais sigam práticas seguras em seus dispositivos pessoais. Este é um alerta importante para toda a indústria: confiar cegamente em selos de compliance pode criar uma falsa sensação de segurança.
O Lumma Stealer e o Funcionário da Context.ai
A empresa de inteligência de ameaças Hudson Rock publicou uma investigação que conecta todo o incidente a uma infecção por infostealer ocorrida em fevereiro de 2026. Segundo a análise da Hudson Rock, um funcionário da Context.ai com privilégios de acesso sensíveis teve sua máquina comprometida pelo Lumma Stealer, um dos infostealers mais ativos do ecossistema cibercriminoso atual.
Os logs do histórico de navegação do funcionário infectado revelam um padrão clássico de como essas infecções começam: o usuário estava ativamente procurando e baixando exploits de jogos, especificamente scripts de “auto farm” e executores para Roblox. Esses tipos de downloads maliciosos são vetores notórios para a implantação do Lumma Stealer. A infecção resultou na coleta massiva de credenciais corporativas, incluindo credenciais do Google Workspace, além de chaves e logins para Supabase, Datadog e Authkit.
Entre os registros comprometidos estava a conta support@context.ai, que provavelmente permitiu ao atacante escalar privilégios, contornar controles de segurança e pivotar com sucesso para a infraestrutura da Vercel. A Hudson Rock identificou que a Context.ai possuía apenas uma única infecção por infostealer em seu banco de dados, exatamente este funcionário, aproximadamente um mês antes do incidente. Essa correlação única torna altamente provável que esta infecção específica tenha sido o método de acesso inicial utilizado para infiltrar a organização.
Esse dado é extraordinariamente relevante: a Hudson Rock obteve os dados dessa credencial comprometida mais de um mês antes da divulgação pública. Se a infecção pelo infostealer tivesse sido identificada e as credenciais expostas revogadas imediatamente, todo este ataque à cadeia de suprimentos poderia ter sido completamente prevenido.
A Cadeia de Ataque Completa da Vercel
A análise completa da cadeia de ataque, combinando informações do boletim oficial da Vercel, do comunicado da Context.ai, da declaração do CEO Guillermo Rauch no X e da pesquisa da Trend Micro, revela um ataque em cinco estágios que explorou relações de confiança OAuth de forma magistral.
No primeiro estágio, o comprometimento do aplicativo OAuth de terceiros, o atacante utilizou as credenciais roubadas pelo Lumma Stealer para acessar a infraestrutura da Context.ai. A empresa identificou e bloqueou o acesso não autorizado ao seu ambiente AWS em março de 2026, mas o comprometimento dos tokens OAuth de seus usuários consumidores já havia ocorrido. O aplicativo OAuth do Google Workspace da Context.ai (ID do cliente: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com) foi o vetor de entrada.
No segundo estágio, o takeover da conta Google Workspace, pelo menos um funcionário da Vercel havia se cadastrado no AI Office Suite da Context.ai utilizando sua conta corporativa Google Workspace da Vercel e concedido permissões “Allow All”. As configurações internas de OAuth da Vercel aparentemente permitiram que essa ação concedesse essas permissões amplas no Google Workspace corporativo da empresa. Com o token OAuth comprometido, o atacante ganhou acesso à conta Google Workspace do funcionário sem precisar de senha, sem acionar MFA e sobrevivendo a rotações de senha. Os tokens OAuth mantêm acesso persistente que não requer a senha do usuário, sobrevive a rotações de senha, frequentemente possui escopos amplos (email, Drive, calendário) e raramente é auditado após a autorização inicial.
No terceiro estágio, o acesso a sistemas internos, a partir da conta Workspace comprometida, o atacante pivotou para sistemas internos da Vercel. O CEO Guillermo Rauch descreveu a escalação como “uma série de manobras que escalaram a partir da conta Google Workspace comprometida de nosso colega”. O usuário comprometido era um membro central da equipe “context-inc” no Vercel, com acesso direto a endpoints administrativos críticos, incluindo configurações de variáveis de ambiente, configurações gerais do projeto e logs de produção e staging.
No quarto estágio, a enumeração de variáveis de ambiente, o atacante acessou os sistemas internos da Vercel com privilégios suficientes para enumerar variáveis de ambiente de projetos de clientes. Um ponto fundamental: a Vercel armazena todas as variáveis de ambiente de clientes totalmente criptografadas em repouso, porém a plataforma oferece a capacidade de designar variáveis como “não sensíveis”. As variáveis não marcadas como “sensíveis” ficam descriptografáveis em texto simples e são visíveis no dashboard, acessíveis via APIs internas e não criptografadas em repouso. Através da enumeração dessas variáveis não sensíveis, o atacante obteve acesso adicional a chaves de API, tokens, strings de conexão de banco de dados, chaves de assinatura e outros segredos que clientes haviam armazenado sem marcar como sensíveis.
No quinto estágio, a exploração downstream potencial, as variáveis de ambiente expostas comumente contêm credenciais para serviços downstream. Um relato público de um cliente da Vercel, Andrey Zagoruiko, descreveu ter recebido uma notificação da OpenAI sobre uma chave vazada em 10 de abril, para uma chave de API que, segundo ele, existia apenas na Vercel. Isso sugere que pelo menos uma credencial exposta foi detectada “na natureza” nove dias antes da divulgação pública da Vercel.
O Tempo de Permanência: 22 Meses
A análise da Trend Micro estima que o ataque abrangeu aproximadamente 22 meses, desde o comprometimento inicial do OAuth da Context.ai (por volta de junho de 2024) até a divulgação pública da Vercel (19 de abril de 2026). Este tempo de permanência é consistente com outras intrusões baseadas em OAuth, onde os atacantes aproveitam permissões legítimas de aplicativos que raramente acionam controles de detecção padrão. Compounding este problema, os logs de auditoria OAuth do Google Workspace são retidos por apenas seis meses por padrão em muitos planos de assinatura, o que significa que a visibilidade forense sobre a atividade de comprometimento mais antiga provavelmente já havia desaparecido antes que os investigadores pudessem examinar.
O Que o Atacante Alega ter Obtido
O ator de ameaça publicou no BreachForums sob o pseudônimo ShinyHunters oferecendo os dados da Vercel por US$ 2 milhões. As alegações incluem: um arquivo com 580 registros de funcionários contendo nomes, endereços de email da Vercel, status de conta e timestamps de atividade (compartilhado como prova); acesso a múltiplas contas de funcionários com acesso a várias implantações internas; tokens NPM e tokens GitHub; chaves de API de implantações internas; código fonte e acesso a bancos de dados; dados do Linear workspace interno da Vercel e de sistemas de gerenciamento de usuários.
Em mensagens compartilhadas no Telegram, o ator de ameaça também afirmou estar em contato com a Vercel sobre o incidente e que discutiram uma suposta demanda de resgate de US$ 2 milhões. No entanto, é importante notar que membros conhecidos do grupo ShinyHunters negaram ao BleepingComputer estarem envolvidos neste incidente. O post no BreachForums oferecendo os dados aparentemente foi deletado, e a atribuição real permanece incerta. A Vercel não verificou as alegações do atacante sobre os dados.
O CEO Suspeita de Uso de IA pelos Atacantes
Em sua declaração pública na plataforma X em 19 de abril, o CEO da Vercel, Guillermo Rauch, fez uma observação notável: “Acreditamos que o grupo atacante seja altamente sofisticado e, eu suspeito fortemente, significativamente acelerado por IA. Eles se moveram com velocidade surpreendente e compreensão profunda da Vercel.” Esta declaração é significativa por ser uma das primeiras atribuições públicas de “aceleração por IA” feita por um CEO de empresa afetada. A Trend Micro observou que, se a avaliação de Rauch refletir algo real, os sinais forenses subjacentes provavelmente incluiriam velocidade de enumeração que excede o ritmo manual, construção de consultas contextualmente conscientes da terminologia específica da Vercel, comportamento adaptativo em resposta a erros e artefatos de engenharia social que parecem autenticamente locais em vez de traduzidos ou baseados em templates.
A Resposta da Vercel
A Vercel publicou um boletim de segurança continuamente atualizado e tomou diversas ações. A empresa confirmou que os projetos open source Next.js, Turbopack e outros permanecem seguros, afastando o cenário mais temido de um release de framework envenenado. Engajou a Mandiant (pertencente ao Google), firmas adicionais de cibersegurança e autoridades policiais. Notificou diretamente os clientes identificados como impactados e recomendou rotação imediata de credenciais. Publicou o indicador de comprometimento (IOC) do aplicativo OAuth para apoiar a comunidade ampla na investigação. Implementou mudanças no dashboard, incluindo uma página de visão geral de variáveis de ambiente e uma interface melhorada para criação e gerenciamento de variáveis sensíveis. Engajou diretamente a Context.ai para entender o escopo completo do comprometimento subjacente.
A Resposta da Context.ai
A Context.ai publicou seu próprio comunicado de segurança, revelando que em março de 2026 identificou e bloqueou o acesso não autorizado ao seu ambiente AWS. Engajou a CrowdStrike para conduzir a investigação forense. Reconheceu que o atacante também provavelmente comprometeu tokens OAuth de alguns de seus usuários consumidores. Afirmou explicitamente que a Vercel não é cliente da Context, mas que pelo menos um funcionário da Vercel se cadastrou no AI Office Suite usando sua conta corporativa Google Workspace e concedeu permissões “Allow All”. O produto consumidor AI Office Suite foi totalmente descontinuado e os ambientes associados foram encerrados. O produto enterprise atual da Context, o Bedrock, roda em ambientes dos próprios clientes e é arquiteturalmente distinto dos sistemas legados do consumidor, não sendo afetado pelo incidente.
O Problema de Design das Variáveis de Ambiente
O aspecto mais consequencial desta violação não é o vetor de acesso inicial, pois comprometimentos OAuth são um risco conhecido e estudado. O problema é o modelo de sensibilidade de variáveis de ambiente da Vercel, que criou uma configuração padrão insegura para segredos de clientes.
Na Vercel, as variáveis de ambiente possuem uma flag “sensitive” que controla as restrições de acesso. O estado padrão para todas as novas variáveis é NÃO sensível, o que significa que são visíveis no dashboard, acessíveis via APIs internas e não criptografadas em repouso. Para marcar como sensível, o desenvolvedor precisa explicitamente ativar a flag, que então mascara o valor após a criação, restringe o acesso e criptografa em repouso. A escolha crítica de design é que a flag sensível está desativada por padrão. Cada DATABASE_URL, API_KEY, STRIPE_SECRET_KEY ou AWS_SECRET_ACCESS_KEY adicionada por um desenvolvedor que não ativou explicitamente esta flag estava armazenada sem criptografia em repouso no modelo de acesso interno da Vercel. Como a Trend Micro observou: “Qualquer controle de segurança que requer opt in explícito para cada segredo individual, sem guardrails ou padrões, terá uma baixa taxa de adoção na prática.”
Em comparação, plataformas como HashiCorp Vault criptografam todos os segredos com ACL por padrão, e o GitHub Actions mascara todos os segredos nos logs por padrão. A indústria está se movendo em direção ao armazenamento de segredos dedicado em vez de armazenamentos de variáveis de ambiente com níveis de sensibilidade.
A Falsa Segurança do SOC 2
Este incidente levanta questões profundas sobre a confiança depositada em certificações de compliance. A Context.ai mantinha certificações SOC 2 Type II e ISO 27001, disponibilizando relatórios de avaliação sob NDA. Essas são certificações que custam dezenas de milhares de dólares para obter e manter, e que são frequentemente o critério decisivo para empresas ao avaliar se devem integrar uma ferramenta de terceiros em seus fluxos de trabalho.
Porém, o que o SOC 2 realmente avalia é se controles existem e operam conforme projetado durante o período auditado. Ele não avalia se um funcionário individual está baixando scripts de exploit de Roblox em sua máquina de trabalho. Não detecta que credenciais foram roubadas por um infostealer em fevereiro e não foram revogadas. Não impede que tokens OAuth comprometidos sejam utilizados para pivotar para organizações de terceiros. A lição é clara: certificações de compliance são um ponto de partida, não uma linha de chegada. Organizações precisam ir além dos selos e implementar monitoramento contínuo, detecção de infostealers, gerenciamento rigoroso de OAuth e princípios de menor privilégio que funcionem independentemente de certificações.
Credential Fan Out: O Efeito Cascata
O termo “credential fan out” descreve como uma única violação de plataforma se espalha em cascata para cada serviço downstream autenticado por credenciais armazenadas nessa plataforma. Um único projeto na Vercel comumente contém de 10 a 30 variáveis de ambiente. Em escala organizacional, um portfólio de 50 projetos poderia ter de 500 a 1.500 credenciais dentro da plataforma. Cada credencial é um potencial ponto de pivô para um sistema inteiramente separado com seu próprio raio de explosão. As categorias de credenciais tipicamente armazenadas incluem credenciais de banco de dados (acesso completo aos dados), credenciais de cloud como AWS, GCP e Azure (comprometimento de conta cloud), chaves de processadores de pagamento como Stripe (dados financeiros, fraude de reembolso), segredos de autenticação como JWT (falsificação de sessão, account takeover), chaves de email como SendGrid (phishing a partir de domínios confiáveis), tokens de monitoramento como Datadog (manipulação de telemetria) e tokens de código fonte como GitHub e NPM (injeção na cadeia de suprimentos).
Contexto Mais Amplo: A Onda de Ataques à Cadeia de Suprimentos
A violação da Vercel não ocorreu isoladamente. O período de março a abril de 2026 viu uma concentração sem precedentes de ataques à cadeia de suprimentos de software. Em 24 de março, o LiteLLM sofreu comprometimento via pacotes maliciosos no PyPI usando credenciais de CI/CD roubadas do Trivy. Em 31 de março, o Axios foi comprometido via sequestro de conta de mantenedor no npm, com injeção de um RAT pela Microsoft atribuída ao Sapphire Sleet, ator patrocinado pelo estado norte coreano. E em 19 de abril, a Vercel teve seu aplicativo OAuth comprometido com acesso em nível de plataforma a segredos de deployment de clientes. Três ataques em três semanas. Três vetores diferentes. O mesmo alvo: as credenciais e segredos que desenvolvedores armazenam em suas toolchains.
Indicador de Comprometimento (IOC)
O IOC publicado pela Vercel para apoiar a comunidade é o seguinte aplicativo OAuth: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Administradores de Google Workspace devem verificar imediatamente se este aplicativo foi autorizado em seus ambientes, acessando Admin Console, Segurança, Controles de API, Gerenciar acesso de aplicativos de terceiros e pesquisando por este Client ID. Se encontrado, o acesso deve ser revogado imediatamente e o protocolo de resposta a incidentes deve ser iniciado.
Recomendações de Segurança Dolutech
Para clientes da Vercel, as ações imediatas incluem: rotacionar todas as variáveis de ambiente que não foram marcadas como sensíveis, independentemente de acreditar que foram acessadas, pois o custo de uma rotação desnecessária é trivial comparado ao custo de uma credencial comprometida. Realizar redeploy de todos os ambientes após a rotação, pois a rotação sozinha não invalida deployments antigos que continuam usando o valor da credencial antiga. Habilitar a flag “sensitive” em todas as variáveis de ambiente que contenham qualquer forma de credencial, token, chave ou segredo. Revisar logs de atividade para sinais de atividade suspeita. Investigar deployments recentes para qualquer coisa inesperada ou suspeita. Rotacionar tokens de Deployment Protection. Garantir que Deployment Protection esteja configurado no mínimo como Standard.
Para administradores de Google Workspace, mesmo sem usar a Vercel, é necessário auditar as concessões OAuth no console administrativo e pesquisar pelo Client ID malicioso publicado como IOC. Revogar acesso de qualquer aplicação que não está mais em uso ativo. Implementar revisão periódica de todas as aplicações OAuth autorizadas.
Para equipes de segurança em geral, recomendamos tratar concessões OAuth como relacionamentos com fornecedores, adicionando as ao inventário de riscos de terceiros. Migrar segredos para gerenciadores dedicados como HashiCorp Vault, AWS Secrets Manager, Doppler ou Infisical, injetando segredos em runtime em vez de armazená los como variáveis de ambiente de plataforma. Implementar autenticação baseada em OIDC para pipelines de CI/CD e deployment onde suportado, eliminando credenciais de longa duração. Implementar monitoramento de aplicações OAuth com soluções comerciais ou com o gerenciamento nativo do Google Workspace. Estabelecer automação de rotação de credenciais com ciclos de 30 a 90 dias independentemente de incidentes. Monitorar notificações de credenciais vazadas de provedores como OpenAI, Anthropic, GitHub, AWS e Stripe, pois agora são um canal primário de alerta antecipado para violações em nível de plataforma.
Implicações Regulatórias
Organizações afetadas pela exposição de credenciais devem avaliar obrigações de notificação sob GDPR (se credenciais expostas forneciam acesso a sistemas contendo dados pessoais da UE, o relógio de notificação de 72 horas pode ter começado na confirmação da exposição), LGPD no Brasil (exposição de dados pessoais de funcionários ou clientes brasileiros pode acionar requisitos de comunicação à ANPD), PCI DSS (se credenciais de processadores de pagamento foram expostas, procedimentos de resposta a incidentes PCI podem ser aplicáveis), SOC 2 (organizações com obrigações SOC 2 devem documentar o incidente, ações de rotação de credenciais e controles atualizados) e regras de cibersegurança da SEC para empresas públicas.
Linha do Tempo Resumida
Junho de 2024: aplicativo OAuth do Google Workspace da Context.ai é comprometido. De junho de 2024 a 2025: atacante mantém acesso persistente via token OAuth comprometido. Entre final de 2024 e início de 2025: atacante pivota do acesso OAuth da Context.ai para a conta Google Workspace de um funcionário da Vercel. De início a meados de 2025: sistemas internos da Vercel são acessados e enumeração de variáveis de ambiente de clientes começa. Fevereiro de 2026: funcionário da Context.ai é infectado pelo Lumma Stealer após baixar exploits de Roblox. Março de 2026: Context.ai identifica e bloqueia acesso não autorizado ao seu ambiente AWS, engaja CrowdStrike. 10 de abril de 2026: cliente da Vercel recebe notificação da OpenAI sobre chave de API vazada. 19 de abril de 2026: Vercel publica boletim de segurança, CEO Guillermo Rauch nomeia Context.ai publicamente no X. Ator de ameaça sob pseudônimo ShinyHunters publica dados no BreachForums pedindo US$ 2 milhões. 20 de abril de 2026: Hudson Rock publica investigação ligando o incidente à infecção por Lumma Stealer.
Conclusão
A violação da Vercel é mais do que um incidente isolado. É a manifestação mais recente de uma vulnerabilidade estrutural na forma como a indústria de software gerencia segredos e relações de confiança. O fato de que uma cadeia de ataque que começou com um funcionário baixando cheats de Roblox terminou com a potencial exposição de milhares de credenciais de clientes de uma das maiores plataformas de deployment do mundo demonstra a fragilidade das interconexões no ecossistema moderno de desenvolvimento.
A lição mais importante para organizações brasileiras e portuguesas que utilizam a Vercel, ou qualquer plataforma similar, é que cada ferramenta de IA integrada, cada aplicação OAuth autorizada e cada variável de ambiente armazenada é uma relação de confiança que precisa ser gerenciada, monitorada e tratada com o mesmo rigor que se aplica a fornecedores contratados. Certificações SOC 2 e ISO 27001 são importantes, mas não substituem a vigilância contínua. A Dolutech continuará acompanhando os desdobramentos deste incidente e publicará atualizações conforme novas informações emergirem.
Referências
Vercel Security Bulletin: https://vercel.com/kb/bulletin/vercel-april-2026-security-incident
Context.ai Security Update: https://context.ai/security-update
The Hacker News, “Vercel Breach Tied to Context AI Hack Exposes Limited Customer Credentials”: https://thehackernews.com/2026/04/vercel-breach-tied-to-context-ai-hack.html
BleepingComputer, “Vercel confirms breach as hackers claim to be selling stolen data”: https://www.bleepingcomputer.com/news/security/vercel-confirms-breach-as-hackers-claim-to-be-selling-stolen-data/
SecurityWeek, “Next.js Creator Vercel Hacked”: https://www.securityweek.com/next-js-creator-vercel-hacked/
Hudson Rock / Infostealers.com, “Breaking: Vercel Breach Linked to Infostealer Infection at Context.ai”: https://www.infostealers.com/article/breaking-vercel-breach-linked-to-infostealer-infection-at-context-ai/
Trend Micro, “The Vercel Breach: OAuth Supply Chain Attack Exposes the Hidden Cost of AI Tool Integration”: https://www.trendmicro.com/en_us/research/26/d/vercel-breach-oauth-supply-chain.html
HeroDevs, “Vercel Breach Confirmed: Critical Security Steps for Every Developer”: https://www.herodevs.com/blog-posts/vercel-breach-confirmed-critical-security-steps-for-every-developer
Guillermo Rauch (CEO Vercel) post no X: https://x.com/rauchg/status/2045995362499076169
Dark Web Informer no X: https://x.com/DarkWebInformer/status/2045893769187275223
Amante por tecnologia Especialista em Cibersegurança e Big Data, Formado em Administração de Infraestrutura de Redes, Pós-Graduado em Ciências de Dados e Big Data Analytics e Machine Learning, Com MBA em Segurança da Informação, Escritor do livro ” Cibersegurança: Protegendo a sua Reputação Digital”.
