Para: desenvolvedores e operadores que fazem deploy na Vercel, equipes que mantêm segredos de produção (chaves de API, credenciais de banco de dados, chaves de assinatura) em variáveis de ambiente, administradores do Google Workspace e qualquer pessoa em um PaaS (uma plataforma que executa suas aplicações para você) que funcione da mesma forma.
Este artigo é baseado no boletim oficial de segurança e na documentação da Vercel e não aborda técnicas de ataque nem valores de indicadores de comprometimento (IoC).
O que os usuários da Vercel devem fazer hoje
Verifique se há uma mensagem da Vercel, e continue mesmo que não haja
A Vercel diz que entrou em contato diretamente com os clientes afetados e recomendou a rotação imediata de credenciais. Sua atualização de 22 de abril acrescenta que uma revisão ampliada encontrou um pequeno número de contas comprometidas adicionais, que também foram notificadas. Primeiro, confirme quais endereços recebem as mensagens da Vercel (proprietários de equipe, contatos de faturamento).
Mas a Vercel apresenta os passos abaixo como boas práticas que você deve seguir independentemente disso. Não ter recebido contato da Vercel não é motivo para não fazer nada.
Liste as variáveis de ambiente não marcadas como sensíveis e rotacione os segredos primeiro
A Vercel pede que você trate as variáveis de ambiente que não foram marcadas como sensíveis — chaves de API, tokens, credenciais de banco de dados, chaves de assinatura e similares — como potencialmente expostas e que as rotacione como prioridade.
Na tabela de variáveis de ambiente do painel, cada variável tem o rótulo Config (o valor pode ser exibido após salvar) ou Secret (o valor não pode ser exibido após salvar). Segredos que estão sob o rótulo Config são a lista de trabalho de hoje. Verifique também as variáveis compartilhadas no nível da equipe, além das variáveis dos projetos.
Rotacione nesta ordem: adicione a nova chave e faça um novo deploy, depois invalide a antiga
A documentação da Vercel indica esta ordem para rotacionar sem interrupção:
- No serviço de terceiros (provedor de banco de dados ou de API), emita uma nova credencial e mantenha a antiga por enquanto
- Atualize a variável de ambiente na Vercel
- Faça um novo deploy (para uma variável no nível da equipe, todos os projetos que a utilizam)
- Após verificar que tudo funciona, invalide a credencial antiga
Editar apenas a variável deixa os deploys em execução com o valor antigo, e somente o passo 4 torna inútil o valor vazado.
Armazene o novo valor como Secret
Salve os novos valores que você criou como Secrets (somente escrita). No boletim, a Vercel diz que o recurso sensível protege os valores secretos contra leitura no futuro.
Em 30 de setembro de 2026, a documentação diz que o valor de um Secret fica oculto após salvar e é alterado fornecendo um novo valor, e que os Secrets, antes limitados a Production e Preview, agora também são permitidos em Development. Veja a comparação mais adiante neste artigo para saber o que vai em cada categoria.
Rotacione antes de excluir qualquer projeto
A Vercel afirma claramente que excluir seus projetos ou sua conta não é suficiente para eliminar o risco, pois um segredo vazado continua válido no banco de dados ou na API que ele desbloqueia. Se você está limpando projetos antigos ou deixando a Vercel, invalide primeiro as chaves no provedor e só depois exclua.
Revise o log de atividades e os deploys recentes
A Vercel recomenda revisar o log de atividades da sua conta e dos seus ambientes (no painel ou via CLI) em busca de atividade suspeita, e investigar os deploys recentes em busca de algo inesperado ou com aparência suspeita. Ela diz para excluir qualquer deploy em questão. Use o mesmo log para procurar sinais de que alguém visualizou valores de variáveis de ambiente.
Defina a Deployment Protection como Standard ou superior e rotacione seus tokens
A Vercel recomenda definir a Deployment Protection como Standard no mínimo e, se você usa tokens de Deployment Protection, rotacioná-los. A documentação da Vercel descreve o Standard como a opção recomendada para a maioria dos projetos: ele protege URLs de preview e de cada deploy, enquanto as URLs de produção atuais continuam públicas.
Ative a autenticação multifator na sua conta da Vercel
A Vercel recomenda a autenticação multifator com um aplicativo autenticador ou uma passkey. Por que essas opções são melhores que SMS está explicado em Escolhendo a autenticação multifator.
Administradores do Google Workspace: procurem o aplicativo OAuth listado no boletim
A Vercel publicou o identificador do aplicativo OAuth do Google Workspace da ferramenta de IA e recomenda que administradores do Google Workspace e proprietários de contas Google verifiquem imediatamente o uso desse aplicativo.
Segundo a Vercel, esse aplicativo OAuth foi alvo de um comprometimento mais amplo, que potencialmente afetou centenas de usuários em muitas organizações — por isso, organizações que não usam a Vercel também podem estar no escopo. Obtenha o identificador no boletim da Vercel, linkado nas fontes abaixo.
Limite as ferramentas de IA e os aplicativos OAuth que os funcionários conectam
Segundo a Vercel, o atacante usou o acesso a uma ferramenta de IA de terceiros para assumir a conta Google Workspace do funcionário e, a partir dali, avançar para a conta dele na Vercel.
Funcionários conectarem uma ferramenta de IA útil a uma conta corporativa com "Fazer login com o Google" ou "Permitir acesso ao Drive" acontece todos os dias em todas as organizações. A seguir, estão configurações que um administrador do Google Workspace pode alterar hoje para reduzir esse risco.
Liste os aplicativos de terceiros conectados às contas corporativas
A página de ajuda para administradores do Google "Controlar quais aplicativos acessam os dados do Google Workspace" diz que o Console do administrador mostra quais aplicativos acessaram dados da organização, quais usuários os autorizaram e os escopos OAuth solicitados por cada aplicativo.
Extraia a lista e sinalize os aplicativos que ninguém consegue explicar e os aplicativos com escopos que podem ler todo o Drive ou o Gmail.
Bloqueie os aplicativos não utilizados e restrinja os que você mantém
A mesma página diz que cada aplicativo pode ser definido como Confiável, Limitado, Dados específicos do Google ou Bloqueado. Restrinja os aplicativos que você decidir manter a apenas os dados de que precisam, e bloqueie os demais.
Impeça que funcionários conectem livremente aplicativos não configurados
Você pode definir uma política da organização sobre se os usuários podem autorizar aplicativos de terceiros que o administrador não configurou. Permitir apenas aplicativos que solicitam informações básicas de login coloca uma revisão do administrador antes de cada nova ferramenta de IA.
Para Gmail e Drive, você também pode restringir individualmente escopos de alto risco, como enviar e-mails ou excluir arquivos.
Mantenha as contas administrativas de produção separadas das contas que conectam ferramentas de IA
Esta é uma sugestão deste site. Neste incidente, a conta Google à qual uma ferramenta de IA estava conectada tornou-se o caminho para uma conta na Vercel. Pessoas com direitos de administrador em produção ou hospedagem devem considerar não conectar ferramentas de IA de teste à conta que usam para fazer login ali. Se uma ferramenta precisar ser conectada, use uma conta separada com acesso restrito aos dados de negócio.
O que aconteceu (segundo o boletim da Vercel)
Tudo a seguir está como declarado no boletim de segurança da Vercel, "Vercel April 2026 security incident". A Vercel atualizou o boletim várias vezes e, após 24 de abril, passou a atualizá-lo apenas quando houver atualizações críticas.
19 de abril de 2026
A Vercel divulga acesso não autorizado a determinados sistemas internos da Vercel, diz que acionou especialistas em resposta a incidentes e notificou as autoridades, e publica um identificador de aplicativo OAuth para que outras organizações possam verificar seus ambientes.19 de abril (atualização posterior)
A Vercel publica a origem do ataque (uma ferramenta de IA de terceiros comprometida) e acrescenta recomendações.20 de abril
A Vercel esclarece a definição de credenciais comprometidas e acrescenta recomendações. No mesmo dia, afirma que seus pacotes npm foram validados como não comprometidos, acrescenta orientações sobre autenticação multifator e lança melhorias de produto.22 de abril
A Vercel publica as conclusões de uma revisão ampliada: um pequeno número de contas adicionais comprometidas neste incidente, que foram notificadas, e, separadamente, um pequeno número de contas de clientes com sinais de comprometimento que parecem não relacionados a este incidente, que receberam ações corretivas específicas.23 de abril
A Vercel esclarece ainda mais suas conclusões.24 de abril
Sem atualizações. A partir de então, a Vercel diz que alertará os clientes afetados e atualizará o boletim se houver atualizações críticas.
- Origem
- O comprometimento de uma ferramenta de IA de terceiros usada por um funcionário da Vercel. O aplicativo OAuth do Google Workspace da ferramenta foi alvo de um comprometimento mais amplo em muitas organizações
- Caminho
- Tomada da conta Google Workspace do funcionário → conta Vercel do funcionário → um ambiente da Vercel → avanço pelos sistemas para enumerar e descriptografar variáveis de ambiente
- O que foi acessado
- Para um subconjunto limitado de clientes, variáveis de ambiente não marcadas como sensíveis (aquelas descriptografadas em texto simples)
- Outras conclusões
- Um pequeno número de contas adicionais comprometidas neste incidente, agora notificadas. Separadamente, um pequeno número de contas com sinais de comprometimento que parecem separados deste incidente e não parecem ter origem nos sistemas da Vercel
- Não afetados
- Pacotes npm publicados pela Vercel (confirmado com GitHub, Microsoft, npm e uma empresa de segurança)
- Avaliação da Vercel
- A Vercel avalia o atacante como altamente sofisticado, com base na velocidade operacional e no profundo conhecimento da superfície da API de produtos da Vercel. Ela trabalha com empresas de resposta a incidentes, pares do setor e autoridades policiais
- Mudanças de produto
- Melhor gestão de variáveis de ambiente (padrões mais seguros, salvaguardas aprimoradas, educação dentro do produto), uma visão geral de gestão e segurança das variáveis de ambiente em toda a equipe, e um log de atividades mais fácil de usar
Nota de leitura: não foram publicadas contagens, e a ferramenta não é nomeada aqui
A Vercel descreve os clientes afetados apenas como "um subconjunto limitado" e "um pequeno número"; não publicou uma contagem. Este site não divulga números que a organização não revelou.
O boletim da Vercel nomeia o fornecedor da ferramenta de IA, mas, pela política deste site, nomeamos apenas a organização que divulgou o incidente e descrevemos as outras partes pelo papel ("uma ferramenta de IA de terceiros"). Para verificar a sua própria organização, use o identificador do aplicativo OAuth no boletim da Vercel, e não o nome.
Em qual etapa o dano poderia ter sido evitado
1. Ferramenta de IA de terceiros
Seu aplicativo OAuth está amplamente comprometido
↓→
Configuração que ajuda
Administradores limitam quais aplicativos se conectam e com quais escopos
2. Conta Google do funcionário
Assumida; usada para entrar na Vercel
↓→
Configuração que ajuda
Sem ferramentas de teste em contas administrativas de produção
3. Ambiente da Vercel
Variáveis de ambiente enumeradas
↓→
O que os clientes podem fazer
Os clientes não conseguem impedir esta etapa; se os valores vazam depende da categoria na etapa 4
4a. Legível (Config)
Descriptografada e obtida em texto simples
4b. Somente escrita (Secret)
A Vercel informa apenas 4a como comprometida
O que pode ir em Config (valores podem ser exibidos)
- Valores inofensivos se públicos: URLs públicas, feature flags, níveis de log
- Valores enviados ao navegador de qualquer forma: por exemplo, qualquer coisa com prefixo
NEXT_PUBLIC_ - Configurações que você precisa ler de volta: nomes de região, nomes de bucket — coisas que não abrem nada por si só
O que deve ir em Secret (valores não podem ser exibidos)
- Chaves de API e tokens de acesso: pagamentos, envio de e-mails, APIs de IA
- Strings de conexão e senhas de banco de dados
- Chaves de assinatura e criptografia: assinatura de sessão e JWT, segredos de verificação de webhooks
- Credenciais administrativas de serviços externos: chaves de acesso à nuvem e similares
Visão deste site: valores que você pode exibir depois também podem ser lidos por um invasor
O motivo para manter uma variável de ambiente legível é quase sempre poder verificar o valor depois. Este incidente mostrou que a mesma categoria é legível para qualquer pessoa que consiga entrar na plataforma. As variáveis que a Vercel informa como comprometidas são exatamente essa categoria.
Um teste basta: você algum dia vai precisar ler este valor de volta nesta tela? Se não, transforme-o em Secret. Um segredo que você quer consultar deve ficar onde você realmente o guarda — um gerenciador de senhas ou o console do provedor — e não em uma cópia legível na sua plataforma de deploy.
A documentação da Vercel também oferece uma política para equipes, Separate Production Secret Values, que exige que os Secrets de produção sejam diferentes dos de Preview e Development. É mais uma configuração que impede que uma chave de preview vazada funcione em produção.
A mesma lógica se aplica a outros sistemas PaaS e de CI. Todo serviço que mantém seus segredos de forma legível torna-se um segundo local de armazenamento, separado daquele que você de fato gerencia. Os fundamentos de onde os segredos devem ficar e como separá-los estão em O que torna arquivos .env e chaves de API arriscados.
Uma série de comprometimentos que começou com uma ferramenta de desenvolvedor também aconteceu em maio de 2026 com TanStack, Nx Console e GitHub. Ali, o ponto de partida foi um canal de distribuição de código (pacotes npm e uma extensão de editor), e a lição sobre estruturas em que uma única chave roubada não consegue publicar sozinha está em O que desenvolvedores devem verificar após a cadeia TanStack, Nx Console e GitHub.
No incidente da Vercel, o ponto de partida não foi código, mas as permissões de um SaaS conectado via OAuth. Para um caso em que o ponto de partida foi uma ferramenta executada no próprio CI, veja o comprometimento de cadeia de suprimentos do Trivy.
Fontes (registro público)
Os fatos deste artigo vêm das fontes públicas abaixo. Técnicas de ataque, valores de IoC e informações que identifiquem o atacante não são abordados.
- Vercel, "Vercel April 2026 security incident" (boletim de segurança, publicado em 19 de abril de 2026, atualizado em 24 de abril) — vercel.com
- Documentação da Vercel, "Sensitive environment variables" (tipos Config e Secret, revisão de 28 de agosto de 2026) — vercel.com
- Documentação da Vercel, "Rotating environment variables" (rotação sem interrupção) — vercel.com
- Documentação da Vercel, "Deployment Protection" (Standard Protection) — vercel.com
- Google Workspace Admin Help, "Control which apps access Google Workspace data" — knowledge.workspace.google.com
Histórico de atualizações
2026-09-30: Primeira versão, com base no boletim de segurança da Vercel (revisão de 24 de abril) e na documentação oficial da Vercel em 30 de setembro de 2026. Atualizaremos esta página se a Vercel atualizar seu boletim.
Leia a seguir
- Um caso mais recente em plataformas para desenvolvedores: acesso não autorizado a um aplicativo interno de vendas da WorkOS
- Onde os segredos devem ficar: O que torna arquivos .env e chaves de API arriscados / O que é um arquivo .env?
- Outros incidentes que começaram com ferramentas de desenvolvedor: A cadeia TanStack, Nx Console e GitHub / O que usuários de CI devem fazer após o comprometimento do Trivy
- Violações por meio de credenciais válidas: Em 2026, as violações ocorreram por meio de credenciais válidas
- Proteção de contas: Escolhendo a autenticação multifator
- Mantenha segredos fora de repositórios: Impeça segredos antes do commit com o gitleaks
- Outros incidentes de 2026: Vazamentos de dados e ciberataques de 2026