针对 x402 的五种攻击：当 AI 智能体付款时，跨层接缝在漏水

这是什么？

2026 年 5 月 12 日，来自俄亥俄州立大学、CSIRO 和曼彻斯特大学的研究者发布了 Five Attacks on x402 Agentic Payment Protocol（arXiv:2605.11781）。x402 是一个开放标准——由 Coinbase 主推——它重新启用了长期闲置的 HTTP 402 Payment Required 状态码，让软件智能体能够即时为 API 和内容付费：服务器以 402 回应请求，智能体附上一个 X-PAYMENT 头，由链下的*协调者（facilitator）*在链上验证并结算支付，随后交付资源。

论文的论点是结构性的。x402 把同步的 HTTP 授权与异步的区块链结算耦合在一起，而这道接缝——在传统 Web 支付和纯链上支付中都不存在——正是协议漏水之处。作者形式化了四条安全性质（授权可靠性、支付—服务对应、重放抵抗，以及协调者的 k-原子性），并证明 x402 在设计层面和已部署实现中都违反了它们。

工作原理

该工作刻画了四类共五种攻击。它们都不破解密码学，而是利用 HTTP 层与链之间的缝隙。

类别                          攻击            核心缺陷
----------------------------  --------------  -------------------------------------------
I  结算路径不一致             I-A Revert-grant  支付最终性确认前即授予资源
                              I-B 抢占          结算未绑定调用者，被观察者在真正协调者之前消费
II 重放 / 幂等性              II               可重用的 X-PAYMENT 载荷 -> 多次授予
III Web 层处理               III              付费内容的 CDN 缓存泄漏；代理 / 头部歧义
IV 服务器选择                IV               发现层把智能体引向恶意的付费端点

重放结果最为直观：当服务器在原子地记录支付身份之前就交付资源时，一份有效的 X-PAYMENT 载荷便可被重复使用，在一个生产端点上作者观察到单次支付换来 248 次授予。结算路径不一致使智能体能拿到最终从未付清的资源（即便协调者诚实，revert-grant 复现率高达 5.18%）。在发现层——任何支付开始之前——篡改服务器元数据可将智能体的选择偏向敌对端点，最高达 71.8%；五身份的 Sybil 洪泛达到 60.2%。

本文不复述任何可复现的载荷；权威参考是原论文。结果在一个超过 25,000 次支付请求、48 种配置（Hardhat/Anvil 与 Base Sepolia）外加四个生产端点的测试床上得到验证，并报告 95% 的 Wilson 置信区间。

为什么重要

智能体商务正从演示走向部署，而 x402 是其承重轨道之一。其攻击面之新在于信任边界横跨多个协议：X-PAYMENT 头表现得像一张持有者凭证，普通 HTTP 基础设施——代理、CDN、缓存——会乐于重放或存储它，而真正的钱要在数秒之后才在一条 Web 层无法回滚的链上结算。一处缓存配置失误就变成了支付绕过；一个缺失的幂等键就变成了规模化的免费服务。

一项跨实现审计在三个开源 SDK 和四个生产端点中发现了 11 个漏洞，包括某第三方 Python SDK 的”先授予后结算”行为、缺失资源标识符绑定、“发后即忘”式结算，以及缺失 Cache-Control 头。这不是理论模型，而是正在运行的代码。同一季度的相关工作——关于明文元数据泄漏的 Hardening x402 与 关于智能体商务中自主智能体安全的 SoK——指向同一方向：支付层如今已是智能体威胁模型中不可或缺的一环。

防御

这里没有单一补丁——它们是协议层和部署层的攻击类别。论文提出的缓解措施，以及任何运行 x402 者的标准加固：

1. 让结算与授予原子化（两阶段结算）。 不要在乐观执行下交付资源。把链上调用者、协调者、资源与访问决策绑定为单一原子对象，使一次回滚不会留下”已授予但未付款”的状态。

2. 强制幂等性并绑定资源。 在交付任何东西之前记录支付身份，并把每笔支付绑定到具体的资源标识符。这就堵住了导致”单次支付换 248 次授予”的重放/幂等性类别。

3. 在 Web 栈中把 X-PAYMENT 头当作持有者机密对待。 对付费响应显式设置 Cache-Control: no-store，审计 CDN 与代理行为以防缓存泄漏，并施加规范化编码，使头部/代理歧义无法被解析器差异所利用。

4. 加固智能体侧的发现机制。 不要让未经验证的元数据或注册数量驱动端点选择。在 Bazaar 式发现中使用信誉、签名注册和抗 Sybil 机制，使智能体无法在尚未付款时就被引向恶意付费服务器。

5. 最小化并保护支付元数据。 根据 Hardening x402，resource_url、description、reason 等字段以明文传向协调者——应在执行前过滤或脱敏个人数据。

6. 审计你的 SDK，而不只是规范。 11 个发现中大多是实现缺陷。请在你部署的 x402 库中测试”先授予后结算”、缺失幂等性和缺失缓存头。

状态

项目	参考	日期	备注
Five Attacks on x402 Agentic Payment Protocol	arXiv:2605.11781	2026-05-12	四类五种攻击；形式化模型 + 测试床
产生多次授予的重放	同一论文	2026-05-12	生产端点上单次支付换 248 次授予
发现层偏置	同一论文	2026-05-12	元数据篡改 71.8%；五身份 Sybil 洪泛 60.2%
SDK / 端点审计	同一论文	2026-05-12	3 个 SDK + 4 个端点中 11 个漏洞
负责任披露	HackerOne #3679163/#3679179/#3679220	2026	发表前已私下报告给 Coinbase
Hardening x402（元数据/PII）	arXiv:2604.11430	2026-04	明文元数据泄漏与执行前过滤

这条教训超越单一协议：当一个智能体的授权活在 HTTP 里、而它的钱活在链上时，唯有两者被原子地绑定，安全才能成立。 这些攻击所利用的一切，都藏在两者之间的缝隙里。