페이퍼 세미나 · 결제 프로토콜 보안

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

HTTP 402 상태 코드를 부활시켜 API·콘텐츠·AI 에이전트가 온체인으로 마이크로페이먼트를 주고받게 하는 x402 프로토콜. 동기식 HTTP 인가와 비동기식 블록체인 정산이 만나는 지점에서 새로운 교차 계층(cross-layer) 공격면이 열린다. 이를 각각 다른 각도에서 파고든 두 편의 논문을 정리했다.

Paper 1 · arXiv

Five Attacks on x402 Agentic Payment Protocol

Zelin Li, Qin Wang, Zhipeng Wang

arXiv:2605.11781 · 2026-05-12 · cs.CR

arxiv.org/abs/2605.11781
Paper 2 · USENIX Security '26

When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments

Qinying Wang, Yong Yang, Yuan Chen, Shouling Ji, Mathias Payer (EPFL · Zhejiang Univ.)

USENIX Security 2026 · 툴: x402scope

usenix.org · wang-qinying

01 x402 결제 워크플로

두 논문 모두 다음 3단계 흐름을 공격 분석의 기준으로 삼는다.

요청 & 견적 (Request & Quote)클라이언트가 리소스를 요청 → 서버가 402와 함께 결제 조건(금액·수신 주소·네트워크 등)을 응답.
결제 제시 (Payment Presentation)클라이언트가 결제 페이로드에 서명하고, X-PAYMENT 헤더를 붙여 요청을 재전송.
검증·정산·발급 (Verify, Settle & Grant)서버가 facilitator에게 검증 요청 → facilitator가 온체인 제출 → 정산 확인 후 서버가 리소스를 발급.
x402 워크플로와 공격 지점
Figure 1 (Paper 1). x402 워크플로와 다섯 공격의 삽입 지점. 파란 선이 정상 흐름(① 요청·402 → ② X-PAYMENT 재전송 → ③ verify/settle → ④ 200 OK + Grant)이고, 빨간 상자가 각 단계에서 끼어드는 공격 I-A/I-B·II·III·IV의 위치를 보여준다.

02 Paper 1 — 다섯 가지 공격

Five Attacks on x402 Agentic Payment Protocol · Zelin Li, Qin Wang, Zhipeng Wang

이 논문은 x402를 형식적으로(formally) 분석한 뒤, 설계·구현 양쪽에서 실증한다. 다섯 공격은 인가(authorization)·바인딩(binding)·재전송 방어(replay protection)·웹 계층 처리(web-layer)의 약점을 각각 겨냥하며, 결과적으로 돈은 안 냈는데 서비스는 받거나(unpaid service), 반대로 돈은 냈는데 서비스는 거부당하는(paid-but-denied) 두 가지 결말로 이어진다.

위협 모델 (Threat Model)

확률적 다항시간(PPT) 공격자를 가정하며, 능력별로 나눈다: 네트워크 계층 공격자(메시지 지연·재정렬), 손상된 클라이언트, 비잔틴 facilitator, 유한성(finality) 범위를 지키는 블록체인 조작자, honest-but-curious 서버. 암호 프리미티브 자체는 안전하다고 전제한다.

공격 5종

I-ARevert-grant under optimistic execution유한성 / 정산

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

실측 5.18%지연이 있는 낙관적 실행 조건에서 revert-grant 발생 확률

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

I-BUnauthorized settlement preemption인가 / 바인딩

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

확인됨Base Sepolia의 라이브 EIP-3009 경로와 통제된 Permit2 PoC에서 nonce 선점 재현

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됐다.

누가 손해·이득을 보나:

피해 지불자 — 직접 손해서명에 지정된 금액이 실제로 빠져나가지만 HTTP 402를 받고 서비스는 받지 못한다.
외부 관찰자 공격자 — 직접 수익 없음수신자·금액을 바꿀 수 없어 결제금을 가져가지 못하고 선점 트랜잭션의 가스비도 낸다. 경쟁자 방해·평판 훼손·협박 같은 간접 이득이 목적이다.
정상 판매자 — 결제 수령, 운영 손실서명에 지정된 수신자로서 돈은 받을 수 있지만 결제와 요청을 연결하지 못해 환불·고객지원·평판 비용이 발생한다.
악성 판매자·서버 — 직접 이득 가능자신이 수신자이면서 의도적으로 선점한다면 결제금을 보유한 채 서비스를 거부할 수 있다.

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

Attack I-A와 I-B 시퀀스 다이어그램
Figure 2 (Paper 1). Attack I. 위(I-A): 서버가 온체인 확정 전에 리소스를 발급 → 이후 reorg로 결제가 사라져도 서비스는 이미 나감(non-atomicity, k-depth). 아래(I-B): 공격자가 X-PAYMENT를 엿듣고 settle(PP)를 프론트런해 선점 → 정당한 정산은 revert되어 지불자만 손해.
IIReplay / Idempotency across HTTP–Chain boundary재전송 방어

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

취약 경로: 1회 결제 → 248 grantsgrant-before-settle 동작을 보인 라이브 엔드포인트의 가장 강한 재현 라운드

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

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

논문에서 확인한 구현 차이: SDK-B의 streaming 경로는 settle_payment 전에 응답을 완료했고, SDK-C의 optimistic 모드는 정산을 tokio::spawn으로 분리해 중복 grant가 발생했다. 반대로 SDK-C의 pessimistic 모드는 정산을 동기적으로 완료한 후 응답해 같은 재전송에서 grant가 1개로 제한됐다. 라이브 테스트에서는 한 결제 헤더를 1,000개 동시 요청으로 보냈고, 가장 강한 라운드에서 HTTP 200이 248개였지만 온체인 결제는 1건뿐이었다.

누가 손해·이득을 보나:

재전송 공격자 — 직접 이득한 번의 결제 비용으로 여러 API 결과·파일·연산 서비스를 받아 결제 대비 가치를 증폭시킨다.
판매자 — 직접 손해결제는 한 번만 받지만 서버 비용과 유료 리소스는 여러 번 제공해 매출·연산 자원을 잃는다.
블록체인·토큰 — 정상 동작nonce가 재결제를 막아 온체인 이중 지불은 발생하지 않는다. 실패 지점은 HTTP 발급 계층이다.
정상 클라이언트 — 우발적 유발 가능네트워크 재시도나 타임아웃 복구가 중복 요청을 만들 수 있어 공격자가 없어도 판매자 손실이 발생할 수 있다.

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

Attack II 재전송 시퀀스 다이어그램
Figure 3 (Paper 1). Attack II의 취약한 grant-before-settle 경로. 한 번 결제한 X-PAYMENT를 n번 재전송했을 때, 서버가 정산 완료를 기다리지 않고 verify만으로 먼저 응답하면 Grant(n)이 나간다. 온체인 nonce 검사는 첫 정산만 허용하지만 이미 보낸 리소스는 회수할 수 없다. 반대로 settle 결과를 await한 뒤 응답하는 pessimistic 경로에서는 중복 요청이 402로 끝나 grant는 1개뿐이다.
IIIHTTP / Proxy-Level Confusion & Header Manipulation웹 계층

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

1,000 / 1,000 유출Cache-Control이 없는 nginx 캐시 실험의 미지불 요청

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

누가 손해·이득을 보나:

미지불 요청자 — 직접 이득다른 사람이 만든 유료 응답을 cache hit으로 받아 결제 없이 보호 콘텐츠를 소비한다.
원래 지불자 — 콘텐츠 노출 위험자신이 결제해 생성한 결과가 다른 사용자에게 전달될 수 있다. 사용자별 응답이라면 민감 정보 노출로 확대될 수 있다.
판매자 — 매출·기밀성 손실첫 결제만 받고 이후 캐시 요청에는 과금하지 못하며, 유료 콘텐츠의 접근 통제도 잃는다.
프록시·CDN — 악성일 필요 없음공유 캐시 기본값이나 헤더 처리 차이만으로도 발생할 수 있는 배포·설정 취약점이다.

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

Attack III 프록시 헤더 변조 및 캐시 유출
Figure 4 (Paper 1). Attack III. D1 헤더 변조: 프록시가 X-PAYMENT를 normalize/merge/truncate 하면서 PP → PP'로 바뀌어 서버가 402/파싱 불일치를 반환. D2 캐시 유출: no-store가 없으면 유료 응답이 프록시에 캐시돼, 미지불 Client B가 cache hit으로 콘텐츠를 공짜로 받는다.
IVServer-Selection Attacks디스커버리

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

71.8% / 60.2%단일 조작 listing의 최대 모델 선택률 / Sybil 5개 사용 시 3-LLM 평균

재현 결과: 공개 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 listing에 shortlist 자리를 빼앗겨 검색 노출·호출·매출을 잃는다.
마켓·레지스트리 — 신뢰 손실등록 비용이 낮고 순위 다양성이 없으면 조작 listing이 누적돼 디스커버리 품질 전체가 악화된다.

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

Attack IV 디스커버리 조작과 Sybil flooding
Figure 5 (Paper 1). Attack IV. 에이전트가 Bazaar 디렉터리에서 서버를 검색(top-k 선택)할 때, E1은 악성 서버 R*에 조작된 메타데이터를 등록해 상위에 올리고, E2는 다수의 Sybil 서버(R1*·R2*·R3*)를 등록해 목록을 도배함으로써 정직한 서버 Rh를 밀어낸다.

완화책 (Mitigations)

M1 정규화된 typed 인코딩 + nonce/timestamp 검증
M2 정산 호출자가 지불자가 승인한 facilitator와 일치하도록 강제
M3 서비스 발급 전에 결제–리소스 쌍을 원자적으로 claim
M4 2단계 정산(reserve-then-release) 또는 k-confirmation 게이팅
M5 유료 응답에 no-store·private Cache-Control 부여
M6 디스커버리 계층의 메타데이터 검증 + Sybil 저항성

평가 (Evaluation)

Attack I-A revert-grant 실측 결과
Figure 6 (Paper 1). Attack I-A 실측. (a) reorg 확률·지연이 커질수록 revert-grant 확률(RGP)이 증가(최대 5.18%, 비잔틴 facilitator면 100%). (b) 확인 깊이 k를 늘리면 RGP는 낮아지지만 grant까지 지연(Tgf)이 커지는 안전성-즉시성 트레이드오프.
Attack IV 카테고리별 선택률
Figure 7 (Paper 1). Attack IV 선택률(12개 카테고리, 경쟁 서버 밀도 순). 빨간 점선은 E1 메타데이터 조작(3-LLM 평균), 막대는 E2 Sybil flooding(r=1·3·5). 경쟁이 적은 카테고리일수록 소수 Sybil로도 쉽게 상위 선점.

03 Paper 2 — x402scope 실측 연구

When HTTP 402 Meets the Blockchain · Qinying Wang 외 (EPFL · Zhejiang University) · USENIX Security 2026

참고
USENIX 발표 페이지와 저자 홈페이지에 아직 전체 초록이 공개되지 않았다. 아래 내용은 공개된 제목·저자 정보와 오픈소스 저장소 HexHive/x402scope의 README를 근거로 정리한 것이며, 정식 초록 공개 시 갱신 필요.

이 논문은 Paper 1이 "형식 분석 + 재현 테스트"에 무게를 뒀다면, 실제 라이브 facilitator와 온체인 데이터에 대한 대규모 실측(measurement)에 방점을 둔다. 도구 x402scope는 두 축으로 구성된다.

겨냥한 공격 범주

특징은 EVM(Base)뿐 아니라 Solana까지 실측 범위에 넣었다는 점, 그리고 데이터 파이프라인·규칙 위반 탐지기를 재현 가능한 프레임워크로 공개했다는 점이다. 코드: github.com/HexHive/x402scope

04 두 논문 비교

Paper 1 · Five Attacks (arXiv)Paper 2 · x402scope (USENIX)
주된 방법론형식적 분석 + 재현형 테스트베드라이브 facilitator·온체인 대규모 실측
구조화공격 5종을 계층별로 분류·명명규칙 위반 탐지 + 통계적 계측
체인 범위EVM 중심 (Hardhat, Base Sepolia)EVM(Base) + Solana
대표 공격revert-grant, 정산 선점, replay, 캐시 유출, server-selectionfree-shopping, ERC-1271/6492, Solana 토큰계정 악용
산출물공격 분류 + 완화책 M1–M6 + SDK 3종 감사오픈소스 도구 x402scope + 실측 데이터셋
공통점HTTP–체인 경계의 타이밍/바인딩 결함이 "무료 서비스" 또는 "지불 후 거부"로 이어진다는 문제의식 공유

요약하면 Paper 1은 "무엇이 왜 깨지는가"를 체계적으로 분류·증명하고, Paper 2는 "실제 세상에서 얼마나, 어디서 깨지고 있는가"를 실측한다. 세미나에서는 두 논문을 이론적 분류 ↔ 경험적 계측의 상보 관계로 배치하면 이야기가 자연스럽다.

05 세미나 토론 포인트

Q1. 낙관적 발급(optimistic grant)은 UX(빠른 응답)와 안전성의 트레이드오프다. k-confirmation 게이팅을 걸면 에이전트 결제의 "즉시성"이 사라지는데, 실무에서 어느 지점이 균형점일까?
Q2. Replay 공격(1건 → 248 grant)은 결국 서버 측 멱등성 부재가 원인이다. 이건 x402 프로토콜의 결함인가, 아니면 구현/운영의 문제인가? 프로토콜이 강제해야 하는가?
Q3. Server-selection / Sybil 공격은 결제가 시작되기도 전 단계다. 디스커버리 계층의 신뢰를 어떻게 부트스트랩할 것인가? (평판? 스테이킹? 온체인 신원?)
Q4. Paper 2가 Solana를 포함시킨 이유 — EVM과 Solana에서 x402 위협 모델이 어떻게 달라지는가? (계정 모델, rent, ATA 등)
Q5. 두 논문의 완화책이 모두 적용되면 x402는 "안전한 에이전트 결제 표준"이 될 수 있는가, 아니면 교차 계층 결합 자체가 근본적 한계인가?