Violação na Vercel: ataque via OAuth expõe o risco oculto das variáveis de ambiente da plataforma

• A violação da cadeia de suprimentos via OAuth levou ao acesso a sistemas internos da Vercel, causando a exposição de variáveis de ambiente em um conjunto limitado de projetos de clientes
• O ponto de partida foi a infecção por Lumma Stealer de um funcionário da Context.ai, e os tokens OAuth vazados do Google Workspace foram usados para acessar uma conta de funcionário da Vercel e sistemas internos
• Os invasores obtiveram permissão para enumerar variáveis de ambiente de projetos de clientes e, em especial, as variáveis marcadas como non-sensitive ampliaram a possibilidade de exposição de credenciais de serviços downstream
• Pelas informações públicas, em pelo menos um caso houve detecção de chave de API vazada antes da divulgação da Vercel, destacando o intervalo entre detecção e notificação como um fator de risco importante
• Este incidente revelou que as relações de confiança via OAuth e a forma como a plataforma armazena variáveis de ambiente podem, juntas, levar à disseminação de credenciais por toda a cadeia de suprimentos

---

Principais implicações

• Efeito de amplificação do OAuth confirmado
  • O comprometimento de uma única relação de confiança via OAuth se expandiu em cadeia, do fornecedor até sistemas internos da Vercel
  • Até variáveis de ambiente de projetos de clientes sem relação direta com o fornecedor comprometido foram expostas de forma limitada
• Possibilidade de atividade ofensiva acelerada por IA
  • O CEO declarou publicamente que a velocidade incomum do invasor pode estar ligada a reforço por IA
  • No entanto, essa avaliação é uma fala pública, não uma conclusão forense oficial
• Atraso entre detecção e divulgação em evidência
  • Em pelo menos um relato público de cliente, há indícios de detecção de chave vazada 9 dias antes da divulgação da Vercel
  • Em violações de plataforma, o atraso entre detecção e notificação foi apontado como um fator de risco crítico
• Ligação com um padrão mais amplo de 2026
  • Junto com LiteLLM, Axios, Codecov e CircleCI, o caso se encaixa em uma tendência de cadeia de suprimentos voltada a credenciais armazenadas por desenvolvedores

Linha do tempo do incidente

• Por volta de fevereiro de 2026, um funcionário da Context.ai foi infectado pelo Lumma Stealer, resultando no vazamento de credenciais corporativas, tokens de sessão e tokens OAuth
• Por volta de março de 2026, os invasores acessaram o ambiente AWS da Context.ai e roubaram tokens OAuth de usuários consumidores
  • Entre eles estava um token do Google Workspace de um funcionário da Vercel
• Em março de 2026, o token OAuth roubado foi usado para acessar a conta Google Workspace de um funcionário da Vercel
• De março a abril de 2026, após se moverem para sistemas internos da Vercel, os invasores começaram a enumerar variáveis de ambiente de clientes
• Por volta de abril de 2026, surgiu a alegação de que um ator ligado ao ShinyHunters começou a vender dados da Vercel
• Em 10 de abril de 2026, um cliente da Vercel mencionou publicamente ter recebido da OpenAI um alerta sobre chave de API vazada
• Em 19 de abril de 2026, a Vercel publicou o aviso de segurança e a thread no X
• Após 19 de abril de 2026, seguiram notificações a clientes, orientações para rotação de credenciais e mudanças no dashboard
• Mesmo com um tempo de permanência relativamente curto, de cerca de 2 meses, ficou evidente a velocidade com que a cadeia foi da infecção de um fornecedor terceirizado ao vazamento de variáveis de ambiente de clientes
• O período padrão de retenção de logs de auditoria do Google Workspace OAuth é de 6 meses em muitos planos
  • Esse tempo de permanência de cerca de 2 meses provavelmente ainda estaria dentro da janela de retenção
  • Também foi apontado que violações semelhantes mais longas podem ultrapassar o período padrão de retenção

Cadeia de ataque

• Etapa 1: violação de OAuth de terceiro

  • A Context.ai tinha um aplicativo OAuth do Google Workspace aprovado por um funcionário da Vercel
  • O comprometimento desse aplicativo foi rastreado até a infecção por Lumma Stealer de um funcionário da Context.ai por volta de fevereiro de 2026
  • Segundo reportagens da Hudson Rock e da CyberScoop, o funcionário teria sido infectado após baixar um script de exploit para jogo do Roblox
  • Com as credenciais roubadas, os invasores acessaram o ambiente AWS da Context.ai e vazaram tokens OAuth para usuários consumidores do Context AI Office Suite, lançado em junho de 2025
  • A Context.ai informou que detectou e interrompeu em março de 2026 o acesso não autorizado ao ambiente AWS
  • No entanto, afirmou explicitamente que o vazamento dos próprios tokens OAuth só foi identificado durante a investigação da Vercel
  • Aplicativos OAuth aprovados têm as seguintes características
    • não exigem a senha do usuário
    • podem continuar válidos mesmo após troca de senha
    • frequentemente possuem escopos amplos para e-mail, Drive, calendário etc.
    • raramente são alvo de auditoria após a aprovação inicial

• Etapa 2: comprometimento da conta Workspace

  • O acesso ao aplicativo OAuth comprometido levou à conta Google Workspace de um funcionário da Vercel
  • Isso possibilitou acesso a e-mail, documentos internos no Google Drive, visibilidade sobre calendário e recursos conectados, e potencialmente acesso a outros serviços ligados por OAuth

• Etapa 3: acesso a sistemas internos

  • A partir da conta Workspace comprometida, houve movimentação adicional para sistemas internos da Vercel
  • Rauch mencionou que a escalada ocorreu por meio de uma série de ações iniciadas a partir da conta Google Workspace comprometida de um colega na Vercel
  • As técnicas específicas de movimento lateral não foram divulgadas
    • integração SSO
    • credenciais coletadas de e-mails ou do Drive
    • outras ferramentas internas conectadas por OAuth
    • não foi revelado qual desses caminhos foi usado

• Etapa 4: enumeração de variáveis de ambiente

  • Os invasores obtiveram acesso a sistemas internos da Vercel com privilégios suficientes para enumerar variáveis de ambiente de projetos de clientes
  • A Vercel oferece um recurso para marcar variáveis de ambiente de clientes como “non-sensitive”
  • Segundo declarações públicas, nem todas as variáveis de ambiente de clientes eram protegidas da mesma forma, e a enumeração de variáveis sem marcação de sensibilidade permitiu obter acesso adicional

• Etapa 5: possível abuso de serviços downstream

  • Variáveis de ambiente expostas normalmente incluem credenciais de serviços downstream
  • Segundo relatório público de 19 de abril de 2026 de Andrey Zagoruiko, em 10 de abril ele recebeu um alerta da OpenAI sobre chave vazada
  • Segundo o relato, essa chave não existia fora da Vercel
  • Esse contexto sugere a possibilidade de que pelo menos uma credencial exposta tenha sido detectada externamente antes da divulgação da Vercel

A lacuna de 9 dias no momento da divulgação

• Em uma resposta de Guillermo Rauch na thread do X em 19 de abril, o cliente Andrey Zagoruiko revelou publicamente que recebeu em 10 de abril de 2026 um alerta da OpenAI sobre chave vazada
• A detecção de credenciais vazadas pela OpenAI normalmente é acionada quando elas aparecem em locais públicos, como GitHub, sites de paste e similares
• O artigo avalia que o caminho entre uma variável de ambiente da Vercel e um alerta da OpenAI não é simples
• Pelas datas, existe uma janela de 9 dias entre a evidência pública mais antiga de exposição e a divulgação da Vercel

• O que essa lacuna de 9 dias significa — e o que não significa

  • Trata-se de um único relato público e não de um resultado forense confirmado
  • Isso não deve ser interpretado como prova de que a Vercel já tinha conhecimento da violação em 10 de abril
  • Por outro lado, tem valor como indício de que ao menos uma credencial foi detectada externamente antes da notificação aos clientes para troca de segredos

• Implicações para cada parte interessada

  • Reguladores
    • No GDPR, o relógio de notificação de 72 horas começa a contar a partir do momento em que o controlador toma conhecimento da violação
    • Quando a Vercel tomou conhecimento passa a surgir como questão pública relevante
  • Auditores
    • Avaliadores de SOC 2 e ISO 27001 podem examinar o atraso entre detecção e notificação como evidência de monitoramento contínuo
  • Clientes
    • Não se pode assumir que a janela de exposição começou em 19 de abril
    • O artigo indica que pode ter havido exploração ativa antes disso
  • Alertas de credenciais vazadas enviados por fornecedores ganham importância como canal de alerta precoce
  • Incluem-se como exemplos OpenAI, Anthropic, GitHub, AWS e Stripe

Atividades de ataque aceleradas por IA

• Guillermo Rauch afirmou no X, em 19 de abril de 2026, que suspeita fortemente que o grupo atacante era altamente sofisticado e foi significativamente acelerado por IA
• O artigo trata essa fala como uma avaliação pública registrada do CEO da plataforma afetada e menciona a necessidade de uma análise cuidadosa

• Sinais que podem ser esperados em evidências forenses

  • Velocidade de enumeração acima do ritmo manual
    • parcialmente explicável apenas com scripting
    • reconhecimento baseado em LLM pode paralelizar exploração de esquema, sondagem de endpoints e reconhecimento de formatos de credenciais
  • Construção de consultas com consciência de contexto
    • consultas que parecem conhecer terminologia específica da Vercel, slug de projeto, nomes de alvos de deploy e convenções de nomenclatura de env vars, mesmo sem reconhecimento prévio evidente
  • Adaptabilidade na resposta a erros
    • mudança de estratégia após erros de API e rate limit com mais flexibilidade do que scripts estáticos
  • Produtos de engenharia social com aparência localizada
    • mensagens de phishing, mensagens de commit e tickets de suporte com qualidade mais próxima do contexto local do que de tradução ou template

• Importância para além do caso Vercel

  • Independentemente de essa avaliação se sustentar na perícia formal, a categoria de operações de ataque reforçadas por IA já não é mais mera especulação
  • Em anúncio de abril de 2026, a Microsoft documentou casos de phishing por device code com IA, geração dinâmica de código, iscas hiperpersonalizadas e orquestração automatizada de backend
  • Aponta-se que baselines de telemetria calibradas para velocidade humana podem gerar false negatives contra operadores acelerados por IA

• Implicações para a engenharia de detecção

  • Se houver compressão da enumeração e do movimento lateral, regras existentes baseadas em permanência e limiares de velocidade podem alertar menos do que deveriam
  • Levanta-se a necessidade de reavaliar os seguintes itens
    • taxa de enumeração de recursos únicos por sessão
    • curva de recuperação de sucesso em relação a erros
    • diversidade de padrões de consulta em curto intervalo de tempo

Vulnerabilidade central no desenho das variáveis de ambiente

• O aspecto mais grave no artigo não é o vetor de acesso inicial em si, mas o modelo de sensibilidade das variáveis de ambiente da Vercel

• Como as variáveis de ambiente da Vercel funcionavam na época

  • projetos injetavam variáveis de ambiente em funções serverless e no processo de build
  • havia uma flag sensitive por variável
  • o padrão era non-sensitive
  • sensitive precisava ser ativado explicitamente
  • variáveis non-sensitive eram exibidas no dashboard
  • variáveis sensitive eram mascaradas após a criação
  • acesso via API interna era possível para non-sensitive, enquanto sensitive tinha restrições
  • segundo declarações públicas, armazenamento criptografado não se aplicava a non-sensitive, e se aplicava a sensitive com restrições adicionais
  • nesta violação, o que os atacantes puderam acessar estava marcado como non-sensitive

• Escolha de design decisiva

  • a flag sensitive vinha desativada por padrão
  • todo DATABASE_URL, API_KEY, STRIPE_SECRET_KEY e AWS_SECRET_ACCESS_KEY que o desenvolvedor não ativasse explicitamente era armazenado de forma não criptografada no modelo interno de acesso da Vercel
  • avalia-se que controles de segurança que exigem opt-in explícito para cada segredo, sem proteção padrão nem guardrails, têm baixa adoção real

• Resposta da Vercel

  • foi confirmada a implementação de melhorias na página de visão geral das variáveis de ambiente e na UI de criação e gerenciamento de variáveis sensíveis
  • houve melhora no aspecto de visibilidade, mas, no momento da redação, o padrão não havia mudado
  • ainda era necessário opt-in por variável
  • a possibilidade de inverter o padrão segue como questão pública em aberto

• Comparação com o setor

  • o setor está migrando para cofres de segredos dedicados como Vault, AWS Secrets Manager, Doppler e Infisical
  • avalia-se que este caso reforça a escolha por estruturas dedicadas de gestão de segredos, em comparação com a abordagem baseada em variáveis de ambiente da Vercel
  • segundo a tabela comparativa
    • a Vercel tem padrão non-sensitive e não faz detecção automática
    • o AWS SSM Parameter Store oferece suporte a SecureString
    • o HashiCorp Vault fornece criptografia para todos os segredos e ACL
    • o GitHub Actions mascara todos os segredos nos logs
    • o Netlify usa abordagem de variável de ambiente com toggle de secret

Fan-out de credenciais e risco a jusante

• Credential fan-out é o fenômeno em que uma única violação de plataforma leva à exposição em cascata de todos os serviços a jusante autenticados pelas credenciais armazenadas nessa plataforma
• Itens frequentemente presentes nas variáveis de ambiente de projetos Vercel e seus impactos a jusante
  • Banco de dados
    • DATABASE_URL, POSTGRES_PASSWORD
    • possibilidade de acesso completo aos dados
  • Nuvem
    • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
    • possibilidade de comprometimento da conta em nuvem
  • Pagamentos
    • STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET
    • risco para dados financeiros e fraude de reembolso
  • Autenticação
    • AUTH0_SECRET, NEXTAUTH_SECRET
    • possibilidade de falsificação de sessão e tomada de conta
  • Envio de e-mail
    • SENDGRID_API_KEY, POSTMARK_TOKEN
    • possibilidade de phishing com base em domínio confiável
  • Monitoramento
    • DATADOG_API_KEY, SENTRY_DSN
    • possibilidade de manipulação de telemetria
  • Código-fonte e pacotes
    • GITHUB_TOKEN, NPM_TOKEN
    • possibilidade de injeção na cadeia de suprimentos
  • AI/ML
    • OPENAI_API_KEY, ANTHROPIC_API_KEY
    • possibilidade de abuso de API e geração de custos
• Um único projeto na Vercel costuma conter de 10 a 30 variáveis de ambiente
• Em escala organizacional, um portfólio de 50 projetos pode ter de 500 a 1.500 credenciais na plataforma
• Embora neste caso se diga que apenas alguns projetos de clientes foram acessados, cada credencial exposta pode se tornar um ponto de pivô para outro sistema
• O artigo define esse ponto não como mero incidente de confidencialidade da plataforma, mas como um efeito multiplicador que se espalha por toda a cadeia de suprimentos de software

Relações de confiança OAuth e evasão de defesas de perímetro

• Uma invasão baseada em OAuth contorna muitos controles que detectam e bloqueiam ataques tradicionais baseados em credenciais
• O artigo menciona cerca de 22 meses, mas a correção no topo informa que o período de permanência foi revisado para cerca de 2 meses
• Descreve-se que controles defensivos dos quais as equipes de segurança dependem na coluna da esquerda tornam-se irrelevantes ou já satisfeitos no caminho de comprometimento via app OAuth
• Por causa dessa assimetria, a governança de OAuth emerge como uma área de segurança separada de IAM

• Governança de OAuth é uma função de risco de fornecedor

  • muitas organizações tratam a aprovação de OAuth como questão de autosserviço para desenvolvedores
  • isso costuma se limitar à aprovação de ferramentas necessárias por funcionário e a uma revisão central mínima
  • este caso é apresentado como evidência de que apps OAuth aprovados devem ser tratados como fornecedores terceirizados com acesso persistente
  • são necessárias revisão de fornecedor, reaprovação periódica e monitoramento de uso anômalo

Alegações do agente de ameaça e atribuição

• Parte-se do pressuposto de que alegações feitas por agentes de ameaça em fóruns clandestinos são inerentemente difíceis de confiar
• As informações aqui estão organizadas não como fatos confirmados, mas para fins de percepção e rastreamento

• Alegação de vínculo com o ShinyHunters

  • O autor da postagem no BreachForums alegou vínculo com o ShinyHunters e afirmou estar de posse de dados da Vercel
  • Itens de dados alegados
    • cerca de 580 registros de funcionários
    • repositórios de código-fonte
    • chaves de API e tokens internos
    • tokens do GitHub e do NPM
    • comunicações internas
    • acesso ao workspace do Linear
  • Todas as quantidades e o escopo acima permanecem não verificados

• Fatores que dificultam a atribuição

  • Membros conhecidos do ShinyHunters negaram envolvimento ao BleepingComputer
  • Há alegações de que foi feita uma exigência de resgate de US$ 2 milhões via Telegram
  • A marca ShinyHunters tem sido usada por vários agentes, ou por agentes não relacionados, desde a campanha original
  • O aviso de segurança da Vercel não menciona as alegações do fórum
  • A thread de Rauch trata da cadeia de ataque, mas não aborda diretamente a postagem do fórum

• Posição da Vercel sobre a rota de release da cadeia de suprimentos

  • Rauch afirmou ter analisado a cadeia de suprimentos do Next.js, Turbopack e de vários projetos open source, dizendo à comunidade que eles estão seguros
  • No momento da redação, a verificação independente ainda está em andamento
  • Recomenda-se que organizações que usam Next.js, Turbopack e outros projetos open source da Vercel continuem verificando sinais de integridade de pacotes, como checksums, assinaturas e provenance attestation
  • Como não há verificação independente dos dados alegados no fórum, é necessário tratá-los como informação não confirmada
  • A avaliação é que a cadeia de ataque baseada em OAuth descrita pela Vercel, por si só, já sustenta tecnicamente o incidente, sem que seja condição necessária o amplo escopo de acesso alegado pelo autor da postagem no fórum

Mapeamento MITRE ATT&CK

• A cadeia de ataque confirmada se mapeia de forma natural a técnicas do MITRE ATT&CK já conhecidas
• Itens do mapeamento
  • Initial Access / Trusted Relationship / T1199
    • uso do app OAuth da Context.ai como terceiro confiável
  • Persistence / Application Access Token / T1550.001
    • persistência do token OAuth mesmo após a troca de senha
  • Credential Access / Valid Accounts / T1078
    • credenciais comprometidas do Workspace de funcionários
  • Discovery / Account Discovery / T1087
    • enumeração de sistemas internos e projetos
  • Credential Access / Unsecured Credentials: Credentials in Files / T1552.001
    • possibilidade de acesso a variáveis de ambiente non-sensitive
  • Lateral Movement / Valid Accounts: Cloud Accounts / T1078.004
    • possibilidade de uso de credenciais de nuvem expostas
  • Collection / Data from Information Repositories / T1213
    • enumeração de variáveis de ambiente em vários projetos
• O ponto de detecção mais valioso nesse mapeamento é a transição do acesso ao aplicativo OAuth para o acesso a sistemas internos
• As organizações precisam monitorar comportamentos anômalos de apps OAuth que acessam recursos fora do escopo esperado ou a partir de faixas de IP não previstas

Cerco à cadeia de suprimentos: LiteLLM, Axios, Vercel

• O incidente da Vercel não é um caso isolado, mas se insere em uma sequência de ataques à cadeia de suprimentos concentrada entre março e abril de 2026
• O artigo aponta que isso pode ter sido uma campanha coordenada ou, em uma interpretação mais provável, o resultado de vários atacantes terem descoberto ao mesmo tempo a mesma fraqueza estrutural: fronteiras de confiança entre repositórios de pacotes, CI/CD, provedores OAuth e plataformas de deploy

• 24 de março de 2026: comprometimento da cadeia de suprimentos do LiteLLM no PyPI

  • publicação dos pacotes maliciosos litellm 1.82.7 e 1.82.8 no PyPI
  • uso de credenciais de deploy de CI/CD roubadas do scanner de vulnerabilidades Trivy, da Aqua Security
  • o LiteLLM é um proxy de LLM com cerca de 3,4 milhões de downloads por dia
  • o backdoor em três estágios mirava mais de 50 tipos de credenciais em diversos provedores de nuvem
  • incluía persistência via Kubernetes DaemonSet
  • o tempo de permanência antes da detecção e remoção foi de cerca de 40 minutos a 3 horas
  • o CVE relacionado é CVE-2026-33634

• 31 de março de 2026: comprometimento da cadeia de suprimentos do Axios no npm

  • o pacote npm axios tem entre 70 milhões e 100 milhões de downloads por semana
  • versões maliciosas 1.14.1 e 0.30.4 foram distribuídas após comprometimento de conta de mantenedor
  • injeção da dependência plain-crypto-js@4.2.1, contendo um RAT multiplataforma
  • foi detectado que 135 endpoints infectados se comunicaram com o C2 do atacante
  • o tempo de permanência foi de 2 a 3 horas
  • a Microsoft atribuiu o ataque ao agente de ameaça patrocinado pela Coreia do Norte Sapphire Sleet

• Padrão convergente

  • 3 ataques em 3 semanas
  • vetores diferentes
  • o alvo comum foram credenciais e segredos armazenados por desenvolvedores na toolchain
  • O resumo em tabela apresenta o seguinte
    • LiteLLM: roubo de credenciais de CI/CD → PyPI, credenciais de desenvolvedor e chaves de API, 40 minutos a 3 horas
    • Axios: comprometimento de conta de mantenedor → npm, RAT em workstation de desenvolvedor, 2 a 3 horas
    • Vercel: comprometimento de app OAuth → plataforma, variáveis de ambiente de clientes, a tabela registra cerca de 22 meses, mas a correção no topo e o corpo do texto ajustam para cerca de 2 meses

Padrões em comum com comprometimentos anteriores de plataforma

• O comprometimento da Vercel se conecta a um padrão recorrente em que violações em nível de plataforma expõem segredos de clientes

• Comprometimento do Codecov Bash Uploader, janeiro a abril de 2021

  • o atacante modificou o script Bash Uploader para vazar variáveis de ambiente de ambientes de CI de clientes
  • permaneceu sem detecção por cerca de 2 meses
  • mais de 29 mil clientes potencialmente afetados, incluindo Twitch, HashiCorp e Confluent
  • o ponto em comum com a Vercel é a exposição de variáveis de ambiente de clientes por meio do comprometimento da plataforma

• Incidente de segurança da CircleCI, janeiro de 2023

  • malware em dispositivo pessoal roubou tokens de sessão SSO de funcionário
  • após acesso a sistemas internos, segredos de clientes e chaves de criptografia foram vazados
  • a CircleCI recomendou a todos os clientes a rotação de todos os segredos armazenados na plataforma
  • a estrutura é quase idêntica à da Vercel
    • comprometimento de conta de funcionário
    • acesso a sistemas internos
    • vazamento de segredos de clientes

• Ataque a credenciais de clientes da Snowflake, maio a junho de 2024

  • o UNC5537 usou credenciais obtidas por infostealer e contas sem MFA habilitado
  • mais de 165 organizações afetadas
  • incluindo Ticketmaster, Santander Bank e AT&T

• Comprometimento do sistema de suporte da Okta, outubro de 2023

  • acesso ao sistema de gerenciamento de casos de suporte a clientes com credenciais roubadas
  • visualização de tokens de sessão em arquivos HAR
  • clientes impactados incluíram Cloudflare, 1Password e BeyondTrust

• Resumo do padrão

  • acesso inicial por relação de confiança ou credenciais
  • movimento lateral para sistemas internos
  • vazamento de segredos de clientes
  • o escopo dos alvos varia de alguns alvos específicos até toda a plataforma
  • A tabela resume, por incidente, o vetor inicial, os ativos expostos e o atraso na detecção
    • Codecov cerca de 2 meses
    • Okta várias semanas
    • CircleCI várias semanas
    • Snowflake vários meses
    • Vercel cerca de 2 meses

O que ainda não foi divulgado

• Apesar da grande quantidade de cobertura pública e falas de executivos, lacunas centrais ainda permanecem
• Perguntas sem resposta no registro público
  • quando a Vercel detectou pela primeira vez a atividade anômala
  • o motivo da diferença de 9 dias entre a evidência mais antiga de abuso de credenciais divulgada publicamente e a divulgação pública
  • número de clientes impactados
    • Rauch usou a expressão “quite limited”, mas não divulgou números concretos
  • se as alegações do fórum do ShinyHunters vieram do mesmo atacante
  • o status atual da Context.ai e se houve notificação aos clientes downstream
  • o escopo total do acesso interno à Vercel
    • o número de equipes afetadas, projetos afetados e variáveis de ambiente não foi divulgado
    • também não está confirmado se houve acesso a outros sistemas internos além das variáveis de ambiente de clientes
• O artigo enfatiza que, para uma análise rigorosa, é necessário não apenas relatar os fatos conhecidos, mas também reconhecer explicitamente o que não foi divulgado

Guia de detecção e hunting

• Ações imediatas para clientes da Vercel

  • É necessário auditar todas as variáveis de ambiente dos projetos
  • O artigo inclui os seguintes exemplos de CLI
    • vercel env ls --environment production
    • vercel env ls --environment preview
    • vercel env ls --environment development
  • Como a CLI atualmente não expõe diretamente o sinalizador sensitive, é necessário verificar pelo dashboard ou pela API

• Busca por uso não autorizado de credenciais expostas

  • Pesquisar logs de auditoria dos provedores de nuvem
    • AWS CloudTrail
      • Filtro de eventSource incluindo sts.amazonaws.com, iam.amazonaws.com, s3.amazonaws.com
      • Buscar userIdentity.accessKeyId que corresponda à access key armazenada na Vercel e já rotacionada
      • Detectar sourceIPAddress fora dos CIDRs conhecidos da organização, python-requests, curl, Go-http-client e strings de automação desconhecidas no userAgent
      • O período deve ir de fevereiro de 2026 até o presente
    • GCP Audit Logs
      • Buscar protoPayload.authenticationInfo.principalEmail da conta de serviço que usa a chave armazenada na Vercel
      • callerIp fora do intervalo conhecido
      • Verificar métodos como storage.objects.get, compute.instances.list, iam.serviceAccountKeys.create
    • Azure Activity Logs
      • Filtrar com base no ID do aplicativo ou service principal que estava nas variáveis de ambiente da Vercel
      • callerIpAddress fora do intervalo esperado
      • Priorizar a verificação de Microsoft.Storage/storageAccounts/listKeys, Microsoft.Compute/virtualMachines/write, Microsoft.Authorization/roleAssignments/write
  • Pesquisar logs de acesso a bancos de dados
    • Todos os bancos cujas strings de conexão estavam em variáveis de ambiente da Vercel
    • Analisar toda a janela entre fevereiro e abril de 2026
    • Verificar IPs fora dos intervalos de egress conhecidos, como Vercel edge IP, VPN e escritório
    • Detectar conexões usando credenciais expostas fora das janelas normais de deploy
    • Para PostgreSQL, pg_stat_activity, log_connections
    • Para MySQL, general log ou audit plugin
    • Para MongoDB Atlas, eventos DATA_EXPLORER e CONNECT no Project Activity Feed
  • Pesquisar logs de processamento de pagamentos
    • Stripe Dashboard → Developers → Logs
    • source_ip fora dos servidores esperados
    • /v1/charges, /v1/transfers, /v1/payouts, /v1/customers
    • Verificar logs equivalentes de Braintree e Adyen
    • Priorizar chaves de API armazenadas em env vars non-sensitive que ainda não foram rotacionadas
    • Verificar também envios inesperados nos logs de serviços de envio de e-mail
  • É necessário verificar alertas involuntários de credenciais vazadas vindos de OpenAI, Anthropic, GitHub, AWS, Stripe etc.

• É necessário rotacionar e redeployar ao mesmo tempo

  • Segundo a documentação da Vercel, apenas rotacionar variáveis de ambiente não invalida os valores antigos de credenciais em deploys passados
  • Deploys anteriores continuam usando as credenciais antigas até serem redeployados
  • Portanto, toda rotação exige redeploy de todos os ambientes que usam essas variáveis ou a desativação explícita dos deploys antigos
  • A prioridade deve seguir esta ordem
    • Credenciais de provedores de nuvem
    • Strings de conexão de banco de dados
    • Chaves de processamento de pagamentos
    • Segredos de autenticação
    • Chaves de API de terceiros
    • Tokens de monitoramento e logging

• Resposta preventiva para equipes de segurança

  • No Google Workspace Admin Console → Security → API Controls → Third-party app access, revisar todos os apps OAuth aprovados
  • Destacar apps com escopos amplos, como Drive, Gmail e Calendar
  • Investigar apps de fornecedores sem relação comercial ativa
  • Monitorar uso de tokens OAuth a partir de intervalos de IP inesperados
  • É necessário buscar o OAuth Client ID malicioso conhecido
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Lógica de detecção no SIEM

• Sinais anômalos em aplicações OAuth, fases 1 e 2

  • Alertar imediatamente sobre eventos de refresh de token ou autorização associados ao OAuth Client ID malicioso conhecido
  • Cruzar eventos de concessão de escopos amplos, como acesso total ao e-mail, leitura/gravação no Drive e acesso ao Calendar, com a lista atual de fornecedores
  • Apps que já não têm uso comercial devem ser revogados
  • Se o uso de token de apps OAuth aprovados ocorrer a partir de IPs fora dos intervalos CIDR esperados da empresa e do fornecedor, isso deve ser investigado

• Acesso a sistemas internos e movimento lateral, fase 3

  • Eventos anômalos de autenticação SSO/SAML
    • Quando uma conta comprometida do Workspace faz login em aplicações internas a partir de um IP, região ou impressão digital de dispositivo nunca vistos antes
  • Coleta de credenciais via e-mail e Drive
    • Busca em massa por palavras-chave como API key, secret, token, password, .env
    • Acesso a repositórios compartilhados de credenciais, runbooks de engenharia e documentação de infraestrutura
    • Criação de regras de encaminhamento de e-mail
  • Acesso a ferramentas internas por conexão OAuth
    • Criação de sessões ou atividade de API em Slack, Jira, GitHub e dashboards internos em horários ou infraestruturas fora do padrão
  • Tentativas de escalonamento de privilégios
    • Participação em novos grupos ou funções
    • Acesso a consoles administrativos antes não utilizados
    • Monitorar chamadas à Directory API do Google Workspace, mudanças de delegação e tentativas de enumerar tokens OAuth de outros usuários

• Enumeração de variáveis de ambiente, fase 4

  • Detectar padrões anormais de volume e frequência em chamadas com característica de leitura, listagem ou descriptografia de envs nos logs de auditoria da equipe Vercel
  • Primeiro, é necessário estabelecer uma baseline dos horários normais de build de CI/CD
  • Depois, alertar sobre acessos cujo volume, momento ou agente de origem saiam da baseline
  • Dar atenção a acessos feitos por contas de usuário, e não por contas de serviço, e por contas que normalmente não interagiam com o projeto

• Abuso de credenciais downstream, fase 5

  • Verificar logs de todos os serviços de destino de credenciais que ficaram armazenadas em variáveis de ambiente non-sensitive da Vercel durante a janela de fevereiro a abril de 2026
  • Na AWS, pesquisar no CloudTrail usando o access key ID específico
  • Em GCP e Azure, pesquisar logs de auditoria com base na conta de serviço ou no ID do aplicativo
  • Em APIs SaaS como Stripe, OpenAI, Anthropic, SendGrid e Twilio, verificar no dashboard ou nos logs da API se houve uso a partir de IPs não reconhecidos ou em horários inativos
  • Qualquer uso que não possa ser atribuído à sua própria infraestrutura deve ser tratado imediatamente como credencial comprometida, exigindo rotação e investigação da atividade

• Alertas de vazamento de credenciais de terceiros

  • É necessário monitorar alertas automáticos de varredura de segredos, como GitHub secret scanning partner program, AWS compromised key detection, OpenAI, Anthropic, Stripe e Google Cloud
  • Alertas sobre chaves que existiam apenas na plataforma de deploy não devem ser tratados como meros avisos de higiene, mas como indicadores de comprometimento da plataforma

Procedimentos manuais de threat hunting

• Busca manual no Google Workspace Admin Console

  • Admin Console → Reports → Audit and Investigation → OAuth Log Events
  • Application Name = Context.ai ou Client ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
  • Período: de fevereiro de 2026 até o presente
  • Se houver resultados, é necessário revogar imediatamente as permissões e investigar o incidente

• Revisão de apps OAuth de terceiros com escopos amplos

  • Admin Console → Security → API Controls → Third-party app access → Manage Google Services
  • Ordenar apps com App access = Unrestricted
  • Itens de verificação para cada app
    • Existência de relação ativa com o fornecedor
    • Justificativa de negócio para os escopos
    • Data do uso mais recente
  • Apps sem uso há mais de 90 dias devem ser revogados

Recomendações de defesa

• Ações imediatas, 0~48 horas

  • Rotacionar todas as variáveis de ambiente da Vercel não marcadas como sensitive
  • Reimplantar todos os ambientes após a rotação
  • Ativar a flag sensitive em todas as variáveis de ambiente que contenham credenciais, tokens, chaves e segredos
  • Auditar aprovações de apps OAuth no console administrativo do Google Workspace ou do Microsoft Entra
  • Revogar o acesso de apps que não estejam mais em uso ativo
  • Revisar os logs de acesso de todos os serviços que usaram credenciais armazenadas em variáveis de ambiente da Vercel, de fevereiro de 2026 até o presente

• Reforço de curto prazo, 1~4 semanas

  • Migrar para o uso de gerenciadores dedicados de segredos, como HashiCorp Vault, AWS Secrets Manager, Doppler e Infisical
  • Usar injeção em runtime em vez de armazenar segredos nas variáveis de ambiente da plataforma
  • Onde houver suporte, eliminar credenciais de longo prazo com autenticação baseada em OIDC
  • Implementar monitoramento de apps OAuth
    • Nudge Security, Grip Security, Valence Security ou recursos nativos de administração do Google Workspace
  • Implementar automação para rotação de credenciais
    • Sugere-se um ciclo de 30~90 dias
  • Incluir aprovações de OAuth no inventário de risco de terceiros, assim como fornecedores contratados

• Mudanças estruturais, 1~6 meses

  • Adotar uma postura de Zero Trust para variáveis de ambiente
    • Assumir que todos os segredos armazenados na plataforma de deploy podem ser expostos em caso de comprometimento da plataforma
  • Aplicar escopos de menor privilégio
    • Menor privilégio para contas de banco de dados
    • Restringir o escopo operacional de chaves de API
    • Para credenciais de nuvem, usar credenciais temporárias baseadas em função em vez de access keys de longo prazo
  • Realizar revisão de segurança de terceiros e reavaliações periódicas para todos os apps OAuth e integrações que acessem o sistema corporativo de identidade
  • Incluir plataformas PaaS no inventário de SBOM/ASPM
    • Devem ser tratadas não como serviços externos, mas como dependências de supply chain de primeira classe

• Monitoramento recomendado

  • Auditar o Client ID OAuth acima no Google Workspace Admin Console
  • Monitorar chamadas inesperadas de API env.read e env.list nos logs de auditoria da Vercel
  • Verificar em CloudTrail, GCP Audit Logs e Azure Activity Logs se houve uso por IPs ou user agents inesperados de credenciais armazenadas em variáveis de ambiente da Vercel entre fevereiro e abril de 2026
  • Se houver LiteLLM ou Axios na árvore de dependências, monitorar também os IoCs citados em cada recomendação
  • Acompanhar alertas de provedores de API sobre vazamento involuntário de credenciais durante o período de exposição

Impacto regulatório e de compliance

• Organizações que possam ter sofrido exposição de credenciais por causa dessa violação precisam avaliar as seguintes obrigações

• GDPR

  • Se as credenciais expostas permitiram acesso a sistemas com dados pessoais da UE, o prazo de notificação de 72 horas pode começar no momento da confirmação da exposição
  • A notificação da OpenAI em 10 de abril levanta a questão de que, para algumas organizações, o momento de ciência pode ter sido anterior à divulgação pública de 19 de abril

• CCPA/CPRA

  • A exposição de credenciais que dão acesso a dados de consumidores pode acionar obrigações de notificação

• PCI DSS

  • A exposição de credenciais de processamento de pagamento, como Stripe, Braintree e Adyen, pode exigir procedimentos de resposta a incidentes e investigação forense

• SOC 2

  • É necessário refletir o registro do incidente, as ações de rotação de credenciais e os controles atualizados nas evidências de monitoramento contínuo

• SEC Cybersecurity Rules 8-K

  • Empresas listadas que considerarem o caso material têm obrigação de divulgação em até 4 dias úteis
  • O artigo observa que, mesmo que ainda não se saiba se houve uso real de acesso não autorizado, muitos frameworks regulatórios podem operar com base na própria exposição, e não na confirmação de exploração

Indicadores de comprometimento

• IoC confirmado

  • OAuth Client ID
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
    • Valor associado ao aplicativo OAuth comprometido da Context.ai