Cinco ataques a x402: cuando los agentes de IA pagan, las costuras entre capas gotean

¿Qué es esto?

El 12 de mayo de 2026, investigadores de la Ohio State University, el CSIRO y la Universidad de Mánchester publicaron Five Attacks on x402 Agentic Payment Protocol (arXiv:2605.11781). x402 es un estándar abierto — impulsado por Coinbase — que rescata el código de estado HTTP 402 Payment Required, durante mucho tiempo en desuso, para que los agentes de software paguen API y contenidos sobre la marcha: el servidor responde a una petición con un 402, el agente adjunta una cabecera X-PAYMENT, un facilitador fuera de cadena verifica y liquida el pago on-chain, y luego se entrega el recurso.

La tesis del artículo es estructural. x402 acopla una autorización HTTP síncrona con una liquidación blockchain asíncrona, y esa costura — ausente tanto en los pagos web clásicos como en los pagos puramente on-chain — es donde el protocolo gotea. Los autores formalizan cuatro propiedades de seguridad (solidez de la autorización, correspondencia pago–servicio, resistencia a la repetición y k-atomicidad del facilitador) y demuestran que x402 las viola tanto por diseño como en las implementaciones desplegadas.

Cómo funciona

El trabajo caracteriza cinco ataques en cuatro clases. Ninguno rompe la criptografía; explotan las brechas entre la capa HTTP y la cadena.

Clase                         Ataque          Fallo central
----------------------------  --------------  -------------------------------------------
I  Inconsistencia liquidación I-A Revert-grant  recurso concedido antes de la finalidad del pago
                              I-B Preempción    liquidación no ligada al llamante, consumida por
                                                un observador antes del facilitador real
II Repetición / idempotencia  II               carga X-PAYMENT reutilizable -> concesiones múltiples
III Manejo en capa web        III              fuga de caché CDN del contenido de pago; ambigüedad
                                                proxy / cabecera
IV Selección de servidor      IV               la capa de descubrimiento dirige al agente a un
                                                endpoint de pago malicioso

El resultado sobre la repetición es el más elocuente: cuando un servidor entrega el recurso antes de registrar atómicamente una identidad de pago, una carga X-PAYMENT válida puede reutilizarse, y en un endpoint en producción los autores observaron 248 concesiones a partir de un solo pago. Las inconsistencias de liquidación permiten que un agente reciba un recurso que nunca se paga finalmente (revert-grant reproducido hasta el 5,18 % incluso con facilitadores honestos). En la capa de descubrimiento — antes de cualquier pago — manipular los metadatos de un servidor sesgó la selección del agente hacia un endpoint adverso hasta en el 71,8 % de los casos, y una inundación Sybil de cinco identidades alcanzó el 60,2 %.

Aquí no se reproduce ninguna carga reproducible; la referencia canónica sigue siendo el artículo. Los resultados se validaron en un banco de pruebas de más de 25 000 peticiones de pago en 48 configuraciones (Hardhat/Anvil y Base Sepolia) más cuatro endpoints en producción, con intervalos de confianza de Wilson al 95 %.

Por qué importa

El comercio agéntico pasa de la demo al despliegue, y x402 es uno de sus raíles portantes. La superficie de ataque es novedosa porque la frontera de confianza atraviesa varios protocolos: la cabecera X-PAYMENT se comporta como una capacidad al portador que la infraestructura HTTP ordinaria — proxies, CDN, cachés — repetirá o almacenará con gusto, mientras que el dinero se liquida segundos después en una cadena que la capa web no puede revertir. Una mala configuración de caché se convierte en un eludir el pago; una clave de idempotencia ausente se convierte en servicio gratuito a escala.

Una auditoría multi-implementación de tres SDK de código abierto y cuatro endpoints en producción reveló 11 vulnerabilidades, incluido un comportamiento de «conceder antes de liquidar» en un SDK de Python de terceros, la falta de vinculación al identificador del recurso, una liquidación «fire-and-forget» y cabeceras Cache-Control ausentes. No es un modelo teórico: es código en producción. Los trabajos del mismo trimestre — Hardening x402 sobre la fuga de metadatos en texto plano y el SoK sobre agentes autónomos en el comercio agéntico — apuntan en la misma dirección: la capa de pago ya forma parte de pleno derecho del modelo de amenazas de los agentes.

Defensas

No hay un único parche — son clases a nivel de protocolo y de despliegue. Las mitigaciones que propone el artículo, y el endurecimiento estándar para quien opere x402:

1. Hacer la liquidación atómica con la concesión (liquidación en dos fases). No entregue el recurso bajo ejecución optimista. Vincule el llamante on-chain, el facilitador, el recurso y la decisión de acceso en un solo objeto atómico, de modo que un revert no deje un estado concedido-pero-impago.

2. Imponer idempotencia obligatoria con vinculación al recurso. Registre una identidad de pago antes de entregar nada, y vincule cada pago a un identificador de recurso concreto. Esto cierra la clase repetición/idempotencia que produjo 248 concesiones por un pago.

3. Tratar la cabecera X-PAYMENT como un secreto al portador en su stack web. Ponga un Cache-Control: no-store explícito en las respuestas de pago, audite el comportamiento de CDN y proxies contra fugas de caché, y aplique codificación canónica para que ninguna ambigüedad de cabecera/proxy sea explotable por diferencias entre parseadores.

4. Endurecer el descubrimiento del lado del agente. No deje que metadatos no verificados o el volumen de registros gobiernen la selección de endpoint. Use reputación, registros firmados y resistencia Sybil en el descubrimiento tipo Bazaar, para que un agente no pueda ser dirigido a un servidor de pago malicioso antes incluso de pagar.

5. Minimizar y proteger los metadatos de pago. Según Hardening x402, campos como resource_url, description y reason viajan en texto plano hacia el facilitador — filtre o redacte los datos personales antes de la ejecución.

6. Auditar su SDK, no solo la especificación. La mayoría de las 11 fallas eran errores de implementación. Pruebe el conceder-antes-de-liquidar, la idempotencia ausente y la falta de cabeceras de caché en la biblioteca x402 que despliegue.

Estado

Elemento	Referencia	Fecha	Notas
Five Attacks on x402 Agentic Payment Protocol	arXiv:2605.11781	2026-05-12	Cinco ataques / cuatro clases; modelo formal + banco de pruebas
Repetición que produce concesiones múltiples	Mismo artículo	2026-05-12	248 concesiones de un pago, endpoint en producción
Sesgo en la capa de descubrimiento	Mismo artículo	2026-05-12	71,8 % por manipulación de metadatos; 60,2 % flood Sybil de 5
Auditoría SDK / endpoints	Mismo artículo	2026-05-12	11 vulnerabilidades en 3 SDK + 4 endpoints
Divulgación responsable	HackerOne #3679163/#3679179/#3679220	2026	Reportado en privado a Coinbase antes de publicar
Hardening x402 (metadatos/PII)	arXiv:2604.11430	2026-04	Fuga de metadatos en texto plano y filtrado pre-ejecución

La lección trasciende un solo protocolo: cuando la autorización de un agente vive en HTTP pero su dinero vive en una cadena, la seguridad solo se sostiene si ambos están vinculados atómicamente. Todo lo que estos ataques explotan se aloja en la brecha entre ellos.