Agentes de IA que pagam chamadas de API com os kits de desenvolvimento de software (SDKs) do x402 podem assinar um pagamento pelo saldo total de um token compatível, caso uma API maliciosa solicite isso, afirmou a empresa de segurança V12 em 22 de outubro.
A causa estava no cliente padrão dos SDKs, que não definia nenhum limite de gastos até que as versões lançadas em 18 de agosto acrescentassem esse controle. O risco se limitava a agentes que assinavam pagamentos automaticamente e cujos aplicativos não definiam limites.
A ausência de limite é uma das 25 falhas que a V12 encontrou no código do x402 e uma das três que a empresa classificou como críticas e descreveu em detalhes. A Fundação x402, responsável pela manutenção dos SDKs, já havia corrigido as três falhas críticas nas versões de 18 de agosto.
Outra dessas falhas permitia que um facilitador, serviço que verifica os pagamentos x402, aceitasse como pagamento válido uma transação na Solana que não movimentava tokens. Entre os SDKs do x402, apenas o de TypeScript tinha essa falha. A terceira permitia que um servidor malicioso levasse um agente a assinar uma mensagem de login destinada a outro site.
A V12 identificou as falhas por meio da revisão do código e da execução de testes locais. Nem a V12 nem a Fundação x402 informaram publicamente qualquer ataque que tenha explorado esses problemas.
A fundação não publicou nenhum aviso de segurança para as três falhas, e seus registros de alterações listam as correções sem as identificar como correções de segurança. Até 23 de outubro, a ferramenta npm audit não apresentava alertas para as últimas versões do TypeScript anteriores às correções, e o PyPI não listava vulnerabilidades para a última versão do Python anterior a elas, segundo levantamento do The Hacker News. Desenvolvedores que dependem dessas verificações, portanto, não recebem nenhum alerta para atualizar.
A Coinbase criou o x402 e o transferiu este ano para a Fundação x402, projeto da Linux Foundation cujos membros incluem Visa e Mastercard. A Coinbase ocupa a cadeira de maior hierarquia no comitê técnico diretor da fundação.
Nenhum limite de gastos no cliente padrão
O x402 é um padrão aberto que permite que softwares, incluindo agentes de IA, paguem uma chamada de interface de programação de aplicações (API) dentro da própria requisição web, sem que uma pessoa precise aprovar cada pagamento.
Quando um servidor quer ser pago, responde com o código de status HTTP 402 (Payment Required, ou pagamento necessário) e lista suas opções de pagamento, cada uma com um valor, um token e um destinatário. O cliente escolhe uma delas, assina o pagamento e envia a requisição novamente.
O cliente padrão escolhia a primeira opção da lista e, antes da correção, não definia nenhum limite de valor.
Uma API hostil poderia usar essa característica para transformar uma simples requisição de dados em uma solicitação do saldo total de um token compatível na carteira, afirmou a V12. Um pagamento anterior de valor baixo poderia revelar o endereço da carteira, permitindo que o servidor consultasse o saldo antes.
Com um assinador automático e sem política de pagamento definida pelo aplicativo, o cliente poderia assinar um pagamento por esse valor. Em um token que aceita transferências assinadas, o invasor poderia então enviar o pagamento assinado e recolher os fundos.
As versões de 18 de agosto acrescentaram controles de gastos aos clientes para TypeScript, Python e Go. Por padrão, agora eles limitam cada pagamento a US$ 1 e permitem apenas stablecoins (criptomoedas atreladas ao dólar) americanas reconhecidas pelo SDK, como a USDC.
Aprovações de tokens aceitas como pagamentos na Solana
No x402, o servidor de um comerciante depende de um facilitador para verificar cada pagamento e enviá-lo à blockchain. Na Solana, o facilitador também paga a taxa da transação.
O código do facilitador em TypeScript para a Solana verificava se o pagamento chamava um programa de token permitido e, em seguida, o lia como uma transferência, sem checar o tipo de instrução. Uma aprovação de token, que permite que outra conta gaste tokens posteriormente, mas não movimenta nenhum token por si só, difere de uma transferência apenas no primeiro byte.
No teste local da V12, o facilitador aceitou essa aprovação como pagamento válido. O teste não enviou nenhuma transação real.
Um comerciante que dependesse do facilitador poderia, portanto, entregar um recurso pago sem receber nenhum token, afirmou a V12, que classificou a situação como «uma bypass completa de pagamento». O invasor precisava de uma conta de token, mas não de saldo, e o facilitador pagava a taxa da transação a cada vez.
Os SDKs de Python e Go já verificavam o tipo de instrução. As versões de 18 de agosto acrescentaram a mesma verificação ao código em TypeScript.
Todas as versões publicadas do @x402/svm, de 2.0.0 a 2.22.0, não têm essa verificação, e todas as versões a partir de 2.23.0 a têm, segundo levantamento do The Hacker News feito a partir da busca nos pacotes publicados.
Logins assinados para outros sites
O x402 também tem uma extensão de login chamada Sign-In-With-X (SIWx). Ela permite que um agente faça login assinando uma mensagem curta com sua carteira, por exemplo, para comprovar um pagamento anterior sem precisar pagar novamente. Na Ethereum, a mensagem indica o site, o endereço da carteira e um código de uso único.
O cliente automatizado assinava essas mensagens sem verificar se o site citado nelas era o mesmo com o qual ele estava se comunicando.
Um servidor malicioso poderia obter uma mensagem de login nova de outro site, repassá-la ao agente e usar a assinatura para entrar naquele site como a carteira do agente, afirmou a V12. Isso funcionaria em qualquer lugar em que o outro site aceitasse a mensagem repassada, e o invasor teria o acesso que o login permitisse.
As versões de 18 de agosto fazem com que os clientes para TypeScript, Python e Go recusem assinar, a menos que o site citado na mensagem corresponda ao site que enviou a resposta 402. O projeto também alterou a especificação do SIWx, que agora determina que o cliente deve recusar a assinatura quando os dois não coincidirem.
O código em TypeScript que chama diretamente o createSIWxPayload agora precisa informar a URL da resposta 402, após eventuais redirecionamentos. Os wrappers @x402/fetch e @x402/axios repassam essa informação por conta própria.
O que atualizar
Atualizar para as versões mais recentes também traz correções posteriores, incluindo uma para outra falha de bypass de pagamento, presente no @x402/core 2.27.0, corrigida em setembro. Até 23 de outubro, as versões mais recentes são a 2.28.0 para @x402/core, @x402/svm, @x402/extensions, @x402/fetch e @x402/axios, a v2.28.0 para o módulo Go e a 2.25.0 para o pacote Python.
No TypeScript, os clientes recebem a correção de gastos ao atualizar @x402/fetch ou @x402/axios para a versão 2.23.0 ou posterior, o que também traz o @x402/core correspondente. Aplicativos que usam SIWx precisam do @x402/extensions 2.23.0 ou posterior, que contém a verificação de login. Facilitadores que verificam pagamentos na Solana precisam do @x402/svm 2.23.0 ou posterior.
Após a atualização, os clientes existentes ficam limitados a US$ 1 por pagamento e a stablecoins reconhecidas, a menos que o aplicativo defina seus próprios controles de gastos. Aplicativos que passam spendControls: false desativam todos esses controles.
Equipes que ainda não podem atualizar podem registrar uma política de pagamento que descarte qualquer opção acima de um valor definido. Os clientes mais antigos aceitam essa solução com registerPolicy em TypeScript e Go e com register_policy em Python, versão que também oferece uma política max_amount pronta para uso.
A V12 recomenda que os clientes verifiquem se a mensagem de login do SIWx identifica o site que contataram antes de assinar, que definam orçamentos para cada pagamento e no total, e que limitem quais tokens, redes e destinatários aceitarão pagar.
