XRP 공급 상한을 깰 수 있던 버그, 수정은 투표 없이 들어갔다

웨일로그 편집팀

XRP 레저 개발진이 2026년 10월 9일 공개한 취약점 보고서에는 결제 엔진이 금액을 더할 때 64비트 정수의 넘침을 검사하지 않아 정해진 공급량을 넘는 XRP가 생길 수 있었다는 내용이 담겼습니다. 2015년부터 코드에 남아 있던 문제이고, 보고서는 어떤 공개 네트워크에서도 악용된 증거는 찾지 못했다고 밝혔습니다. 이 글은 xrpl.org의 보고서 원문을 직접 열어 확인한 내용을 7개 질문으로 정리한 것이며, 모든 서술은 2026년 10월 12일 오전(KST) 기준입니다.

📌 오늘의 헤드라인 — 2026년 10월 12일 아침

이 블록은 발행일인 2026년 10월 12일 아침 기준 스냅샷입니다. 이후 시세와 상황은 달라지므로, 지난 글을 보고 계신 경우 아래 수치는 현재 값이 아닙니다. 본문 내용은 발행일 기준으로 작성됐습니다.

주말과 밤사이(한국시간 10월 9일~12일 아침) 들어온 소식을 정리했습니다.

  • XRP 레저가 xrpld 3.4.1에서 고친 취약점 2건의 공개 보고서를 10월 9일 올렸습니다(xrpl.org 개발자 블로그). 같은 날 두 번째 버그의 수정안 fixBatchV1_2가 메인넷에서 활성화됐다고 보고서에 적혀 있습니다.
  • 비트코인은 10월 12일 오전 9시 35분(KST) 기준 24시간 전 대비 1.02% 오른 8만 3,748.01달러였습니다(코인마켓캡). 같은 조회에서 이더리움은 1.46% 오른 2,539.15달러, XRP는 오전 9시 34분 기준 0.66% 오른 1.4087달러였습니다. 세 종목 모두 7일 기준으로는 각각 2.91%, 6.64%, 6.98% 낮은 수준입니다.
  • 전체 암호화폐 시가총액은 2조 8,312억 달러, 비트코인 점유율은 59.42%였습니다(코인마켓캡, 10월 12일 오전 9시 35분 KST 기준).
  • 24시간 레버리지 청산 규모는 상위 20개 종목 기준 9,585만 달러로 집계됐고, 이 가운데 숏 포지션이 81.54%였습니다(코인글래스 집계, 토큰포스트 10월 12일 오전 4시 56분 기사). 집계 사이트 수치이므로 1차 자료는 아닙니다.
  • IMF가 토큰화 주식에 대한 수요는 확인되지만 시장은 여전히 변동성이 크고 유동성이 얕다는 분석을 내놨다는 보도가 있었습니다(코인데스크 10월 11일 기사). 원문 보고서는 이 글 작성 시점에 확인하지 못했습니다.

Q1. 이번에 XRP 레저에서 발견된 버그는 무엇인가요?

결제 엔진의 오버플로(overflow) 문제입니다. 오버플로는 컴퓨터가 숫자를 담아 두는 칸의 크기가 정해져 있어서, 그 칸에 들어가지 않는 큰 수를 넣으면 값이 한 바퀴 돌아 엉뚱하게 작은 수가 되는 현상입니다. 자동차 주행거리계가 999,999km를 넘으면 0으로 돌아가는 것과 같은 일이 계산 중에 벌어지는 셈입니다.

보고서가 설명하는 경로는 이렇습니다. XRP 레저에는 호가창(order book)이 있어서, 한 번의 결제가 여러 판매 주문(오퍼)을 차례로 소비할 수 있습니다. 결제 엔진은 이때 매수자가 내야 할 총액을 64비트 정수로 단순히 더하면서 넘침 검사를 하지 않았습니다. 그래서 보고서의 표현대로 “호가창 맨 아래에 놓이도록 가격을 매긴 오퍼 수백 개”를 미리 깔아 두면 합계가 한계를 넘기고, 그 값이 작은 수로 되돌아갑니다.

문제는 그 뒤입니다. 오퍼를 올린 판매자들에게는 각자 전액이 지급되는데, 매수자에게 청구되는 금액은 되돌아간 작은 값입니다. 차액만큼 XRP가 어디서 나온 것도 아닌 상태로 생겨납니다. 보고서는 이런 일을 막기 위해 있던 안전장치 두 개가 이 경로를 잡아내지 못했다고 적었습니다.

Q2. 실제로 XRP가 새로 발행된 적이 있나요?

보고서는 “이 문제가 어떤 공개 네트워크에서도 악용된 증거를 찾지 못했다(We have found no evidence that this issue was exploited on any public network)“고 적었습니다. 이 문제로 자금 손실이나 개인키 유출이 발생하지 않았다는 확인도 함께 들어 있습니다.

다만 이 문장을 읽을 때 구분해 둘 것이 있습니다. 이것은 재단 측의 조사 결과 서술이고, 저희가 체인 전체를 전수 검증해 확인한 것이 아닙니다. 외부에서 같은 결론을 독립적으로 검증했다는 발표는 이 글 작성 시점까지 확인되지 않았습니다.

참고로 저희가 10월 12일 오전 9시 36분(KST, 원장 마감 시각 기준)에 XRPL 공개 노드(xrplcluster.com)에 ledger 명령을 보내 받은 원장 107,594,916번의 total_coins 값은 99,985,592,375,146,668드롭, 즉 약 999억 8,559만 XRP였습니다. 코인마켓캡이 같은 시각 총발행량으로 표시한 999억 8,560만 XRP와 사실상 같은 값입니다. XRP 레저는 수수료가 소각되는 구조라 이 값이 조금씩 줄어드는데, 반대로 늘어난 흔적은 이 조회에서 보이지 않았습니다. 이 총발행량과 에스크로에 묶인 물량이 어떻게 갈리는지는 8월 28일 글 [XRP 3부] 에스크로에 묶인 물량, 공급 구조 읽는 법에 정리해 뒀습니다.

Q3. ’XRP를 무한정 찍을 수 있었다’는 보도는 사실인가요?

이 사건을 다룬 영문 매체의 제목은 “수조 개(trillions)의 XRP를 찍을 수 있었다”와 “수십억 달러 규모”로 갈렸습니다. 숫자가 이렇게 벌어지는 이유는 보고서 자체에 상한 수치가 적혀 있지 않기 때문입니다. 보고서는 총발행량이 숫자가 되돌아가는 지점보다 “훨씬 낮다”고만 썼습니다.

그래서 되돌아가는 지점이 어디인지는 산술로 직접 따져 봐야 합니다. XRP의 최소 단위는 1드롭이고 100만 드롭이 1 XRP입니다. 64비트 정수가 담을 수 있는 최대값은 부호 없는 경우 18,446,744,073,709,551,615드롭(약 18조 4,467억 XRP), 부호 있는 경우 그 절반인 9,223,372,036,854,775,807드롭(약 9조 2,234억 XRP)입니다. 보고서는 둘 중 어느 쪽인지 명시하지 않았지만, 어느 쪽이든 Q2에서 실측한 총발행량 999억 8,559만 XRP의 90배를 넘습니다.

정리하면 매체가 쓴 조 단위 수치는 산술적 한계이고, 실제로 발행됐거나 탈취된 양이 아닙니다. 보고서가 규정한 것은 “정해진 공급량을 넘는 XRP가 생길 수 있었다”는 가능성이며, 얼마나 생길 수 있었는지는 공격자가 깔아 둘 수 있는 오퍼의 수와 가격에 달린 문제여서 하나의 숫자로 고정되지 않습니다.

이 대목은 저희가 10월 5일 글 비트코인 상한은 2,100만 개가 아니다 — 코드가 정한 값은 20,999,999.9769에서 다룬 이야기와 정확히 같은 지점에 있습니다. “공급 상한”은 백서나 홍보 문구가 정하는 것이 아니라 코드가 실제로 어떻게 계산하는지가 정하는 것이고, 그 계산에 구멍이 있으면 상한은 약속으로만 남습니다. 10월 11일 글 소장이 “태워 없앤다”고 적은 MANA, 마지막 소각은 3년 반 전 100개였다에서 문서에 적힌 공급 장치가 실제로 돌고 있는지 체인에서 확인한 것도 같은 이유였습니다.

Q4. 왜 이번에는 수정안 투표를 생략했나요?

XRP 레저는 거래 처리 규칙을 바꿀 때 수정안(amendment)이라는 절차를 씁니다. 검증자들이 찬반을 투표하고, 일정 비율 이상의 지지가 일정 기간 유지되면 활성화되는 방식입니다. 한쪽 서버만 규칙이 달라지면 같은 거래를 두고 서로 다른 결론을 내 네트워크가 갈라질 수 있어서 둔 장치입니다. 채굴도 스테이킹도 없이 검증자 목록으로 합의를 만드는 이 구조 자체는 8월 27일 글 [XRP 2부] 채굴도 스테이킹도 없는 합의 방식에서 다뤘습니다.

이번 오버플로 수정은 그 절차를 거치지 않았습니다. 보고서는 심각도를 근거로 수정안 절차를 우회해 3.4.1 릴리스의 코드 변경으로 바로 넣었고, 거래 처리 방식 변경에 대해 이렇게 한 것은 처음이라고 밝혔습니다. 서버가 3.4.1로 올라가 시작하는 즉시 넘침 검사가 적용되며, 배포 당일 기본 UNL(검증자 목록) 검증자의 80% 이상이 이 버전을 돌리고 있었다고 적혀 있습니다.

여기서 저희가 중요하게 보는 지점은 같은 릴리스에 담긴 두 버그가 서로 다른 경로로 처리됐다는 사실입니다. Q5의 Batch 관련 버그는 수정안 절차를 정상적으로 거쳐 10월 9일 메인넷에서 활성화됐습니다. 반면 오버플로 쪽은 투표 없이 들어갔습니다. 둘을 나란히 놓으면 “무엇이 투표를 생략할 만큼 급한 일인가”를 결정한 주체가 재단과 핵심 개발진이었다는 점이 드러납니다. 탈중앙 네트워크에서 긴급 상황의 판단 권한이 어디에 있는지를 보여 주는 사례이고, 이번 선례가 앞으로 어떤 기준으로 쓰이는지는 지켜볼 일입니다.

수정 내용 자체는 단순합니다. 보고서에 따르면 결제 엔진은 이제 오퍼들의 금액을 더할 때 넘침을 검사하고, 넘칠 합계라면 그 부분은 “경로 고갈(path dry)“이나 부분 결제라는 정상적인 실패 결과로 끝납니다. 여러 결제 경로를 합칠 때도 같은 검사가 추가됐고, “XRP는 새로 생기지 않는다”는 불변식을 확인하는 계산기도 더 넓은 자리수로 바뀌었습니다.

Q5. 같은 날 공개된 다른 버그는 무엇인가요?

Batch 거래의 내부 거래 포장 필드를 검증하지 않던 문제입니다. Batch는 여러 거래를 한 묶음으로 보내는 기능이고, 묶음 안의 각 거래는 RawTransaction이라는 필드에 담겨야 합니다. 그런데 서버가 이 규칙을 확인하지 않아서, 다른 종류의 필드에 담긴 거래도 받아들여져 원장에 기록될 수 있었습니다.

보고서에 적힌 처리 과정은 이렇습니다. 셜록 어택커톤에서 나온 지적(F48)의 당초 등급은 낮음(low)이었는데, 영향 평가 과정에서 서로 다른 버전의 서버가 섞였을 때 합의가 멈출 수 있다는 위험이 확인돼 활성화 전 차단 사유로 올라갔습니다. 수정은 fixBatchV1_2 수정안으로 묶였고, 검증자들이 기존 BatchV1_1 수정안에 던진 표를 일단 회수해 활성화 시계를 되돌린 뒤 수정이 다수 지지를 얻자 다시 표를 넣는 방식으로 진행됐습니다. 두 수정안은 2026년 10월 9일 메인넷에서 활성화됐습니다.

이쪽 버그는 메인넷에서 해당 기능이 켜지기 전에 잡혔습니다. 보고서는 수정 전까지 두 수정안 모두 메인넷에서 활성화된 상태가 아니었고, 메인넷 거래가 잘못 처리된 사례도 없다고 적었습니다.

Q6. 누가 어떻게 이 버그를 찾았나요?

보고서는 오버플로 문제를 Cayden Liao와 Veria AI가 XRPL 버그바운티 프로그램을 통해 신고했다고 적었습니다. 신고 시점은 2026년 9월 22일이고, 공격 증명 코드(proof-of-concept)가 함께 제출됐습니다. 신고자가 매긴 등급은 Major였는데, 리플엑스가 독립 서버에서 공격을 재현한 뒤 critical로 올렸습니다.

보고서에 적힌 처리 일정은 하루 단위로 촘촘합니다. 9월 22일 신고·확인, 22~23일 수정 개발 및 병합, 24일 호가창 교란 시나리오의 실현 가능성 검토, 25일 xrpld 3.4.1 배포, 그리고 10월 9일 보고서 공개입니다. 신고에서 배포까지 사흘이 걸렸고, 공개까지는 2주를 더 기다린 셈입니다. 취약점을 바로 공개하면 패치가 퍼지기 전에 악용될 수 있으므로, 업그레이드가 충분히 퍼진 뒤 공개하는 것이 일반적인 관행입니다.

포상금 액수는 공식 보고서에 적혀 있지 않습니다. 복수의 매체가 이 프로그램의 최고 한도인 25만 달러가 지급됐다고 보도했고, AI 에이전트가 버그를 찾아냈다는 신고자 측 발언도 함께 전했습니다. 다만 저희가 확인한 범위에서 이 두 가지는 원문 보고서로 확인되지 않아 보도 내용으로만 남겨 둡니다.

Q7. 일반 보유자는 지금 무엇을 해야 하나요?

거래소나 지갑 앱으로 XRP를 들고 있는 이용자가 직접 해야 할 일은 보고서에 제시되지 않았습니다. 영향을 받는 것은 소프트웨어를 돌리는 쪽입니다. 보고서는 영향을 받는 버전을 xrpld 3.4.0과 그 이전 전체로 적었고, 깃허브 릴리스 노트는 “서비스 연속성을 위해 가능한 한 빨리 3.4.1로 올리라”고 안내하면서 fixBatchV1_2가 메인넷에서 활성화됐으므로 구버전은 수정안 차단(amendment blocked) 상태가 된다고 밝혔습니다.

배포 날짜에 대해서는 자료 사이에 차이가 있어 그대로 적어 둡니다. xrpl.org 보고서는 3.4.1을 2026년 9월 25일 배포로 적었고, 깃허브 릴리스 페이지는 “2026-09-26에 바이너리 패키지로 먼저 공개했다”고 설명하면서 소스 릴리스 태그 자체는 10월 10일자로 표시합니다. 어느 쪽이 공식 배포일인지는 저희가 확인하지 못했습니다.

앞으로 확인할 일정과 관전 포인트

  • 투표 생략이 선례로 굳는지. 보고서가 스스로 “거래 처리 변경에 대해서는 처음”이라고 적은 만큼, 다음 긴급 상황에서 같은 방식이 쓰일 때 어떤 기준을 들이대는지가 관전 포인트입니다. XRPL 측이 별도의 긴급 패치 기준을 문서로 내놓을지도 지켜볼 대목입니다.
  • 외부 독립 검증 여부. “악용 증거 없음”을 재단이 아닌 제3자가 확인했다는 발표가 나오는지입니다.
  • 버그바운티와 AI 감사의 후속. 이번 신고에 AI 에이전트가 쓰였다는 보도가 사실로 확인되면, 다른 체인들의 감사 방식에도 영향을 줄 수 있습니다. 공식 포상금 내역이 프로그램 페이지에 올라오는지 확인할 수 있습니다.
  • 총발행량 직접 확인법. 공개 노드에 {"method":"ledger","params":[{"ledger_index":"validated"}]}를 보내 응답의 total_coins를 보면 그 시점 원장이 집계한 XRP 총량을 드롭 단위로 직접 읽을 수 있습니다. 집계 사이트를 거치지 않고 체인에 물어보는 방법이라, 공급량 관련 주장을 검증할 때 가장 먼저 쓸 수 있는 수단입니다.

이 글은 정보 제공 목적으로 작성되었으며 투자 권유가 아닙니다. 투자 판단과 책임은 본인에게 있습니다.