Uma falha crítica no SDK x402 podia fazer agentes de IA assinarem um pagamento equivalente ao saldo inteiro de um token para uma API mal-intencionada. O alerta foi feito pela empresa de segurança V12 em 22 de outubro, segundo o The Hacker News. O risco não valia para qualquer um: atingia agentes que assinavam pagamentos de forma automática, em aplicações que não tinham nenhum limite de gasto configurado.
Vale entender o que é o x402. Trata-se de um padrão aberto que permite a um software, incluindo agentes de IA, pagar por uma chamada de API dentro da própria requisição web, sem que uma pessoa precise aprovar cada cobrança. Funciona assim: o servidor responde com o código HTTP 402, que indica pagamento necessário, e mostra as opções de pagamento. Cada uma traz valor, token e destinatário. O cliente escolhe, assina e repete o pedido.
É prático. Mas precisa de freio. E era isso que faltava, de acordo com a reportagem: o cliente padrão pegava a primeira opção da lista e, antes da correção, não impunha nenhum teto de valor. Segundo a V12, uma API hostil poderia transformar um pedido comum de dados numa cobrança do saldo total da carteira. Um pagamento pequeno feito antes poderia até revelar o endereço da carteira, permitindo ao servidor consultar o saldo antes de cobrar.
Esse foi um dos 25 problemas que a V12 encontrou no código do x402, e um dos três que a empresa classificou como críticos. Os outros dois também merecem atenção, e vamos a eles com calma.
As outras duas falhas críticas
A segunda falha envolvia a rede Solana e afetava apenas o SDK em TypeScript. No x402, existe um serviço chamado facilitador, que confere os pagamentos e os envia para a blockchain. Na Solana, ele também arca com a taxa da transação. Segundo o veículo, o código do facilitador em TypeScript não verificava o tipo de instrução recebida. Com isso, uma simples autorização de uso de tokens, que não transfere nada, podia ser aceita como pagamento válido.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
Na prática, um comerciante poderia entregar um conteúdo pago sem receber nada em troca. A V12 descreveu o problema como um desvio completo do pagamento. Um detalhe importante: isso foi demonstrado em teste local, sem transação real na rede. As versões em Python e Go já faziam essa checagem.
A terceira falha estava na extensão de login SIWx, que permite ao agente se identificar assinando uma mensagem curta com a carteira. O cliente automatizado assinava essas mensagens sem conferir se o site citado nelas era o mesmo que tinha sido acessado. Assim, de acordo com a V12, um servidor malicioso poderia repassar ao agente uma mensagem de login de outro site e usar a assinatura para entrar lá como se fosse a carteira do agente.
A notícia boa é que as três falhas críticas já tinham sido corrigidas nas versões publicadas em 18 de agosto. Segundo o The Hacker News, nem a V12 nem a x402 Foundation relataram publicamente ataques usando essas brechas. O padrão foi criado pela Coinbase e repassado neste ano à fundação, um projeto da Linux Foundation que tem Visa e Mastercard entre os membros.
O detalhe que preocupa quem desenvolve
Se a correção saiu em agosto, por que o tema só apareceu agora? Porque o aviso praticamente não circulou. A fundação não publicou alerta de segurança sobre as três falhas. Os registros de mudança das novas versões mencionam as correções, mas sem identificá-las como questões de segurança.
E tem outro ponto. Segundo o The Hacker News, em 23 de outubro o npm audit não apontava alertas para as últimas versões em TypeScript anteriores às correções. No PyPI, a última versão em Python antes do conserto também aparecia sem vulnerabilidades listadas.
Ou seja, quem depende só dessas ferramentas para saber a hora de atualizar não recebe sinal nenhum. O projeto pode seguir rodando numa versão vulnerável sem que ninguém da equipe perceba.
O que muda para quem automatiza pagamentos no Brasil
O primeiro passo é atualizar. Em TypeScript, a correção do limite de gasto chega com os pacotes @x402/fetch ou @x402/axios na versão 2.23.0 ou superior. Quem usa login via SIWx também precisa do @x402/extensions a partir da 2.23.0. Já quem verifica pagamentos na Solana precisa do @x402/svm na mesma versão ou acima.
Ir direto para a versão mais recente traz ainda correções posteriores. Segundo o veículo, isso inclui o conserto de outro desvio de pagamento, corrigido em setembro no @x402/core 2.27.0. Em 23 de outubro, as versões mais novas eram a 2.28.0 para os pacotes em TypeScript e para o módulo em Go, e a 2.25.0 para o pacote em Python.
Depois da atualização, de acordo com a reportagem, cada pagamento passa a ter teto de 1 dólar, e o cliente só aceita stablecoins em dólar reconhecidas pelo SDK, como a USDC. Isso vale até a aplicação definir os próprios controles.
Aqui mora uma pegadinha. Se o código desligar os controles de gasto, toda essa proteção some de uma vez. Por isso, vale revisar a configuração com atenção, principalmente em projetos herdados ou montados às pressas.
E quem ainda não consegue atualizar? Dá para registrar uma política de pagamento que descarte qualquer opção acima de um valor definido. Segundo o veículo, as versões antigas já aceitam esse recurso em TypeScript, Go e Python.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
A lição maior sobre segurança em agentes de IA
O caso vai além de um SDK específico. Dar a um agente o poder de pagar é, na prática, entregar uma carteira a ele. As recomendações da V12, relatadas pelo veículo, servem para qualquer projeto parecido:
- definir um orçamento por pagamento e outro para o gasto total;
- limitar quais tokens, redes e destinatários o agente pode pagar;
- conferir se o site citado numa mensagem de login é o mesmo que o agente acessou antes de assinar.
A ideia conversa com o que já discutimos sobre segurança em camadas para agentes autônomos: nenhuma proteção sozinha dá conta, e o mais seguro é combinar limites, permissões e verificações.
Para quem testa pagamentos com agentes de IA em produtos digitais, campanhas de marketing ou rotinas de operação, o recado é claro. A automação de pagamentos não é um detalhe para resolver depois. Imagine uma pequena empresa que coloca um agente para comprar dados de uma API, deixa a assinatura automática ligada e não configura teto de gasto. Com um cliente vulnerável, um único pedido malicioso poderia levar o saldo de um token da carteira. É o tipo de descuido que ajuda a explicar por que a automação com IA falha em tantos negócios.
Até agora, não há registro público de ataques explorando essas falhas. Mesmo assim, revisar versões e limites hoje custa bem menos do que descobrir o problema pelo extrato da carteira. Quem quiser se aprofundar no tema encontra mais contexto no nosso conteúdo sobre autonomia, segurança e transparência em agentes de IA.
