Guia de Resposta a Incidentes da Vercel de Abril de 2026
Última atualização: 20 de abril de 2026 @ 12h07 AEST/Brisbane - (v2 — incorpora a atualização do CEO da Vercel de 20 de abril)
IMPORTANTE: Isto não é aconselhamento jurídico ou oficial. Se você acha que foi comprometido, entre em contato com um parceiro de resposta a incidentes. Estas informações são oferecidas exclusivamente como boa vontade pela equipe OpenSourceMalware. Se você quiser introduções a empresas de resposta a incidentes, podemos sugerir algumas com as quais já trabalhamos.
O que aconteceu?
A Vercel divulgou em 19 de abril de 2026 que um atacante obteve acesso não autorizado a sistemas internos. Aqui está o anúncio oficial:
Em 20 de abril, o CEO da Vercel, Guillermo Rauch, publicou uma atualização detalhada confirmando o caminho de acesso inicial: um funcionário da Vercel usou uma plataforma de IA chamada Context.ai, que foi ela mesma violada; a partir daí, o atacante migrou para a conta do Google Workspace do funcionário e escalou para os ambientes da Vercel. As variáveis de ambiente são criptografadas em repouso, mas o atacante conseguiu enumerar variáveis não marcadas como "sensíveis". A Vercel caracteriza o atacante como altamente sofisticado e provavelmente acelerado por IA. A Google Mandiant está envolvida na resposta. A Vercel afirma que Next.js, Turbopack e seus projetos de código aberto permanecem seguros.
Aqui está a seção importante de indicadores de comprometimento desse aviso de segurança:
Bem escasso em detalhes. Eles nem dizem onde verificar esse único IOC do Google. Como cliente da Vercel, estou bastante decepcionado com esse nível de detalhe. Ajude-me a entender o que procurar! Diga-me onde ir para saber se fui comprometido ou não!
Na ausência de detalhes da Vercel, criamos este documento
Se você executa workloads na Vercel, assuma o seguinte até que se prove o contrário:
- Variáveis de ambiente não marcadas como "sensíveis" em qualquer projeto Vercel na janela de exposição podem ter sido legíveis.
- Qualquer credencial enviada para a Vercel via painel de controle ou CLI
vercel env que não seja rotacionada é uma responsabilidade permanente.
- Tokens nos caminhos de integração Vercel ↔ GitHub e Vercel ↔ Linear podem ter sido acessíveis.
- Você não receberá um sinal claro "você foi afetado / não foi afetado" rapidamente. Rotacione primeiro, depois investigue.
Conhecido vs. alegado: mantenha-os separados em suas comunicações
Essa distinção é importante para comunicações executivas e para não reagir demais (ou de menos).
Confirmado pela Vercel (boletim + atualização do CEO de 20 de abril)
- Acesso não autorizado a certos sistemas internos da Vercel.
- Vetor de acesso inicial: Context.ai, uma plataforma de IA usada por um funcionário da Vercel, foi violada. O atacante usou esse ponto de apoio para comprometer a conta do Google Workspace do funcionário na Vercel, depois escalou a partir daí para os ambientes da Vercel.
- As variáveis de ambiente dos clientes são criptografadas em repouso. Variáveis designadas como "não sensíveis" eram, no entanto, enumeráveis pelo atacante uma vez dentro.
- Impacto nos clientes caracterizado como "bastante limitado"; a Vercel entrou em contato diretamente com clientes sobre os quais tem preocupações.
- Next.js, Turbopack e os projetos de código aberto da Vercel foram analisados e acredita-se que permaneçam seguros (ou seja, nenhum artefato malicioso no caminho de lançamento desses projetos, conforme declaração da Vercel de 20 de abril).
- Atacante caracterizado como altamente sofisticado e provavelmente significativamente acelerado por IA.
- Parceiros de resposta: Google Mandiant está ativamente envolvida; empresas externas de resposta a incidentes, pares do setor e autoridades policiais estão envolvidos.
- A Vercel entrou em contato com a Context.ai para ajudar a entender o escopo completo.
- A Vercel implementou melhorias na interface do usuário: página de visão geral das variáveis de ambiente, gerenciamento aprimorado de variáveis de ambiente sensíveis.
Relatado / atribuído por terceiros e pelo atacante (não confirmado pela Vercel)
- Integrações Linear e GitHub desproporcionalmente impactadas (relatos da comunidade, notavelmente Theo Browne no X).
- Dados listados para venda no BreachForums: banco de dados interno, contas de funcionários, tokens do GitHub, tokens npm, fragmentos de código-fonte, carimbos de data/hora de atividade — oferecidos por ~$2M.
- Ator se identifica como ShinyHunters; outros atores historicamente ligados a esse apelido negaram envolvimento.
- Classes específicas de dados de clientes exfiltradas além do que a Vercel confirmou diretamente com os clientes.
Trate os relatos não confirmados como plausíveis e acionáveis para sua própria triagem, mas não os cite como fato em comunicações com clientes ou reguladores até que a Vercel os corrobore ou você tenha evidências independentes. A lacuna entre "variáveis de ambiente enumeráveis" (confirmado por Rauch) e "tokens npm + GitHub à venda no BreachForums" (alegação do atacante) é a lacuna que mais importa para o risco da cadeia de suprimentos — assuma o pior para fins de rotação, mantenha-se na versão confirmada para comunicações.
Escopo: quem precisa executar este manual
Maior urgência — você recebeu contato direto da Vercel, ou qualquer um dos seguintes se aplica:
- Você tem (ou teve) uma integração Vercel ↔ GitHub com escopo de escrita no repositório.
- Você tem (ou teve) uma integração Vercel ↔ Linear.
- Você armazena segredos não criptografados (não marcados como sensíveis) como variáveis de ambiente da Vercel.
- Você publica pacotes npm a partir de CI/CD que roda na ou através da infraestrutura da Vercel.
Urgência padrão — qualquer equipe com projetos ativos na Vercel, mesmo sites de marketing. Sites de marketing geralmente contêm chaves de API de CMS, tokens de analytics e webhooks de manipuladores de formulários que podem migrar para sistemas mais sensíveis.
Ainda faça — mesmo que seus projetos tenham sido excluídos antes do incidente. A questão é se os segredos já estiveram residentes na Vercel em uma forma legível, não se o projeto ainda está lá.
Pergunta paralela: sua organização está exposta diretamente ao Context.ai?
A atualização de 20 de abril menciona a Context.ai como o fornecedor upstream violado. Se alguém em sua organização usa a Context.ai independentemente da Vercel — para inteligência de reuniões, gerenciamento de conhecimento, enriquecimento de CRM ou qualquer outro fluxo de trabalho — você pode ter sua própria janela de exposição direta separada do incidente da Vercel.
Execute estas verificações em paralelo:
- Consulte seu SSO / IdP (Okta, Entra, Google Workspace) em busca de qualquer usuário que tenha se autenticado na Context.ai ou em um aplicativo OAuth relacionado à Context.
- Pesquise no console de administração do Google Workspace → Segurança → Logs de acesso a aplicativos OAuth por
context.ai ou IDs de aplicativos associados.
- Verifique as ferramentas de gerenciamento de despesas corporativas / gastos com SaaS em busca de assinaturas da Context.ai.
- Revise quais escopos OAuth foram concedidos — escopos de leitura do Gmail, Calendário, Drive e diretório do Workspace são de alto impacto.
Se você encontrar uso da Context.ai em seu ambiente, revogue as concessões OAuth, rotacione quaisquer credenciais que passaram pelos fluxos de trabalho da Context.ai e monitore as contas do Google Workspace dos usuários afetados para os mesmos indicadores de comprometimento que a Vercel descreve ter visto na conta de seu funcionário. Entre em contato diretamente com a Context.ai para obter seus próprios detalhes do incidente; a Vercel declarou publicamente que está coordenando com a Context para ajudar outras organizações afetadas.
Fase 0: Parar o sangramento (primeiros 60 minutos)
Dois objetivos: evitar novos danos, preservar evidências.
-
Congele as implantações. Pause as implantações automáticas nos branches de produção. Você quer evitar que uma compilação modificada pelo atacante seja enviada, e quer impedir que o log de auditoria seja alterado.
-
Desative o GitHub App da Vercel. Se você tiver o GitHub App da Vercel instalado, o que será o caso se você estiver fazendo implantações automáticas na Vercel ao enviar novo código para o GitHub. Você pode encontrar seus aplicativos GitHub instalados em https://github.com/organizations/<Organização-GitHub>/settings/installations
-
Identifique qual acesso o GitHub App possui. Clique no botão de configuração acima e audite quais repositórios o aplicativo Vercel tinha acesso. Isso informa no que você precisa focar agora. Vá para GitHub → Organização → Configurações → GitHub Apps → Vercel. Revise:
- Acesso ao repositório (todos os repositórios vs. selecionados)
- Permissões concedidas
- Data de instalação e quem instalou
- Faça um snapshot do log de auditoria da Vercel para sua equipe. Exporte ou capture a tela imediatamente. A janela de retenção é limitada e a interface do usuário não expõe tudo. Obtenha isso antes de começar a fazer alterações que poluirão o log. Você pode encontrá-lo em https://vercel.com/activity-log
- Ative “Observability Plus”. Este é um recurso pago adicional da Vercel, e é ruim ter que sugerir que você o ative e PAGUE por ele, mas neste caso acho que é a melhor coisa a fazer durante a resposta a incidentes. Certamente não estou feliz com isso, mas o ativei simplesmente porque ele mantém os logs de auditoria por mais tempo do que o padrão, que é MUITO curto.
- Inventarie a amplitude da exposição. Para cada equipe/conta Vercel que você controla, liste:
- Projetos e seus repositórios Git vinculados
- Integrações conectadas (GitHub App, Linear, Slack, integrações de marketplace)
- Membros da equipe e suas funções
- Tokens de acesso pessoal / tokens de API emitidos sob a equipe
- Deploy hooks
- Revise o log de auditoria da Organização do GitHub. Procure na janela de exposição (conservadoramente, 1 a 15 de abril de 2026 até o presente). Filtre por:
repo.add_member, repo.add_topicorg.invite_member, org.add_memberintegration_installation, integration_installation.repositories_addedprotected_branch.destroy,
Não faça ainda anúncios ou rotacione segredos. Você quer o snapshot primeiro.
Fase 1: Verificar Indicadores de Comprometimento (IOC)
Os detalhes do anúncio da Vercel são bem escassos:
Pelo que podemos entender, eles sugerem que você vá ao Console de Administração do Google Workspace e procure por este aplicativo googleusercontent.com. Veja como encontrar no console:
-
No console de administração do seu workspace, vá para Segurança > Acesso e controle de dados > Controles de API e encontre os aplicativos acessados e pendentes.
-
Em seguida, procure nas diferentes listas pelo IOC que aparentemente é um aplicativo oauth: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
-
Se encontrá-lo, remova-o imediatamente e consulte um parceiro de resposta a incidentes. Isso está acima do meu nível salarial.
Fase 2: Rotação de credenciais
A rotação é a ação de maior valor isolada. Faça em ordem de prioridade para que, se você for interrompido, as coisas mais perigosas já tenham sido tratadas.
O que você precisa rotacionar depende do que seus ambientes GitHub e Vercel expuseram. Comece com PATs do GitHub, etc., e vá saindo a partir daí usando este guia.
Níveis de prioridade
Nível 0 — Rotacione hoje, antes de qualquer outra coisa:
- Rotacione imediatamente todos os PATs do GitHub e mate quaisquer sessões existentes. Tokens de Acesso Pessoal, ou PATs. Existem dois tipos de PATs:
- Rotacione imediatamente quaisquer variáveis de ambiente da Vercel que sejam sensíveis: http://vercel.com/all-env-vars
Nível 1 — Rotacione hoje, dependendo do que você expôs em seus aplicativos:
- Chaves secretas do processador de pagamento (Stripe, Adyen, Braintree, etc.)
- Segredos de assinatura de autenticação (
AUTH_SECRET / NEXTAUTH_SECRET do NextAuth, chaves de assinatura JWT, chaves de cookie de sessão, tokens CSRF)
- Strings de conexão de banco de dados com acesso de escrita (
DATABASE_URL, URLs diretas Postgres/MySQL, URIs Mongo, Redis com autenticação)
- Chaves de provedor de nuvem com escopo amplo ou raiz (chaves de acesso IAM da AWS, JSON de conta de serviço GCP, segredos de cliente Azure)
- Segredos de assinatura de webhook (Stripe, GitHub, Slack — rotacione e atualize a configuração do remetente)
Nível 2 — Rotacione esta semana:
- Chaves de API de SaaS de terceiros (analytics, provedores de e-mail, SMS, CRM)
- Segredos de cliente OAuth para aplicativos que você possui
- Credenciais SMTP
- Chaves de criptografia para criptografia em nível de aplicativo (rotacione com incremento de versão de chave, não substituição direta)
- Chaves de purga de CDN, chaves de serviço de imagem
- Chaves de provedor de feature flag
Nível 3 — Rotacione quando conveniente, mas ainda rotacione:
- Tokens de analytics somente leitura
- DSNs do Sentry / logging (nota: a rotação de DSN não é crítica se você aceitar uma pequena janela de eventos perdidos)
- Chaves públicas e chaves anônimas (ainda rotacione — elas podem revelar a existência do projeto e às vezes permitir enumeração)
Armadilhas na ordem de operações
- Chaves de assinatura de sessão invalidam todas as sessões ativas na rotação. Planeje um evento de logout forçado. Comunique-o.
- Segredos de webhook devem ser rotacionados em ambas as extremidades. Atualize o remetente primeiro (Stripe, GitHub) para enviar sob o novo segredo, depois seu receptor para verificar contra ele. Ou suporte ambos temporariamente.
- Credenciais de banco de dados — crie o novo usuário primeiro, faça o deploy, depois revogue o antigo. Não substitua diretamente ou você causará uma interrupção.
- Chaves AWS — se você está rotacionando as chaves de acesso de um usuário IAM, crie a segunda chave, faça o rollout das implantações, depois exclua a primeira. Não
desative e espere.
- Reimplante após alterações nas variáveis de ambiente. As variáveis de ambiente da Vercel são incorporadas no momento da compilação para muitas configurações de framework. Alteração de variável de ambiente sem um novo deploy não é totalmente aplicada.
- Verifique também seus segredos de CI. Se um segredo foi espelhado para GitHub Actions, CircleCI ou similar, rotacione o espelho.
Não se esqueça dessas omissões comuns
.env.local commitado em um repositório privado (ainda é um problema — o código-fonte pode ter sido exfiltrado)- Segredos em ambientes de preview/desenvolvimento da Vercel, não apenas produção
- Segredos armazenados como variáveis de ambiente compartilhadas em "nível de equipe" da Vercel
- Deploy hooks (rotacione-os; são gatilhos completos de deploy)
- Tokens de acesso pessoal da Vercel emitidos sob sua conta
- Tokens de Acesso Pessoal do GitHub que autorizaram a instalação do GitHub App da Vercel (separados do próprio aplicativo)
Fase 3: Caça em nível de repositório
Para repositórios que estavam conectados à Vercel:
- Faça um diff do HEAD de
main/master contra o tag/commit que você sabe ser bom antes da janela do incidente.
- Procure por alterações em:
package.json → scripts (especialmente postinstall, prepare, preinstall)package-lock.json / pnpm-lock.yaml / yarn.lock — adições inesperadas de dependências ou atualizações de versão.github/workflows/*.yml — novos workflows, novos passos run:, novos uses: com SHAs não fixadosvercel.json — alterações no comando de build, novos rewrites/redirects que poderiam exfiltrar tráfego
Se você publica pacotes npm a partir desses repositórios
É aqui que um comprometimento inicial da Vercel pode se tornar um evento na cadeia de suprimentos. Mesmo que você não use a Vercel para publicar, se um atacante obteve seu token do GitHub e seu workflow de publicação usa esse token:
- Verifique o histórico de publicação do npm:
npm view <pkg> time --json para versões inesperadas.
- Compare o tarball de cada versão recente com a tag git da qual ela supostamente se origina. Atacantes publicam a partir de uma tag que não corresponde ao que está no registro.
- Audite o uso de
NPM_TOKEN nos workflows — rotacione o token, revise quem tinha acesso.
- Verifique se novos mantenedores foram adicionados aos seus pacotes:
npm owner ls <pkg>.
- Se você mantém algo significativo, fique atento à execução de scripts pós-instalação no tarball — descompacte e inspecione.
Se você encontrar evidências de uma publicação não autorizada, reporte à segurança do npm ([email protected]) e considere registrar no OSV.dev. Deprecie a versão ruim; não cancele a publicação (a despublicação tem limite de tempo e quebra consumidores downstream).
Nota sobre pacotes de propriedade da Vercel especificamente: A atualização de 20 de abril da Vercel afirma que Next.js, Turbopack e seus projetos de código aberto foram analisados e considerados seguros. Essa é a afirmação da Vercel sobre seu caminho de lançamento — você ainda deve auditar seus pacotes como acima. Se você consome Next.js ou Turbopack, não precisa fixar em uma versão anterior ao incidente como precaução com base nas informações atuais, mas monitore o boletim da Vercel para mudanças nessa postura.
Fase 4: Revisão da integração Linear
Se sua equipe usa a integração Vercel ↔ Linear:
- Revise o log de auditoria do Linear (Configurações do workspace → Segurança → Log de auditoria) para a janela de exposição.
- Procure por:
- Novas chaves de API emitidas
- Novas integrações adicionadas
- Comentários postados por contas de serviço
- Alterações nos destinos de webhook
- Convites de membros
- Visualizações/exportações de dados de issues (a integração tem acesso de leitura a issues, que frequentemente contêm nomes de clientes, detalhes de bugs e, às vezes, credenciais coladas em tickets)
- Preocupação específica: as issues do Linear frequentemente contêm segredos colados de depuração de desenvolvedores. Pesquise seu workspace do Linear para padrões comuns de vazamento (
AKIA, sk_live_, ghp_, ghs_, npm_, eyJ, ----BEGIN). Qualquer coisa encontrada deve ser rotacionada.
Fase 5: Revisão de logs de sistemas downstream
Rotacionar credenciais invalida a persistência do atacante na maioria dos casos, mas eles podem já ter usado o acesso. Verifique os consumidores de seus segredos rotacionados em busca de sinais de uso durante a janela de exposição.
Janelas a verificar
Use 1 de abril de 2026 até agora como limite inferior conservador. O incidente foi divulgado em 19 de abril, mas o acesso inicial é anterior à divulgação. Se a Vercel publicar uma data mais específica, reduziremos isso de acordo.
O que consultar
- AWS CloudTrail — chamadas de API incomuns de chaves IAM comprometidas, especialmente rajadas
GetObject contra buckets S3, CreateUser, AttachUserPolicy, logins no console de novos ASNs/países.
- Logs de auditoria de banco de dados —
SELECT * incomum em tabelas sensíveis, grandes exportações, conexões de IPs de origem inesperados.
- Logs de pagamento Stripe — criação incomum de clientes, criação de transferências, criação de chaves de API.
- Logs do provedor de autenticação (Auth0, Clerk, Cognito, Firebase) — logins de viagem impossível, redefinições de senha acionadas para usuários administradores, novos registros de aplicativos.
- Provedor de e-mail (SendGrid, Postmark, etc.) — campanhas de saída inesperadas, novas chaves de API, alterações na identidade do remetente.
- GitHub — clones, criações de fork, novas chaves SSH em contas de usuário com acesso ao repositório.
Primitivas úteis de caça a IOC
Cole quaisquer nomes de host ou IPs controlados pelo atacante publicados pela Vercel ou parceiros de resposta a incidentes em:
- Logs de acesso HTTP do seu frontend (atacantes às vezes fazem pré-testes para confirmar o acesso antes de agir).
- Logs de DNS — resolução de saída de domínios incomuns de seus servidores.
- Logs de proxy de saída / VPC flow.
Até o momento da publicação, nenhum IOC foi divulgado pela Vercel. Monitore o boletim da Vercel e os artigos de empresas de resposta a incidentes conhecidas para atualizações.
Fase 6: Detecção de comprometimento persistente
A persistência do atacante após uma violação em nível de plataforma geralmente assume estas formas. Caça ativamente cada uma:1. Novos membros da equipe ou colaboradores na sua equipe Vercel, organização GitHub, workspace Linear ou contas na nuvem. Datados dentro da janela de exposição.
2. Novas autorizações OAuth em provedores SSO conectados (Google Workspace, Okta, Entra ID) para as contas dos seus desenvolvedores.
3. Configuração de CI/CD modificada — workflows que agora fazem phone home, novos runners auto-hospedados, novos secrets com nomes inofensivos.
4. Implantações inesperadas no Vercel — verifique o histórico de deploys para implantações que você não consegue mapear para um commit conhecido de um autor conhecido.
5. Indícios de reverse shell em logs de funções serverless — blobs base64 sendo escritos/executados, conexões de saída incomuns de Edge/Serverless Functions.
6. Desvio de DNS — novos subdomínios, alterações de CNAME, redirecionamentos adicionados via vercel.json ou configuração do framework.
7. Alterações de autenticação — MFA desativado, códigos de recuperação regenerados, senha alterada sem ação do usuário.
Comunicações
Interna
Designe um comandante de incidente. Reunião diária mínima enquanto a rotação estiver em andamento. Documento único de fonte da verdade para "o que rotacionamos, o que está pendente, o que encontramos." Mantenha fora do Linear se o Linear estiver no escopo do incidente — use um canal alternativo.
Para clientes
Consulte o jurídico. Os limites de notificação variam, mas:
- GDPR: 72 horas para violações notificáveis que afetem residentes da UE.
- Austrália (Esquema de Violações de Dados Notificáveis, OAIC): notifique o mais rápido possível quando houver probabilidade de dano grave.
- EUA: estado por estado; alguns estados têm janelas de 30 a 60 dias, outros exigem notificação imediata para classes específicas de dados.
- Califórnia (CCPA): obrigações específicas se informações pessoais de residentes da Califórnia estiverem no escopo.
- Clientes SOC 2 / ISO 27001: cláusulas contratuais de notificação frequentemente exigem aviso mais cedo do que os mínimos regulatórios. Leia seus MSAs.
Se você não tiver evidências de saída de dados dos seus sistemas, talvez ainda não tenha uma obrigação de notificação — mas "nós usamos Vercel e a Vercel teve um incidente" sozinho geralmente não é suficiente para acionar notificação, a menos que dados sensíveis estivessem materialmente em risco. Documente seu raciocínio.
Declarações preparadas
Redija estas antes de precisar delas:
- Reunião geral interna
- Aviso para clientes
- Modelo de notificação ao regulador
- Atualização de página de status (se pública)
Higiene de atribuição pública
Não reafirme publicamente as alegações dos atacantes como fato. Vincule ao boletim da Vercel como fonte primária. Deixe a Vercel caracterizar seu próprio incidente — você está na sua faixa caracterizando sua própria exposição.
Endurecimento de médio prazo (pós-incidente)
Este incidente revela problemas estruturais que valem a pena corrigir mesmo que você acabe não sendo afetado.
- Migre todos os segredos para o recurso de variável de ambiente sensível da Vercel. Torne-o o padrão da equipe. Treine os desenvolvedores para marcar ao criar.
- Adote credenciais de curta duração sempre que possível. Use federação OIDC do GitHub para AWS/GCP/Azure em vez de chaves de acesso de longa duração espelhadas em variáveis de ambiente da Vercel. Use gerenciadores de segredos nativos da nuvem (AWS Secrets Manager, GCP Secret Manager) acessados em tempo de execução em vez de variáveis de ambiente incorporadas.
- Inventarie aplicativos OAuth de terceiros conectados ao seu Google Workspace, Microsoft 365, organização GitHub e equipe Vercel. O IAV da Vercel foi o Context.ai — uma plataforma de IA integrada via OAuth na conta Google Workspace de um funcionário. A mesma classe de risco existe em toda organização que aprovou liberalmente integrações de SaaS e ferramentas de IA, e a barreira para "o que é aprovado" caiu consideravelmente na corrida do ouro das ferramentas de IA nos últimos 18 meses. Ações concretas:
- Obtenha seu relatório de aplicativos OAuth do Google Workspace (Admin console → Segurança → Controles de API → Controle de acesso de aplicativos). Revise todos os aplicativos com escopos sensíveis (
gmail.readonly, calendar, drive, admin.directory).
- Faça o mesmo para o Microsoft 365 (Entra ID → Aplicativos empresariais).
- Institua revisão trimestral. Exija aprovação de segurança para novas concessões OAuth que carreguem escopos sensíveis.
- Considere restringir a instalação de aplicativos OAuth a uma lista de permissões em vez de aprovação orientada pelo usuário.
- Princípio do menor privilégio no escopo do GitHub App. Se a Vercel não precisar de acesso a repositórios em toda a organização, restrinja aos repositórios que ela realmente implanta.
- Rotação de deploy hooks como rotina. Trimestralmente.
- Crie uma varredura de segredos em seu pre-commit e CI. Trufflehog, gitleaks ou equivalente. Varra retrospectivamente o histórico do repositório em busca de qualquer coisa que possa ter sido commitada e depois rotacionada — assuma que o que foi commitado uma vez ainda está em algum clone.
Referência
Histórico de alterações
- 2026-04-20 (v2) — Atualizado após a declaração do CEO da Vercel, Guillermo Rauch, em 20 de abril. Vários itens promovidos de "reportado" para "confirmado": Context.ai nomeado como o fornecedor upstream violado, conta Google Workspace de um funcionário da Vercel como o pivô, enumeração de variáveis de ambiente não sensíveis como o movimento lateral dentro da plataforma. Adicionado escopo paralelo para exposição direta ao Context.ai. Adicionada declaração da Vercel de que Next.js, Turbopack e projetos OSS permanecem seguros. Adicionado engajamento da Mandiant. Reforçada a recomendação de inventário de aplicativos OAuth.
- 2026-04-20 (v1) — Versão inicial. Baseada no boletim da Vercel de 19/04/2026 e em reportagens públicas contemporâneas. Atualize à medida que a Vercel publicar detalhes adicionais, IOCs ou uma janela de exposição mais estreita.
opensourcemalware/vercel-april2026-incident-response
