A Vercel Guardou os Seus Segredos em Texto Simples e Chamou-Lhe Uma Funcionalidade
Um atacante propagou-se a partir de uma ferramenta de IA comprometida, através de uma conta Google, até à infraestrutura da Vercel e decifrou todas as variáveis de ambiente não marcadas manualmente como «sensíveis». A violação durou dois meses antes de alguém dar por ela.
A Vercel foi violada. O atacante esteve lá dentro aproximadamente dois meses antes da deteção. Enumerou e decifrou variáveis de ambiente de clientes — chaves de API, palavras-passe de bases de dados, chaves de assinatura, tokens — em todos os projetos que não usavam a marcação opcional «sensível» da Vercel.
A cadeia de ataque: uma ferramenta de IA de terceiros chamada Context.ai foi comprometida. O atacante usou essa posição inicial para assumir o controlo da conta Google Workspace de um colaborador da Vercel. A partir daí, propagou-se para os sistemas internos da Vercel. Depois começou a ler segredos.
Os dados estão agora, alegadamente, a ser oferecidos no BreachForums por 2 milhões de dólares.
A caixa de verificação «sensível» que não era predefinição
Eis a parte que interessa.
A Vercel tem dois tipos de variáveis de ambiente. As normais, que são "encrypted at rest" (cifradas em repouso) mas que podem ser decifradas e lidas pelos sistemas da Vercel. E as «sensíveis», que usam cifragem adicional que, segundo a Vercel, impede até o acesso interno.
O atacante conseguia ler todas as normais. Apenas as «sensíveis» estavam protegidas.
O problema: a marcação «sensível» era opcional. Não era a predefinição. Todos os programadores que definiram DATABASE_URL, STRIPE_SECRET_KEY ou JWT_SIGNING_KEY sem marcar a caixa — e isso é a maioria — tinham esses valores guardados num formato que um atacante com acesso interno conseguia decifrar.
A orientação da Vercel após a violação: "Enable the sensitive environment variable feature for encrypted storage." Tradução: a cifra que assumia estar a proteger os seus segredos não os estava, de facto, a proteger de nós — nem de quem entrasse nos nossos sistemas.
Dois meses de tempo de permanência
O comprometimento inicial ocorreu em fevereiro de 2026. A Vercel publicou o seu primeiro boletim de segurança a 19 de abril. São aproximadamente dois meses com um atacante com acesso aos sistemas internos.
A própria equipa de segurança da Vercel descreveu o atacante como "highly sophisticated based on their operational velocity and in-depth understanding of Vercel's product API surface" — altamente sofisticado, com base na sua velocidade operacional e no conhecimento profundo da superfície da API de produto da Vercel. Quando a empresa que aloja a sua infraestrutura diz que o atacante compreendia os seus sistemas melhor do que o esperado, isso deve fazê-lo parar para pensar.
Durante esses dois meses, o atacante teve tempo para enumerar todas as variáveis de ambiente acessíveis nos projetos de clientes afetados. Tempo para exfiltrar. Tempo para vender.
A cadeia de fornecimento OAuth
O ponto de entrada nem sequer foi o código da própria Vercel. Um colaborador da Vercel autorizou a Context.ai — uma ferramenta de produtividade baseada em IA — através de Google OAuth. Quando a Context.ai foi comprometida, o atacante herdou todas as permissões que essa autorização OAuth concedia.
É um padrão que se repete. As organizações protegem cuidadosamente a sua autenticação principal e depois distribuem tokens OAuth a ferramentas de terceiros que têm a sua própria postura de segurança, frequentemente mais fraca. Basta uma aplicação comprometida na cadeia e o atacante herda o acesso do seu colaborador.
A ID da aplicação OAuth comprometida é pública: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Se a sua organização autorizou esta aplicação, revogue-a agora.
O que deve fazer
Se faz deployment na Vercel:
- Rotacionar todas as variáveis de ambiente imediatamente — não espere para determinar se foi "afetado"
- Ativar a marcação «sensível» em todas as variáveis de ambiente a partir de agora
- Auditar as permissões de aplicações OAuth do seu Google Workspace e revogar tudo o que não use ativamente
- Rever os registos de deployment da Vercel à procura de alterações inesperadas entre fevereiro e abril de 2026
- Verificar os serviços a jusante (bases de dados, processadores de pagamentos, APIs) quanto a acessos não autorizados que usem as credenciais que estavam guardadas na Vercel
A verdadeira lição
A arquitetura da Vercel armazenava os segredos dos clientes de forma que um acesso interno os conseguia decifrar. Ofereciam uma opção mais forte, mas não a tornaram a predefinição. Durante dois meses, ninguém reparou que um atacante lia esses segredos.
É este o problema da segurança do tipo "confie em nós". A Vercel cifrava as suas variáveis de ambiente em repouso — tecnicamente verdade. Mas detinha as chaves de decifração. Quando os seus sistemas foram comprometidos, também o foram os seus segredos.
A alternativa é uma arquitetura de conhecimento zero, em que o prestador de serviços matematicamente não consegue decifrar os seus dados. Não "opta por não o fazer" — não consegue. Nenhum comprometimento interno, nenhum colaborador mal-intencionado, nenhum atacante sofisticado que habite na sua infraestrutura durante dois meses consegue ler aquilo para o que o servidor nunca teve chaves de decifração.
A Vercel está a pedir aos clientes que marquem uma caixa para aderirem à cifra real. A questão que vale a pena colocar: porque não foi essa a única opção desde o início?