Saltar para o conteúdo principal

Violações da Vercel + Lovable: Como as Ferramentas de IA se Tornaram o Novo Risco de Cadeia de Suprimentos da Web3

· 15 min de leitura
Dora Noda
Dora Noda
Software Engineer

Em uma única semana de abril de 2026, dois incidentes de SaaS aparentemente não relacionados colidiram de uma forma que deve redefinir o modelo de ameaças de cada equipe Web3. A Vercel — a plataforma de implantação por trás de milhares de UIs de carteiras e frontends de dApps — revelou que um invasor migrou para seu ambiente por meio de uma ferramenta de produtividade de IA comprometida chamada Context.ai. Dias depois, a plataforma de vibe-coding Lovable foi flagrada vazando código-fonte, credenciais de banco de dados e históricos de chat de IA em milhares de projetos anteriores a novembro de 2025 através de um bug de autorização não corrigido. As duas histórias não compartilham infraestrutura comum. Elas compartilham algo pior: o mesmo padrão de impacto, onde ferramentas de IA tornaram-se silenciosamente identidades privilegiadas dentro da cadeia de ferramentas do desenvolvedor — e a Web3 herdou o risco sem nunca precificá-lo.

Auditorias de contratos inteligentes, governança multisig, assinatura em hardware wallet — nenhuma dessas defesas está no caminho que um invasor percorre ao comprometer o pipeline de compilação que entrega a UI de aprovação de transações de seus usuários. Abril de 2026 tornou essa lacuna visível. Se a indústria tratará isso como um alerta ou como outra perda absorvida depende de como será o próximo trimestre.

A Cadeia Vercel-Context: Um Clique de OAuth, Centenas de Frontends​

O relatório de incidente de 19 de abril de 2026 da Vercel parece um caso clássico de dispersão de OAuth (OAuth sprawl). O ataque não começou na Vercel. Começou meses antes, em fevereiro de 2026, quando um funcionário da Context.ai instalou um cheat de Roblox contendo o Lumma Stealer e perdeu suas credenciais do Google Workspace, além de segredos do Supabase, Datadog e Authkit.

Isso, por si só, é uma história rotineira de roubo de credenciais. O que o tornou um ataque à cadeia de suprimentos de múltiplas organizações foi o escopo do OAuth. Pelo menos um funcionário da Vercel havia se inscrito anteriormente no "AI Office Suite" da Context.ai usando sua conta corporativa do Google da Vercel e clicado em "Permitir Tudo" — concedendo à Context.ai permissões persistentes e amplas em todo o Google Workspace da Vercel. Quando o invasor assumiu o controle do aplicativo OAuth da Context.ai, ele herdou essa confiança automaticamente. A partir daí, ele migrou para a conta de Workspace da Vercel do funcionário e depois para os ambientes da Vercel, onde enumerou e descriptografou variáveis de ambiente não sensíveis.

Um ator de ameaça chamado ShinyHunters listou o banco de dados resultante à venda no BreachForums por US$ 2 milhões. A Vercel sustenta que as variáveis marcadas como "sensíveis" permaneceram criptografadas e não foram lidas. Essa distinção importa menos do que a pergunta: quantos projetos Web3 implantados na Vercel realmente marcaram suas chaves RPC, tokens de API e segredos de indexadores como sensíveis? A resposta, a julgar pela corrida para rotacionar credenciais, foi: nem todos.

A DEX da Solana Orca confirmou que seu frontend roda na Vercel e rotacionou todas as credenciais de implantação por precaução. O CTO do Cork Protocol instou publicamente os usuários a pausarem a interação com dApps DeFi hospedados na Vercel até que os projetos tivessem tempo de rotacionar as chaves. Os protocolos on-chain e os fundos dos usuários não foram afetados diretamente — mas o caminho de uma implantação comprometida na Vercel para uma transação maliciosa de "aprovação ilimitada" apresentada a uma carteira conectada não passa por uma auditoria de contrato inteligente. Ele ignora todas as defesas que a Web3 construiu.

Por que a "Segurança de Frontend" é a Camada que a Web3 Esqueceu de Auditar​

Por cinco anos, a narrativa de segurança dominante no mundo cripto tem sido: "Os contratos inteligentes detêm os fundos, portanto, audite os contratos inteligentes". Isso fazia sentido quando o DeFi era pequeno e os frontends eram páginas estáticas simples no IPFS. Isso não descreve a indústria de hoje, onde as UIs de carteiras são entregues via Vercel, Netlify, Cloudflare Pages e AWS Amplify; onde os payloads de assinatura são construídos em JavaScript que chega via CDN; e onde um único pacote malicioso pode drenar usuários sem quebrar o TLS.

O histórico de comprometimentos de frontends na Web3 é curto, mas caro o suficiente para servir de lição:

  • Agosto de 2022, Slope Wallet: Uma integração do Sentry mal configurada transmitiu silenciosamente materiais de chaves privadas de usuários da carteira móvel Slope para um serviço de monitoramento de aplicativos. Um invasor drenou US$ 4,1 milhões em 9.231 carteiras em cerca de quatro horas. A "vulnerabilidade" era uma ferramenta de telemetria rotineira com acesso excessivo — exatamente o padrão de dispersão de OAuth.
  • Dezembro de 2023, Ledger Connect Kit: Um ex-funcionário da Ledger foi vítima de phishing e teve seu token de sessão NPM roubado, ignorando a autenticação de dois fatores (2FA). O invasor enviou um payload malicioso de drenagem de carteira nas versões 1.1.5–1.1.7 do @ledgerhq/connect-kit. O pacote ficou no ar por cinco horas, drenando ativamente por duas, e atingiu mais de 100 frontends de dApps. Cerca de US$ 600 mil foram roubados — um valor pequeno apenas porque alguém percebeu rápido.
  • Julho de 2024, sequestro de DNS da Squarespace: Uma falha de migração na criação de contas de domínio da Squarespace permitiu que invasores registrassem e-mails de administradores para domínios que haviam sido transferidos do Google Domains sem verificação de e-mail. Os frontends da Compound e da Celer Network foram redirecionados para drenadores de carteiras. O Decrypt relatou que mais de 220 protocolos DeFi permaneceram em risco por semanas depois disso.

Cada um desses incidentes compartilha uma forma: uma camada não-blockchain da pilha — telemetria, registro de pacotes, DNS — foi comprometida, e a auditoria do contrato inteligente não teve nada a dizer sobre isso. Abril de 2026 adicionou duas novas camadas a essa lista: ferramentas de produtividade de IA agindo como identidades OAuth (Vercel) e plataformas de codificação de IA armazenando código e credenciais de clientes (Lovable).

O Bug BOLA da Lovable: 48 Dias, 8 Milhões de Utilizadores e "Comportamento Intencional"​

Enquanto a Vercel reconstruía o seu raio de explosão OAuth, a Lovable — uma plataforma de vibe-coding avaliada em 6,6 mil milhões de dólares com oito milhões de utilizadores — divulgava o seu próprio incidente. A vulnerabilidade era uma falha de Autorização de Nível de Objeto Quebrada (BOLA): um endpoint de API expunha dados de utilizadores sem validação de propriedade. Uma conta gratuita mais cinco chamadas de API foram suficientes para ler perfis de outros utilizadores, código-fonte de projetos e credenciais de bases de dados incorporadas nesse código-fonte.

O bug foi alegadamente encerrado pelos triadores da HackerOne 48 dias antes da divulgação porque os dados expostos viviam sob uma flag "pública" cujo significado a Lovable admitiu mais tarde ser "incerto". Durante esse período, todos os projetos anteriores a novembro de 2025 na plataforma estavam acessíveis. Históricos de chat de IA, código-fonte de clientes e as credenciais que esse código-fonte incorporava — para bases de dados, APIs de pagamento e, sim, endpoints RPC de blockchain — eram enumeráveis por qualquer pessoa disposta a criar um script para a chamada.

A resposta inicial da Lovable no X — negando qualquer "violação de dados" e reformulando a exposição como "comportamento intencional" — é a parte que mais deve preocupar os construtores Web3. Isto sinaliza que os pressupostos operacionais das plataformas de codificação por IA ainda não absorveram o modelo de ameaça que os seus utilizadores herdaram. Quando uma equipa Web3 utiliza a Lovable para estruturar um frontend, as credenciais incorporadas durante a prototipagem não desaparecem. Elas vivem na plataforma, indexadas, recuperáveis e, a partir de abril de 2026 — durante pelo menos 48 dias — acessíveis a qualquer pessoa com uma conta gratuita.

O Multiplicador de Dispersão OAuth: Por que "Apenas Rotacionar Chaves" Não é Suficiente​

Ambos os incidentes remontam à mesma causa raiz: estão a ser concedidos a ferramentas de IA escopos OAuth persistentes e multi-aplicação dentro de organizações que não têm inventário de quais escopos foram concedidos a quais aplicações. Dados empresariais recentes sublinham a escala: 98% das organizações reportam uso de IA não sancionado, e a empresa média opera agora mais de 830 aplicações, com 61% a operar fora da supervisão formal de TI. Quando uma ferramenta de IA é comprometida, cada permissão OAuth alguma vez concedida a ela torna-se parte do alcance do atacante.

O post-mortem da Push Security sobre o incidente da Vercel enquadra-o de forma direta: o ataque foi bem-sucedido porque o modelo de identidade da Vercel tratou uma aplicação de IA de terceiros da mesma forma que tratou um funcionário. Não houve uma redução de escopo para "esta ferramenta tem permissão para ler calendários, não para enumerar variáveis de ambiente". Isso não é uma falha específica da Vercel. É o estado predefinido de quase todos os inquilinos (tenants) do Google Workspace, Microsoft 365 e Okta que integraram assistentes de IA nos últimos 18 meses.

Para as equipas Web3, a implicação é que rotacionar chaves após uma violação do tipo Vercel é necessário, mas não suficiente. O vetor de ataque — concessões OAuth excessivamente privilegiadas para ferramentas de IA — persiste em todos os fornecedores de SaaS na cadeia de suprimentos. Uma equipa que rotacionou as credenciais de implementação da Vercel em abril, mas que ainda tem uma aplicação de notas de reuniões de IA com acesso total ao Drive, está a uma infeção por infostealer de distância do mesmo resultado.

Como se Parece um Frontend Web3 Realmente Defendido​

Existem hoje alguns padrões defensivos que, se combinados, teriam neutralizado incidentes do tipo Vercel e Lovable. Nenhum é atualmente obrigatório.

Hashes de Integridade de Sub-recurso (SRI) para bundles de UI de carteira. O SRI é uma recomendação do W3C que permite aos navegadores verificar se um recurso obtido corresponde a um hash criptográfico antes de o executar. Se uma implementação da Vercel for modificada após a publicação do hash de integridade — por exemplo, por um atacante que entrou no pipeline de build — o navegador recusa-se a carregá-lo. O SRI existe desde 2016 e é suportado de forma trivial. Quase nenhuns frontends Web3 o utilizam para os seus bundles principais, porque os bundles principais mudam a cada implementação e alguém tem de gerir a rotação de hashes.

Manifestos de frontend on-chain. Registos ENS contenthash e CIDs IPFS permitem que um projeto ancore "este é o frontend canónico para o protocolo X" on-chain. Uma carteira que consulte o manifesto antes de carregar a UI pode detetar quando o bundle servido não corresponde ao CID publicado. O EIP-2477 explorou isto para metadados de tokens e a mesma ideia generaliza-se para frontends de dApps. A adoção hoje está concentrada em projetos que já enviam apenas para IPFS — a implementação IPFS da Uniswap é o exemplo óbvio — e está ausente em quase todo o resto.

Simulação de transação no lado do cliente. Carteiras como Rabby e Wallet Guard simulam cada transação antes da assinatura e apresentam o movimento real de ativos ao utilizador. Isto não teria impedido a execução da lógica de drenagem do atacante do Ledger Connect Kit do lado do servidor, mas teria dado aos utilizadores a oportunidade de ver "isto transfere todo o seu saldo de USDC para 0xdesconhecido" antes de clicar em confirmar. A adoção está a aumentar, mas ainda é de carteira em carteira, não de protocolo em protocolo.

Ecrãs de hardware-wallet "o que vês é o que assinas". Dispositivos como Ledger Stax e Keystone analisam calldata e renderizam a intenção legível por humanos no ecrã do dispositivo, derrotando o phishing na camada de UI. Isto só funciona quando o contrato tem um esquema de assinatura transparente (clear-signing) publicado. A maioria dos contratos não o tem.

O padrão em todas as quatro defesas: elas existem, funcionam e não são implementadas por predefinição. Elas custam tempo de engenharia que compete com o lançamento de funcionalidades do produto, e o pior cenário que evitam — uma drenagem massiva — tem, até abril de 2026, acontecido maioritariamente a "outras pessoas".

A Questão da Inflexão​

Historicamente, a Web3 exigiu uma perda de mais de US$ 50M + em fundos de usuários para adotar novos padrões defensivos. As auditorias tornaram-se requisitos básicos após o hack da DAO em 2016. A governança multisig passou de opcional a obrigatória após as explorações da Ronin e da Wormhole em 2022. As carteiras de hardware se normalizaram após a Mt. Gox e dezenas de comprometimentos de exchanges.

As invasões duplas de abril de 2026 não produziram uma perda de US$ 50M. O invasor da Vercel foi pago em variáveis de ambiente, não em fundos de usuários. A exposição da Lovable revelou código-fonte, não transações assinadas. Ambos foram tiros de aviso — o equivalente a uma divulgação de vulnerabilidade sem exploração, exceto pelo fato de que as vulnerabilidades estavam nas próprias relações de confiança, e não em qualquer base de código corrigível.

A questão para o próximo trimestre é se os construtores da Web3 precificam o aviso corretamente ou se esperam pelo evento de perda. A segurança de frontend — SRI, manifestos on-chain, simulação de transações, assinatura clara — tem a mesma configuração que as auditorias de contratos inteligentes tinham em 2017: tecnicamente disponíveis, culturalmente opcionais, prestes a serem reclassificadas como obviamente necessárias. A diferença é que o custo da lição é pago pelos usuários, não pelos protocolos.

As equipes que se moverem primeiro absorverão um trimestre de custos de engenharia. As equipes que esperarem absorverão o que quer que o primeiro dreno de classe Vercel de mais de US$ 50M + lhes custe em usuários, exposição regulatória e nos post-mortems que escreverão por meses.

A BlockEden.xyz opera infraestrutura de RPC e indexação de produção em mais de 12 + blockchains, com isolamento de ambiente, chaves de API com escopo definido e ferramentas de rotação projetadas para equipes que tratam a segurança de frontend como uma prioridade de primeira classe. Construa em uma infraestrutura que assume que a cadeia de suprimentos é hostil.

Fontes​

Share on Twitter