유출된 마카룬 파일 하나가 운영 중인 LND 노드를 털었다

2026년 8월 7일, BTCPay Server의 LND 노드에 무슨 일이 있었나?

개인 키도, 시드 구문도 아닌 단 하나의 자격 증명 파일만으로 실제 비트코인 가맹점들이 운영하던 라이브 Lightning 노드가 비워졌다. 대부분의 운영자가 이상을 알아차리기 전까지 탈취는 약 20시간 동안 이어졌다.

2026년 8월 7일 금요일, BTCPay Server는 긴급 보안 권고를 발표하고 이미 실제 가맹점 서버를 상대로 악용되고 있던 치명적 취약점을 막기 위해 버전 2.4.2를 배포했다 . 이 결함으로 인증되지 않은 원격 공격자는 영향을 받는 인스턴스에서 LND .macaroon 자격 증명 파일을 가져올 수 있었다. 특히 노드의 지갑과 채널에 대한 전체 권한을 지닌 admin macaroon이 문제였다. 개인 키를 훔칠 필요는 없었다. 프로젝트의 공식 권고문에 따르면, 유효한 제어 자격 증명만으로도 채널을 강제 종료하고 그 결과 생긴 온체인 출력을 쓸어갈 수 있었다.

2.4.2 이전의 모든 BTCPay Server 버전이 노출됐고, 2.4.2 릴리스 후보 버전들도 포함됐다 . 메인테이너 Nicolas Dorier는 같은 날 릴리스를 내놓았고, 릴리스 노트에서도 표현을 완곡하게 하지 않았다.

"This release contains fix of a critical vulnerability that is being actively exploited. You need to update as fast as you can," — Nicolas Dorier, maintainer, BTCPay Server (source: v2.4.2 release notes, 2026-08).

BTCPay도 이후 보도들도 전체 피해자 수나 총 탈취액을 공개하지 않았다. 수치로 확인할 수 있는 유일한 그림은 연구자 somaxbt가 제3자로서 온체인을 재구성한 분석이다. 이 분석은 8월 7일 01:17부터 20:52 UTC 사이, 72건의 탈취 거래를 통해 약 60개의 피해 가능 지갑에서 연결된 두 개의 수집 주소로 2.21368911 BTC가 이동했다고 추적했다 . 이 분석은 직접적인 익스플로잇 산출물이 아니라 피해자들의 자가 보고와 시점에 근거해 활동을 귀속하므로, 확정된 총액이 아니라 공개적으로 확인 가능한 하한선으로 봐야 한다 (somaxbt, GitHub).

베어러 토큰 자격 증명이 노드 전체 장악으로 이어진 과정

마카룬은 베어러 토큰입니다. 파일을 가진 사람은 별도의 로그인, 기기 바인딩, 운영자가 대시보드에서 취소할 수 있는 세션 없이 그 파일에 담긴 권한을 그대로 얻습니다. LND 자체 문서도 마카룬을 보유한 누구든 그 마카룬이 허용하는 범위 안에서 lnd에 접근할 수 있다고 명시합니다 . 바로 이 설계 속성 하나가 BTCPay Server의 인증 없는 파일 조회 버그를 실제 라이트닝 노드에 대한 무제한 제어로 바꿔 놓았습니다. 공격자는 암호학을 깨뜨릴 필요가 없었고, 파일만 읽으면 됐습니다.

문제가 된 구체적인 파일은 admin.macaroon이었습니다. LND는 시작 시 admin, read-only, invoice 세 가지 마카룬을 생성하며, 기본 admin 마카룬에는 어떤 주의 조건도 붙지 않습니다. 즉 어떤 RPC 호출을 할 수 있는지, 어디에서 호출할 수 있는지, 얼마 동안 사용할 수 있는지에 대한 제한이 없습니다 . 같은 문서는 이러한 기본 파일을 암호화되지 않은 고도로 민감한 파일로 취급하며, 신뢰할 수 없는 환경에서는 데몬 전체 접근 권한을 부여한다고 설명합니다 . BTCPay의 보안 권고문은 악용된 결함을 .macaroon 확장자를 가진 파일을 인증 없이 원격으로 가져올 수 있었던 문제라고 설명했고, 이후 사고 대응에서는 노출된 자격 증명이 공격자들이 연결된 지갑에 접근하는 데 사용한 LND admin 마카룬이었다고 확인했습니다 .

그다음 장악 과정은 수탁 시스템 침해가 아니라 라이트닝 자체 메커니즘을 통해 진행됐습니다. admin 권한을 가진 공격자는 노드에 결제 채널 강제 종료를 지시할 수 있습니다. 그러면 각 채널이 일방적으로 정산되고, 로컬 잔액은 UTXO 묶음 형태로 노드의 온체인 지갑에 돌아옵니다. 이후 이 출력값들은 공격자가 통제하는 주소로 쓸어 담깁니다. 이 ‘강제 종료 후 스윕’이라는 2단계 패턴은 공개적으로 확인된 두 사례 모두와 일치합니다. Passport 하드웨어 지갑 제조사 Foundation은 공격자들이 밤사이 BTCPay 라이트닝 노드의 채널을 강제 종료하고 그 결과 생긴 온체인 출력값을 스윕해 자금을 빼냈다고 밝혔습니다. 비트코인 매체 Citadel21도 자사 노드가 스윕됐지만 보유 자금은 아주 적었다고 보도했습니다 . 제3자의 온체인 재구성에서도 같은 기계적 흔적이 보입니다. 해당 분석은 조사 대상 집합 안에서 같은 날 발생한 채널 종료 UTXO 207개를 집계했습니다 .

이 공격이 건드리지 않은 부분도 그만큼 중요합니다. BTCPay Server의 온체인 개인 키는 추출되지 않았고, BTCPay의 검토 결과 BTCPay 핫월렛을 포함한 BTCPay Server 온체인 지갑은 이 자격 증명 탈취 경로의 영향을 받지 않은 것으로 결론났습니다. LND 자체 온체인 지갑에 있던 자금은 손상된 노드에 속하므로 계속 위험에 노출됐습니다 . Foundation의 사례도 이 경계를 정확히 보여줍니다. 라이트닝 노드는 비워졌지만 BTCPay 온체인 핫월렛은 건드려지지 않았습니다 . 다시 말해 침해는 전적으로 제어 영역에서 발생했습니다. 운영자가 자신의 노출 범위를 판단할 때 쉽게 뒤섞이는 두 가지 질문을 분리해야 합니다.

• 수탁 — 시드와 서명 키를 누가 보유하는가. 여기서는 변하지 않았습니다. BTCPay 자체 지갑 키는 표적이 아니었습니다.
• 제어 — 실행 중인 데몬에 인증된 명령을 누가 내릴 수 있는가. 유출된 것은 이것이며, LND에서는 이것만으로도 자금을 이동시키기에 충분합니다.
• 구현 범위 — Core Lightning이나 Eclair를 실행하는 노드, 그리고 온체인 전용 배포는 이 자격 증명 경로에 노출되지 않았습니다. 다만 BTCPay는 그와 무관하게 모두에게 업데이트를 권고했습니다 .

베어러 자격 증명은 이 두 질문을 하나로 무너뜨립니다. 조용히 복사할 수 있고, 기본적으로 만료가 없으며, 데몬이 노출하는 모든 RPC를 승인하는 파일은 기능적으로 그것이 지키는 자금과 다르지 않습니다. 이 점이 이후의 모든 복구 조치를 규정합니다.

실제로 노출된 노드 운영자는 누구였나?

노출 범위는 첫 보안 공지가 시사한 것보다 좁았다. Lightning 백엔드로 LND를 쓰는 BTCPay Server 인스턴스만 자격 증명 탈취 위험에 놓였고, 2.4.2 이전의 모든 버전, 2.4.2 릴리스 후보까지 영향을 받았다 . 자체 검토 뒤 BTCPay는 BTCPay Server가 관리하는 온체인 지갑, BTCPay 핫월렛을 포함한 지갑은 이 경로의 영향을 받지 않았다고 확인했다. 실제로 위험에 놓인 자금은 LND 자체 온체인 지갑과 결제 채널 안에 있었다 .

이 구분은 대응 우선순위를 정할 때 중요하다. Core Lightning이나 Eclair로 BTCPay를 운영했거나 Lightning 백엔드를 전혀 쓰지 않은 운영자는 취약 버전을 실행 중이었더라도 마카룬 회수 경로에는 노출되지 않았다 . 공개된 피해 양상도 이 기술적 범위와 맞아떨어진다. Passport 기기 뒤의 하드웨어 지갑 제조사 Foundation은 밤사이 BTCPay Lightning 노드에서 강제 종료된 채널과 온체인으로 쓸어간 출력 때문에 자금이 빠져나갔지만, BTCPay 온체인 핫월렛은 건드려지지 않았다 .

차단 조치에는 의도된 대가가 따랐다. 2.4.2 버전은 Docker 배포에서 LND API의 공개 접근을 일시적으로 제거했고, 그 결과 BTCPay 도메인이나 Tor onion 주소를 통해 연결하던 외부 지갑 연결이 끊겼다. Zeus 같은 도구는 프로젝트가 인터페이스를 안전하게 복구할 때까지 원격 노드 관리를 잃었다 . Lightning 결제 자체는 계속 정상적으로 라우팅됐고, 원격 관리만 철회됐다 . 끊긴 Zeus 연결을 두 번째 침해로 읽은 운영자가 본 것은 결함이 아니라 수정 조치였다(동영상: FatheryFinds).

눈여겨봐야 할 쪽은 잔여 위험 그룹이다. 표준 BTCPay 업데이트는 LND를 0.21.1로 올리고 마카룬을 재생성한다. 하지만 BTCPay는 리버스 프록시, 별도 Tor 서비스, 포워딩된 포트, 또는 BTCPay Server 밖에서 직접 관리하는 어떤 경로로든 LND를 노출한 운영자는 자격 증명을 직접 교체해야 한다고 명확히 밝힌다. 업데이트가 소프트웨어가 통제하지 않는 접근 경로까지 닫을 수는 없기 때문이다 . Start9의 BTCPay 패키지 문서도 2.4.2:1 마이그레이션에서 같은 점을 제기한다. Lightning 백엔드의 핵심 자격 증명 교체 작업을 드러내고, 과거 LND 패키지 동작이 루트 키를 교체하지 않은 채 마카룬을 재생성해 이전에 복사된 파일이 계속 유효하게 남았다고 설명한다. 그래서 revoke-macaroons 작업에는 LND 0.21.1-beta:11 이상이 의존성 하한으로 필요하다 . 요컨대 누가 노출됐는지는 백엔드 선택이 갈랐고, 누가 아직 위험한지는 네트워크 토폴로지가 결정한다.

확인된 피해: Foundation, Citadel21, 그리고 온체인 흔적

BTCPay Server 마카룬 익스플로잇으로 손실을 입었다고 공개 확인한 조직은 두 곳이다. Passport 기기를 만드는 하드웨어 지갑 업체 Foundation과 비트코인 매체 Citadel21이다 . Foundation CEO Zach Herbert는 공격자들이 밤사이 회사의 BTCPay 라이트닝 노드에서 자금을 빼내고, 채널을 강제 종료한 뒤 그 결과 생긴 온체인 출력을 쓸어갔다고 밝혔다. 반면 BTCPay 온체인 핫월렛은 건드리지 않았다 . Citadel21도 자사 노드가 쓸려 나갔다고 보고했지만, 당시 보유 자금은 매우 적었다고 했다 .

Foundation 사례는 탈취된 admin 마카룬이 실제 현장에서 무엇을 가능하게 하는지 가장 선명하게 보여준다. 모든 채널을 강제 종료하고 그 결과 출력을 쓸어가는 방식은 개인키 탈취가 아니라 자동화된 자격 증명 악용의 기계적 특징이다. LND의 통제 밖에 있는 온체인 핫월렛은 그대로 살아남았기 때문이다 . 이 구분은 BTCPay 프로젝트가 최종적으로 공개한 영향 범위와도 일치한다. 핫월렛을 포함한 BTCPay 온체인 지갑은 영향을 받지 않았고, LND 자체 온체인 지갑 안의 자금은 침해된 노드의 범위에 들어갔다 .

유출 규모를 수치로 보여주는 유일한 그림은 연구자 somaxbt가 공개한 독립 온체인 분석에서 나왔다. 공식 사후 분석은 아니라고 명시된 자료다. 이 분석은 2026년 8월 7일 01:17부터 20:52 UTC까지 이어진 활동을 추적해, 가능성이 높은 60개 지갑에서 연결된 두 개의 수집 주소로 2.21368911 BTC가 흘러 들어간 것을 확인했다 .

이 수치에는 책임 있는 독자라면 건너뛰면 안 되는 중요한 단서가 붙는다. 이 분석은 직접적인 익스플로잇 산출물이 아니라 피해자들의 자기 보고와 시간대 상관관계를 근거로 해당 활동을 BTCPay 취약점에 연결했다 . 따라서 이는 부분적인 재구성이다. 별도의 수집 주소를 통해 털린 노드나 끝내 공개 제보하지 않은 운영자는 분석 대상 집합에 전혀 나타나지 않는다.

BTCPay Server도, 이 사건을 다룬 매체들도 전체 피해자 수나 총 도난액을 공개하지 않았다 . 프로젝트는 취약점이 실제로 악용됐고, 사용자가 영향을 받았으며, 자금이 도난당했다는 정성적 사실은 확인했지만 숫자는 붙이지 않았다 . 리스크 규모를 가늠해야 하는 트레이더와 운영자에게 실무적으로 읽히는 메시지는 이렇다. 2.21368911 BTC는 문서화된 하한선이고, 약속된 기술 사후 분석이 나오기 전까지 상한선은 알 수 없다. 이 사건에 대한 한 독립 리뷰가 짚었듯이, 헤드라인 가격 움직임보다 훨씬 더 중요했던 것은 셀프커스터디로 보관하던 라우팅 자본이 하룻밤 사이 한 번의 시간 창 안에서 쓸려 나갈 수 있었다는 사실이었다(video: FatheryFinds).

2.4.2로 업데이트만 해서는 피해를 막을 수 없는 이유

침해된 BTCPay Server에 패치만 적용한다고 안전해지는 것은 아닙니다. 2.4.2 릴리스는 공격자가 .macaroon 파일을 가져갈 수 있게 했던 미인증 파일 조회 경로를 닫았지만, 공격자가 이미 복사한 macaroon을 무효화하지는 않습니다 . Macaroon은 bearer token입니다. 도난당한 사본은 노드 수준에서 해당 자격 증명을 폐기하고 다시 생성하기 전까지 계속 유효합니다. 그래서 운영자가 사고가 끝났다고 믿은 뒤 몇 시간이 지나도, 완전히 업데이트된 노드에서 여전히 자금이 빠져나갈 수 있습니다.

일반적인 BTCPay Server 업데이트는 이 중 일부를 자동으로 처리합니다. 업데이트를 적용하면 Lightning 백엔드가 LND 0.21.1로 이동하고 그 과정에서 노드의 macaroon이 다시 생성되므로, BTCPay 자체를 통해 노드에 접근하는 경우 이전에 유출된 파일은 무효화됩니다 . 빈틈은 접근 경로를 BTCPay가 아니라 운영자가 제어하는 경우에 생깁니다. LND가 리버스 프록시, Tor hidden service, 포워딩된 포트, 또는 BTCPay Server 밖에서 설정된 다른 경로를 통해 노출되어 있다면, 프로젝트는 자격 증명을 별도로 교체해야 한다고 명확히 밝힙니다. 업데이트가 자신이 열지 않은 문까지 닫을 수는 없기 때문입니다 .

패키지형 배포에는 더 미묘한 함정이 있습니다. Start9의 BTCPay Server 문서는 2.4.2:1 마이그레이션에서 자격 증명 교체를 핵심 작업으로 표시하고, LND 백엔드 운영자에게 revoke-macaroons 작업을 안내하면서, 업데이트만으로는 공격자가 이미 확보한 접근 권한을 되돌릴 수 없다고 명시적으로 경고합니다 . 이전 LND 패키지 동작은 내부 root key를 교체하지 않은 채 macaroon 파일만 다시 만들었습니다. 즉 새로 작성된 파일은 새것처럼 보였지만, 이전에 복사된 macaroon은 암호학적으로 계속 유효했습니다. 이것이 revoke-macaroons의 의존성 하한이 LND 0.21.1-beta:11 이상인 이유입니다 . 오래된 패키지에서 파일만 다시 생성하고 작업이 끝났다고 생각한 운영자는 여전히 열린 문을 붙잡고 있을 수 있습니다.

LND 운영자를 위한 BTCPay의 자체 복구 체크리스트는 정해진 순서로 진행되며, 단계를 건너뛰는 것이 노드를 노출된 상태로 남깁니다 :

• 업데이트: Server Settings → Maintenance → Update를 통해 진행하거나, 즉시 업데이트할 수 없다면 서버를 오프라인으로 전환합니다.
• 버전 확인: 관리자 푸터에 2.4.2와 LND 0.21.1이 표시되어야 합니다. 2.4.2의 릴리스 후보 버전은 패치된 것으로 보지 않습니다 .
• 노드 수준에서 macaroon 폐기 및 재생성: BTCPay 인터페이스에서만 처리하지 말고, 독립적으로 노출된 모든 LND 경로에 대해 반드시 수행해야 합니다.
• BTCPay가 생성한 온체인 hot wallet의 자금을 옮기고 지갑을 다시 생성: 온체인 지갑이 유출 대상은 아니었더라도 기존 지갑은 폐기된 것으로 취급합니다.
• 침해 여부 감사: 승인되지 않은 결제, 예상치 못한 채널 폐쇄, 낯선 피어, 내부 기록과 실제 온체인 또는 채널 잔액 사이의 차이를 확인합니다.

마지막 항목은 대부분의 운영자에게 부족한 탐지 계층입니다. 이번 사고에서 문서화된 자금 탈취 패턴, 즉 채널을 강제 폐쇄한 뒤 그 결과로 생긴 온체인 출력을 쓸어가는 방식은 감사 단계가 찾도록 되어 있는 바로 그 흔적을 남깁니다 . 통합 운영자에게는 업그레이드와 함께 NBXplorer를 2.6.10으로 올리라는 권고도 있었습니다 . 억제 조치의 의도된 부작용도 하나 있었습니다. 2.4.2는 Docker 배포에서 공개 LND API 접근을 일시적으로 제거했으며, 그 결과 Zeus 같은 도구가 BTCPay 도메인이나 onion 주소를 통해 원격 노드를 관리하는 기능이 깨졌습니다. Lightning 결제는 계속 작동했고, 외부 노드 제어만 철회되었습니다 .

BTCPay의 대응: 포상금, 제보 인정, 그리고 수정된 내용

이 취약점은 비트코인 오픈소스 프로젝트를 감사하기 위해 AI 보조 도구를 사용하는 자원봉사 그룹인 Bitcoin Red Team의 비공개 제보를 통해 BTCPay Server에 전달됐다. 공로가 인정된 구성원으로는 Sparrow Wallet의 Craig Raw, Rob Hamilton, Calle, ZEUS wallet의 Evan Kaloudis가 포함된다 . Raw는 자신도 이 탈취 피해를 직접 입었다고 공개했는데, 이는 제보자가 피해자 집단 바깥이 아니라 그 안에 있었다는 뜻이다. 보기 드물지만 확인 가능한, 당사자적 이해관계가 걸린 제보였던 셈이다.

BTCPay Server Foundation은 이 제보에 빠르게 보상금을 붙였다. 취약점을 책임 있게 보고한 대가로 Craig Raw와 Bitcoin Red Team 펀드에 각각 0.21 BTC를 지급하겠다고 약속했고, 프로젝트 후원자들은 별도로 반환되는 자금의 10%에 해당하는 회수 포상금을 내걸었다. 전체 회수 시 상한은 3 BTC였다 . 이 구조는 주의 깊게 볼 필요가 있다. 제보 보상은 고정되어 있고 이미 받을 자격이 생긴 돈인 반면, 회수 포상금은 조건부이며 현재 도난 출력값을 통제하고 있는 누군가를 향한 제안이다. 제안 당시의 비트코인 가격 기준으로, 이 3 BTC 상한은 약 19만 달러로 보도됐다 .

메인테이너 Nicolas Dorier는 대응 과정에서 잘못 퍼진 사실관계도 바로잡았다. 온라인에서는 악용된 결함이 이미 알려졌거나 이전에 제보된 문제였다는 주장이 돌았지만, Dorier는 해당 버그가 Red Team에 의해 새로 발견된 것이라고 공개적으로 밝혔고, 프로젝트 차원에서 전체 기술 사후 분석을 게시하겠다고 약속했다 . 이 구분은 운영자의 책임과 프로젝트의 제보 처리 절차에 대한 신뢰를 판단하는 데 중요하다. 이미 알고도 방치한 버그와 비공개로 보고된 제로데이는 메인테이너의 대응을 평가할 때 전혀 다른 결론으로 이어지기 때문이다.

"이번 릴리스에는 현재 활발히 악용되고 있는 치명적 취약점에 대한 수정이 포함되어 있습니다. 가능한 한 빨리 업데이트해야 합니다," — Nicolas Dorier, maintainer, BTCPay Server (source: BTCPay Server v2.4.2 release notes).

macaroon 수정 자체를 넘어, 2.4.2 버전에는 악용된 결함과 자주 한데 묶여 설명되지만 기술적으로는 별개인 여러 보강 조치도 포함됐다 :

• Greenfield Basic 인증은 기본적으로 비활성화되며, 계정 생성 5분 뒤 꺼지도록 해 오래 남아 있던 레거시 인증 표면을 좁혔다.
• TOTP 2단계 인증 우회 문제가 수정됐다. 이 우회는 Greenfield Basic 인증을 통해 이뤄졌으며, 일부 보도에서 함께 언급됐지만 실제로 활발히 악용된 문제는 아니었다.
• 공개 인보이스 생성 속도 제한이 결제 요청에 추가되어, 인증되지 않은 엔드포인트 남용을 줄였다.
• NBXplorer 2.6.10이 권장됐으며, 업데이트를 배포하는 통합업체가 적용 대상으로 제시됐다.

공식 권고문은 실제로 활발히 악용된 문제를 TOTP 우회가 아니라 인증 없는 .macaroon 파일 조회로 명확히 규정한다 . BTCPay는 자금 추적과 동결을 위해 거래소, 블록체인 분석 업체, 수사기관과 협력하고 있으며, 외부 코드 스캔과 리뷰 절차를 추가하는 한편 당분간 주요 신규 기능보다 보안 패치와 강화 작업을 우선하겠다고 밝혔다 . 이런 우선순위 변화는 릴리스 흐름에서도 드러났다. 2026년 9월 7일 공개된 2.4.4 버전은 해시 처리된 API 키 저장, 레거시 BitPay Basic-auth 키 제거, 인보이스 권한 수정, 지원 링크를 통한 스크립트 삽입 차단을 추가했다 . 한 독립 논평자는 이 사건을 비트코인 프로토콜의 실패가 아니라 자격 증명 처리 실패로 규정하면서, 네트워크 자체는 깨지지 않았지만 운영자가 통제하는 키가 뚫렸다고 지적했다(video: FatheryFinds).

앞으로 Lightning 인프라 리스크를 어떻게 봐야 하나

2026년 8월 탈취 사건이 남긴 오래가는 교훈은 자체 호스팅 Lightning 노드에는 온체인 커스터디 보호 장치의 바깥에 있는 자격 증명 관리 리스크가 있으며, 이 보호 장치를 우회할 수 있다는 점이다. Foundation의 BTCPay 온체인 핫월렛은 그대로였지만 Lightning 노드는 하룻밤 사이 비워졌다 . 시드 백업, 하드웨어 서명기, 월렛 암호구문은 이미 강제 종료와 스윕 권한을 가진 bearer token 앞에서는 방어가 되지 않는다. 운영자에게 리스크 표면은 키가 아니라 파일이다.

이 차이는 자체 호스팅 결제 인프라를 평가하는 방식을 다시 잡게 만든다. 노드의 위협 모델은 .macaroon이 읽히거나 복사될 수 있는 모든 경로를 포함해야 한다. 리버스 프록시, Tor hidden service, 포워딩된 포트, 백업, 컨테이너 볼륨이 모두 해당하며, 각각은 소프트웨어 업데이트만으로는 닫히지 않는 독립적인 유출 경로다 . 중요한 운영 지표는 패치 주기뿐 아니라 자격 증명 교체 주기가 된다.

탈취 자금 회수 여부는 아직 열려 있다. BTCPay Server는 탈취금 추적과 동결을 위해 거래소, 블록체인 분석 업체, 수사기관과 협력하고 있다고 밝혔지만, 회수 일정은 확인되지 않았고 전체 피해자 수나 총 피해액도 공개되지 않았다 . 공개적으로 수치가 제시된 유일한 그림은 여전히 제3자의 온체인 재구성으로, 72건의 탈취 거래를 통해 2.21368911 BTC가 연결된 두 수집 주소로 들어간 흐름을 추적한 것이다 . 배상을 기다리는 운영자는 아무것도 돌아오지 않는다는 전제로 계획해야 한다.

개발 측면에서 프로젝트는 당분간 주요 신규 기능보다 보안 패치와 강화 작업을 우선하겠다고 밝혔고, 외부 조직과 함께 더 강한 코드 스캔 및 외부 검토 절차를 도입하고 있다 . 사고 이후의 속도는 이것이 단순한 의지 표명이 아니라는 점을 뒷받침한다.

2.4.4 변경의 방향이 읽어야 할 신호다. 저장된 API 키를 해시 처리하고 레거시 BitPay Basic 인증 경로를 삭제한 것은 모두 탈취 사건이 드러낸 같은 구조적 약점을 겨냥한다. 인터넷에 노출된 서버 안에 오래 유지되고, 평문이며, 재사용 가능한 자격 증명이 놓여 있었다는 점이다 . 긴급 패치와 후속 조치 사이에는 31일이 걸렸고, 이는 유지관리자들이 단일 악용 엔드포인트뿐 아니라 자격 증명 아키텍처 자체를 얼마나 진지하게 다루고 있는지 보여주는 합리적인 대리 지표다.

이 장이 끝났다고 결론 내리기 전에 신중해야 할 미해결 질문은 두 가지다. 전체 기술적 근본 원인은 아직 공개되지 않았고, 세부 사항은 운영자들이 업데이트할 시간을 주기 위해 보류되었으며, 추적된 자금이 여전히 이동하지 않았는지도 알 수 없다 . 사후 분석이 나오기 전까지 운영자는 악용된 내용의 전체 그림이 아니라 보안 권고에 근거해 대응하고 있다.

운영자 점검 목록: 아직 노출된 상태인가?

2026년 8월 7일 이전에 존재했던 LND 인스턴스가 노드 수준에서 마카룬을 폐기하고 재생성한 적 없이 계속 실행 중이라면, 해당 운영자는 여전히 노출된 상태입니다. 패치는 첫 단계일 뿐 마무리가 아닙니다. BTCPay Server 2.4.2로 업데이트하면 추가적인 자격 증명 유출은 막을 수 있지만, 이미 복사된 베어러 토큰은 마카룬 루트 키를 로테이션하기 전까지 계속 유효합니다 . 버전 번호 확인에서 멈추지 말고 아래 순서대로 처리하세요.

• 안전하다고 판단하기 전에 버전을 확인하세요. Server Settings → Maintenance → Update를 연 뒤, 관리자 푸터에 BTCPay Server 2.4.2와 LND 0.21.1이 표시되는지 확인하세요. 2.4.2 이전의 모든 릴리스는 2.4.2 릴리스 후보 버전을 포함해 영향을 받았습니다 . 현재 배포 환경은 더 나아갈 수 있습니다. 2026년 9월 7일에 릴리스된 2.4.4는 해시 기반 API 키 저장을 추가하고 기존 BitPay Basic 인증 키를 제거합니다 .
• 업데이트만 하지 말고 로테이션하세요. 표준 BTCPay 업데이트는 LND의 마카룬을 재생성하지만, LND가 BTCPay의 관리형 프록시 밖에서 접근 가능한 상태라면, 예를 들어 리버스 프록시, Tor 히든 서비스, 포워딩된 포트가 있다면, 직접 노드 수준 폐기를 실행하세요. Start9에서는 이것이 revoke-macaroons 작업이며, LND 0.21.1-beta:11 이상이 필요합니다. 이전 패키지는 루트 키를 로테이션하지 않고 마카룬 파일만 다시 만들어 복사본이 계속 유효하게 남았기 때문입니다 .
• BTCPay가 생성한 온체인 핫월렛을 다시 만드세요. 기존 주소 세트를 신뢰하지 말고 잔액을 옮긴 뒤 지갑을 새로 구축하세요 .
• 사고 발생 시간대를 감사하세요. 채널 기록에서 강제 종료, 낯선 피어, 승인되지 않은 결제, 내부 기록과 실제 온체인 또는 채널 잔액 사이의 차이를 확인하세요. 공개 온체인 재구성에 따르면 탈취 활동은 2026년 8월 7일 01:17부터 20:52 UTC 사이에 발생했으며, 72건의 트랜잭션과 당일 채널 종료 출력 207개에 걸쳐 있었습니다 . 대조해야 할 범위가 비교적 좁습니다.

운영상 유의할 점도 하나 있습니다. 2.4.2는 Docker 배포에서 공개 LND API 접근을 일시적으로 철회했기 때문에, Zeus 같은 외부 지갑 도구는 해당 경로가 복구될 때까지 원격 노드 관리를 사용할 수 없습니다. 라이트닝 결제 자체는 계속 작동합니다(video: FatheryFinds). 모든 라이트닝 운영자가 가져가야 할 핵심은 분명합니다. 어떤 보안 공개 이후에도 자격 증명 로테이션을 필수적인 두 번째 단계로 다루고, 이를 노드에서 직접 확인해야 합니다. 완전히 패치된 서버라도 오래된 마카룬으로 실행 중이라면 여전히 열린 문이나 다름없기 때문입니다.

자주 묻는 질문

LND에서 마카룬은 무엇이며, 유출되면 왜 위험한가요?

마카룬은 LND가 시작될 때 생성하는 베어러 자격 증명으로, 노드에 대한 API 호출을 인증하는 데 쓰입니다. LND는 admin, read-only, invoice 세 가지를 만들며, 기본 admin.macaroon은 제한 조건 없이 발급되므로 데몬에 대한 무제한 관리자 권한을 가집니다 . 베어러 토큰이기 때문에 파일을 가지고 있다는 사실만으로 충분합니다. 파일을 가진 사람은 비밀번호 입력, 2단계 인증, 노드의 개인키 탈취 없이도 그 파일이 허용하는 모든 작업을 할 수 있습니다. LND 공식 문서도 기본 마카룬 파일을 암호화되지 않은 파일이며 신뢰할 수 없는 환경에서는 매우 민감한 파일이라고 설명합니다 . 바로 이 설계 때문에 2026년 8월 BTCPay Server 결함의 피해가 커졌습니다. BTCPay Server 보안 권고문이 설명하듯, 공격자가 .macaroon 파일을 가져가면 채널을 강제 종료하고 그 결과 생긴 온체인 출력을 쓸어갈 수 있었습니다.

2.4.2 패치 이후 BTCPay Server는 안전하게 사용할 수 있나요?

2026년 8월 7일 출시된 BTCPay Server 2.4.2에서 유출 경로는 막혔지만, 패치만으로 이미 노출됐던 노드가 안전해지는 것은 아닙니다 . 업데이트는 추가적인 자격 증명 탈취를 막지만, 공격자가 이미 복사한 마카룬을 무효화하지는 않습니다. 해당 마카룬은 삭제하고 재생성하기 전까지 계속 유효합니다. 일반적인 BTCPay 업데이트는 LND를 0.21.1로 옮기고 마카룬을 재생성하지만, BTCPay는 리버스 프록시, Tor 서비스, 포트 포워딩 등을 통해 LND를 별도로 노출한 운영자는 자격 증명을 따로 교체해야 한다고 경고합니다. BTCPay Server 바깥에서 운영자가 관리하는 접근 경로는 업데이트만으로 닫을 수 없기 때문입니다 . 이후 프로젝트는 2026년 9월 7일 2.4.4에서 API 키 해시 저장과 레거시 BitPay Basic-auth 키 제거를 포함한 추가 강화 조치도 배포했습니다 . 필요한 것은 패치만이 아니라 패치, 교체, 검증을 함께 하는 것입니다.

BTCPay Server 자체 자금이나 온체인 지갑도 영향을 받았나요?

아니요. BTCPay는 처음에는 온체인 지갑에 대해서도 각별한 주의를 권고했지만, 이후 프로젝트 검토 결과 BTCPay 핫월렛을 포함한 BTCPay Server 온체인 지갑은 이 취약점의 영향을 받지 않은 것으로 결론 내렸습니다 . 노출 경로는 탈취된 LND admin 마카룬을 통한 것이었으므로, 위험에 처한 것은 LND 노드 자체, 즉 채널 잔액과 LND 자체 온체인 지갑에 들어 있던 코인이었습니다. 실제 결과도 이 경계와 일치했습니다. 하드웨어 지갑 제조사 Foundation은 공격자들이 밤사이 자사의 BTCPay 라이트닝 노드에서 자금을 빼내고 채널을 강제 종료한 뒤 생긴 온체인 출력을 쓸어갔지만, BTCPay 온체인 핫월렛은 건드리지 않았다고 밝혔습니다 . 다만 BTCPay는 예방 차원에서 BTCPay가 생성한 온체인 핫월렛의 자금을 옮기고 지갑을 다시 만들 것을 여전히 권고합니다.

BTCPay Server LND 익스플로잇으로 얼마나 도난당했나요?

공식 총액은 없습니다. BTCPay는 결함이 악용됐고, 사용자가 영향을 받았으며, 자금이 도난당했다는 점은 확인했지만, 프로젝트나 언론 보도 어디에서도 피해 운영자 수나 총 탈취액은 공개하지 않았습니다 . 수치가 제시된 유일한 그림은 연구자 somaxbt가 공개한 독립 온체인 분석입니다. 이 분석은 2026년 8월 7일 01:17부터 20:52 UTC까지 약 60개의 피해 가능 지갑에서 연결된 두 개의 수집 주소로 2.21368911 BTC가 흘러간 것을 추적했으며, 여기에는 72건의 드레인 거래, 556개의 서로 다른 피해자 주소, 559개의 사용된 UTXO, 당일 발생한 207개의 채널 종료 출력이 포함됐습니다 . 이 작업은 직접적인 익스플로잇 산출물이 아니라 피해자 자체 신고와 시점에 근거해 활동을 귀속한 것이므로, 2.21 BTC는 확정된 최종 수치가 아니라 공개적으로 확인 가능한 하한선이자 부분적인 재구성으로 봐야 합니다.

이 취약점은 Core Lightning이나 Eclair 사용자에게도 영향을 주나요?

아니요. BTCPay Server의 검토 결과, 자격 증명 탈취 위험은 LND의 마카룬 모델에 특화된 것으로 나타났고, 프로젝트가 조사한 공격은 .macaroon 확장자를 가진 파일을 겨냥했습니다. 라이트닝 백엔드로 Core Lightning이나 Eclair를 쓰는 운영자, 그리고 온체인 전용 배포를 운영하는 경우는 이 경로에 노출되지 않았습니다 . 그렇다고 해도 2.4.2 이전의 모든 BTCPay Server 버전은 2.4.2 릴리스 후보를 포함해 영향을 받았고, 같은 릴리스에서는 Greenfield Basic 인증을 통한 TOTP 2단계 인증 우회, 계정 생성 5분 뒤 Greenfield Basic 인증 기본 비활성화, 공개 인보이스 생성에 대한 속도 제한 추가도 함께 수정됐습니다 . LND를 쓰지 않는 운영자도 이러한 별도 수정 사항 때문에 업데이트해야 합니다.