x402 결제 프로토콜의 보안 위협

서버가 블록체인 확정 전에 낙관적으로(optimistically) 리소스를 먼저 내준다. 이후 체인 재구성(reorg)으로 결제 트랜잭션이 사라지면 — 서비스는 이미 제공됐는데 돈은 없어진다.

5.18%의 의미: 저자들이 통제한 로컬 실험·분석 모델에서 확인 없이 즉시 발급(k=0), 블록 시간 2초, 주입된 reorg 확률 5%, 지연 400ms 조건으로 요청 5,000건을 실행했을 때 약 259건에서 서비스 발급 후 결제가 사라졌다. 이는 실제 Base 메인넷의 자연 발생률이 아니라 인위적으로 reorg와 지연을 주입한 조건부 결과다. Base Sepolia에서는 grant–finality 사이의 시간적 틈만 확인했으며 실제 reorg 확률은 추정하지 않았다.

공격자가 노출된 결제 인가를 복사해 먼저 정산하고 nonce를 소비한다. 피해 지불자는 실제로 결제하지만 정상 facilitator의 후속 정산이 revert되어 서비스를 받지 못한다. 일반적인 외부 공격자는 결제금을 가져가지 못하며, 주된 목적은 서비스 거부·방해다.

nonce 선점이란: X-PAYMENT에 든 서명된 결제 인가가 특정 facilitator 또는 정산 호출자에게 묶여 있지 않으면, 헤더를 본 프록시·미들웨어·악성 서버가 그 인가를 복사해 먼저 제출할 수 있다. nonce는 일회용이므로 공격자가 먼저 소비하면 정상 facilitator의 후속 정산은 “이미 사용된 nonce”로 실패한다.

재현 결과: EIP-3009 실험에서는 노출된 인가를 익명화된 Base Sepolia 엔드포인트의 정상 경로보다 먼저 테스트넷 USDC transferWithAuthorization에 제출했다. 0.0001 testnet USDC가 결제되고 nonce가 소비된 뒤, 엔드포인트의 정상 정산은 실패해 클라이언트가 HTTP 402를 받았다. Permit2에서는 x402ExactPermit2Proxy를 대상으로 관계없는 공격자 EOA가 관찰한 서명으로 settle()을 먼저 호출했고, 이후 정상 호출은 같은 nonce가 이미 사용돼 revert됐다.

누가 손해·이득을 보나:

한 줄 요약: 외부 공격자가 돈을 훔치는 공격이라기보다 “피해자는 결제, 서비스는 0”으로 만드는 paid-but-denied형 griefing이다. 단, 공격자가 악성 수신자·판매자라면 결제금을 갖고 서비스를 주지 않는 직접적 부당이득도 가능하다. 방어하려면 서명에 승인된 facilitator를 포함하고 컨트랙트에서 실제 호출자를 검사해야 한다.

이 공격은 모든 x402 구현에서 성립하지 않는다. 동일한 X-PAYMENT를 여러 요청으로 보내더라도 서버가 각 요청의 온체인 정산 결과를 끝까지 기다린 뒤 성공한 요청에만 리소스를 반환하면, 첫 요청만 HTTP 200을 받고 나머지는 nonce 중복으로 HTTP 402가 된다.

성립하지 않는 경우 — settle-before-grant: 요청 A가 settle()을 await해 결제에 성공한 뒤 리소스를 받는다. 요청 B부터는 같은 nonce의 정산이 revert되고 서버가 HTTP 402를 반환하므로, 구매자는 추가 리소스를 받지 못한다. 사용자가 지적한 흐름이 바로 이 안전한 pessimistic 경로다.

성립하는 경우 — grant-before-settle: 서버가 서명 검증(verify)만 통과하면 HTTP 200·리소스를 먼저 flush하거나, 정산을 분리된 비동기 작업으로 보내고 응답을 즉시 끝낸다. 여러 동시 요청이 정산 결과가 나오기 전 모두 verify를 통과해 리소스를 받고, 이후 온체인에서는 첫 정산만 성공하고 나머지가 revert된다. 이때는 실패가 확인돼도 이미 보낸 응답을 회수할 수 없다.

논문에서 확인한 구현 차이: 여기서 SDK-A/B/C는 x402 프로토콜의 기능명이 아니라 논문이 비교한 구현체를 가리키는 별칭이다. SDK-A는 Coinbase TypeScript 구현, SDK-B는 서드파티 Python 구현, SDK-C는 서드파티 Rust 구현이다.

왜 문제가 생겼나: SDK-B의 streaming 경로는 온체인 settle_payment이 끝나기 전에 HTTP 응답을 완료했다. SDK-C의 optimistic 모드도 tokio::spawn으로 정산을 백그라운드 작업으로 분리해, “결제 정산이 성공했는지 확인하기 전에” 리소스를 먼저 발급했다. 같은 결제 헤더를 동시에 여러 번 보내면 각 요청이 먼저 verify를 통과하고 유료 리소스를 받아갈 수 있다. 이후 nonce 때문에 온체인 정산은 첫 1건만 성공하고 나머지는 실패하지만, 이미 전송한 리소스는 회수할 수 없다.

안전한 구현: 반대로 SDK-C의 pessimistic 모드는 정산을 동기적으로 완료한 뒤에만 응답했다. 따라서 같은 결제 헤더를 재전송해도 첫 요청만 200 OK와 리소스를 받고, 나머지는 nonce 중복으로 402를 받아 grant가 1개로 제한됐다. 실제 동시성 테스트에서는 같은 결제 헤더를 1,000개 요청에 사용했을 때, 취약한 경로에서 HTTP 200이 248개 발생했지만 온체인 결제는 1건뿐이었다. 즉 결제 1회로 유료 리소스 248개가 발급될 수 있었던 것이다.

누가 손해·이득을 보나:

한 줄 요약: settle() 성공을 await한 뒤 리소스를 반환하면 이 replay로 추가 리소스를 받을 수 없다. 취약점은 정산 완료보다 HTTP grant가 먼저 나가는 구현에서 생기며, 서버는 settle-before-grant를 지키거나 발급 전에 (pay_id, resource_id)를 원자적으로 claim해야 한다.

결제 헤더와 유료 응답이 일반 HTTP 프록시·CDN을 지나면서 결제 경계가 무너지는 공격이다. D1은 프록시가 헤더를 merge·truncate·재정규화해 서버가 클라이언트와 다른 결제 객체를 보게 만드는 경로이고, D2는 결제 후 응답을 공유 캐시에 저장해 다음 미지불 사용자가 공짜로 받는 경로다.

재현 결과와 경계: 기본 nginx·Caddy는 실험 구성에서 X-PAYMENT를 변조하지 않았지만, 커스텀 MitM이 중복 헤더를 주입하자 Node/Express는 1,000건 모두 마지막 값을 선택했다. 이는 parser ambiguity를 확인한 것이며 단독 결제 우회까지 증명한 결과는 아니다. 반면 캐시 유출은 nginx에서 미지불 요청 1,000건 모두 재현됐고, Cache-Control: no-store, private를 붙이자 0건으로 감소했다. Caddy는 두 조건 모두 캐싱하지 않았다.

누가 손해·이득을 보나:

한 줄 요약: 실증된 핵심 이득은 미지불 사용자가 유료 응답을 공짜로 받는 것이다. 유료 응답에는 no-store 또는 private를 강제하고, 프록시가 결제 헤더를 합치거나 재작성하지 못하게 해야 한다.

결제 전 디스커버리 단계에서 악성 판매자가 이름·설명·태그·신뢰 신호를 에이전트가 선호하도록 꾸미거나, 여러 Sybil 엔드포인트를 등록해 top-10 후보 목록을 점유한다. 지갑이나 정산 컨트랙트를 해킹하지 않고도 에이전트의 선택을 먼저 장악해 이후 결제 트래픽을 자신에게 보낸다.

재현 결과: 공개 x402 카탈로그를 이용한 통제된 디스커버리 모사에서 12개 카테고리·카테고리당 15개 질의·LLM 3종으로 총 2,160번의 선택을 측정했다. E1 메타데이터 조작은 공격 서버 하나만으로 MiniMax-M2.7 71.8%, GPT-5.3 69.4%, Sonnet 4.5 68.8%의 선택률을 보였다. E2 Sybil 공격은 서버를 1개에서 5개로 늘리자 3-LLM 평균 선택률이 27.5%에서 60.2%로 상승했다. 이는 실제 전체 x402 시장의 상시 공격 성공률이 아니라 top-10 선택 환경을 모사한 조건부 실험 결과다.

누가 손해·이득을 보나:

한 줄 요약: 공격자의 이득은 결제가 시작되기 전에 선택·매출 기회를 선점하는 것이다. 메타데이터 검증, 등록 비용·평판 기반 Sybil 저항성, 동일 사업자 노출 제한과 순위 다양화가 필요하다.