Graves fallos en el SDK de x402 permiten que APIs maliciosas vacíen las billeteras de agentes de IA

Los agentes de IA que utilizan el estándar x402 para micropagos automatizados se enfrentaban a un riesgo grave de ver cómo sus saldos completos de tokens eran drenados por APIs maliciosas. La firma de seguridad V12 reveló el 22 de octubre que los clientes predeterminados en los kits de desarrollo de software (SDK) de x402 carecían de límites de gasto, lo que permitía a servidores hostiles solicitar y recibir todos los fondos de la billetera.

La Fundación x402, que mantiene estas herramientas de código abierto, lanzó correcciones para estos fallos críticos el 18 de agosto, pero las actualizaciones no fueron marcadas como parches de seguridad en avisos públicos. Esto dejó a muchos desarrolladores inconscientes del peligro a pesar del potencial de pérdidas financieras significativas en flujos de trabajo agénticos.

Qué ocurrió

V12 identificó 25 fallos en la base de código de x402, tres de los cuales fueron calificados como críticos. La vulnerabilidad más peligrosa existía en la lógica del cliente predeterminado en los SDK de TypeScript, Python y Go. Cuando un servidor API respondía con un estado HTTP 402 Payment Required, podía listar opciones de pago con montos arbitrarios. El cliente predeterminado seleccionaba automáticamente la primera opción y firmaba un pago por ese monto sin verificar si excedía algún límite razonable.

Un atacante podría explotar esto realizando primero una solicitud pequeña y legítima para descubrir la dirección de la billetera del agente. Luego, podrían consultar el saldo de la billetera en la blockchain y crear una respuesta 402 posterior solicitando exactamente ese monto. Si la aplicación del agente no había establecido políticas de pago específicas, el SDK firmaría la transacción, permitiendo al atacante enviarla y drenar los fondos. Este riesgo estaba limitado a agentes configurados para firmar pagos automáticamente sin intervención humana.

Los otros dos fallos críticos afectaban partes específicas del ecosistema. Una vulnerabilidad en el facilitador de TypeScript para Solana permitía una "evasión completa del pago". El facilitador, que valida los pagos antes de que lleguen a la blockchain, fallaba en distinguir entre una transferencia de token y una aprobación de token. Un atacante podía enviar una instrucción de aprobación de token, que no mueve fondos pero otorga permiso de gasto, y el facilitador la aceptaría como un pago válido. El comerciante entregaría el recurso, pero ningún token cambiaría de manos, mientras que el facilitador pagaba la tarifa de transacción.

El tercer fallo involucraba la extensión Sign-In-With-X (SIWx). Los clientes firmaban mensajes de inicio de sesión para sitios basados en Ethereum sin verificar que el sitio web nombrado en el mensaje coincidiera con el sitio con el que estaban contactando actualmente. Un servidor malicioso podía retransmitir un mensaje de inicio de sesión de un sitio diferente y confiable, engañando al agente para que lo firmara. El atacante podía luego usar esta firma para iniciar sesión en el sitio confiable como el agente, obteniendo acceso no autorizado.

Cómo funciona

El estándar x402 habilita pagos máquina a máquina incrustando instrucciones de pago directamente en solicitudes HTTP. Cuando un servidor requiere un pago, devuelve un código de estado 402 junto con una lista de opciones de pago, cada una especificando un monto, tipo de token y destinatario. El cliente selecciona una opción, firma una prueba criptográfica de pago y reintenta la solicitud. Este proceso está diseñado para ser fluido para los agentes de IA que necesitan pagar llamadas a API de forma autónoma.

La vulnerabilidad surgió porque la implementación del cliente predeterminado priorizaba la conveniencia sobre la seguridad. Seleccionaba automáticamente la primera opción de pago presentada por el servidor y, antes de la actualización del 18 de agosto, no imponía ningún límite máximo de gasto. Este modelo de confianza asumía que los proveedores de API siempre solicitarían montos justos, una suposición que falla al tratar con actores maliciosos. La corrección introduce un tope predeterminado de $1 por transacción y restringe los pagos a stablecoins reconocidas como USDC, a menos que el developer configure explícitamente reglas diferentes.

En el caso del problema del facilitador de Solana, la causa fue la falta de validación estricta de instrucciones. Las transferencias de tokens y las aprobaciones de tokens son estructuras de datos similares en la blockchain de Solana, diferenciándose solo en su byte de instrucción inicial. El facilitador de TypeScript verificaba si la transacción llamaba a un programa de token válido, pero no verificaba el tipo específico de instrucción. Al añadir una comprobación del tipo de instrucción, el SDK actualizado asegura que solo las transferencias reales sean aceptadas como pago, impidiendo que los atacantes usen aprobaciones vacías para engañar al sistema.

Detalles clave

• V12 descubrió 25 fallos en el código de x402, con tres calificados como críticos y detallados en su informe.
• Los clientes x402 predeterminados para TypeScript, Python y Go no tenían límites de gasto antes de los lanzamientos del 18 de agosto.
• Un fallo específico de Solana en el facilitador de TypeScript permitía aceptar aprobaciones de token como pagos válidos, evitando las transferencias reales de fondos.
• La extensión SIWx permitía a los agentes firmar mensajes de inicio de sesión para sitios web que no estaban visitando actualmente, habilitando la toma de control de cuentas.
• Las correcciones se lanzaron el 18 de agosto, pero no se emitió ningún aviso público de seguridad, y registros de paquetes como npm y PyPI no marcaron las versiones anteriores como vulnerables.
• A partir del 23 de octubre, las últimas versiones seguras son la 2.28.0 para paquetes de TypeScript/Go y la 2.25.0 para Python.

Por qué importa

Para los desarrolladores que construyen agentes de IA que interactúan con APIs de pago, este incidente destaca los riesgos de automatizar transacciones financieras sin salvaguardas estrictas. Los flujos de trabajo agénticos a menudo operan con alta autonomía, lo que significa que una sola llamada a API no verificada puede resultar en pérdida financiera inmediata. La falta de avisos de seguridad explícitos significa que los equipos que dependen de escáneres de vulnerabilidades estándar como npm audit pueden permanecer inconscientes del riesgo, dejando sus sistemas de producción expuestos incluso después de que estén disponibles los parches.

Esto también subraya la importancia de validar entradas externas en sistemas de pago descentralizados. Cuando el dinero se mueve programáticamente, el código debe tratar cada solicitud de pago como potencialmente hostil. Los fallos de x402 demuestran cómo diferencias sutiles en las instrucciones de blockchain o la falta de comprobaciones de dominio en los flujos de inicio de sesión pueden llevar a un compromiso total del sistema. Los equipos deben ahora auditar las configuraciones de sus agentes para asegurarse de que no están usando SDKs obsoletos o desactivando controles esenciales de gasto.

Qué puedes hacer

• Actualiza todos los paquetes de x402 a las últimas versiones: 2.28.0 para TypeScript y Go, y 2.25.0 para Python.
• Verifica que tu aplicación no establezca spendControls: false, lo cual desactivaría el nuevo tope predeterminado de $1 y las restricciones de stablecoin.
• Si no puedes actualizar inmediatamente, registra una política de pago usando registerPolicy (TypeScript/Go) o register_policy (Python) para imponer un monto máximo por transacción.
• Para facilitadores de Solana, asegúrate de usar la versión 2.23.0 o posterior de @x402/svm para prevenir la evasión de pagos mediante aprobaciones de token.
• Actualiza @x402/extensions a la versión 2.23.0 o posterior para imponer la coincidencia de dominio en las firmas de inicio de sesión SIWx.
• Audita los permisos de la billetera de tu agente y considera usar billeteras dedicadas con saldos limitados para interacciones automatizadas con APIs.