BTCPay 서버 구버전 보안 취약점…비트코인 탈취 피해

2026년 11월 3일 읽는 시간 약 11분

BTCPay 서버 해킹, 구버전 핫월렛 BTC 탈취 확인

비트코인 결제 인프라를 운영하는 BTCPay Server에서 구버전 소프트웨어를 사용하는 일부 서버의 핫월렛 자금이 무단 인출되는 보안 사고가 발생했다. 프로젝트 운영진은 긴급 서버 중단을 권고한 뒤 후속 조사에서 버전 2.4.1 이하를 겨냥한 공격 경로를 확인했다고 밝혔다.

이번 사고는 비트코인 네트워크 자체의 보안 결함이 아니라, 가맹점이 직접 운영하는 결제 서버의 접근 권한과 지갑 관리 체계에서 발생한 문제라는 점에서 구분해야 한다.

특히 공격자가 피해 서버에 관리자 권한으로 로그인한 정황이 확인되면서, 자체 호스팅 결제 시스템의 보안 관리가 다시 중요한 쟁점으로 떠올랐다.

구버전 BTCPay Server에서 무슨 일이 발생했나

BTCPay Server는 기업이나 개인 사업자가 비트코인 결제를 직접 처리할 수 있도록 설계된 오픈소스 결제 소프트웨어다. 중앙 결제사업자에게 자금 보관을 맡기지 않고 자체 서버에서 결제 요청과 지갑 연결을 관리할 수 있다는 특징이 있다.

그러나 2026년 11월 1일 프로젝트 측은 일부 서버에서 승인되지 않은 공격자가 핫월렛의 자금을 인출했다는 신고를 접수했다고 발표했다.

초기 경고에서는 공격 원인과 피해 버전이 특정되지 않았기 때문에 운영자들에게 서버를 일시적으로 중단하도록 요청했다.

이후 조사에서 공격 경로가 2026년 7월 23일 출시된 버전 2.4.1과 그 이전 버전을 대상으로 한다는 사실이 확인됐다.

BTCPay Server 공동 창립자 니콜라 도리에(Nicolas Dorier)는 피해 사례에서 공격자가 관리자 권한으로 로그인했다고 설명했다. 다만 공격자가 해당 권한을 어떤 방식으로 확보했는지는 아직 조사 중이다.

이는 취약한 서버가 공격 대상이 됐다는 사실과 실제 침입 수법이 완전히 규명됐다는 주장을 구분해야 한다는 의미다.

버전 2.4.1 이하와 2.4.7의 차이

프로젝트의 후속 안내에서 중요한 기준은 소프트웨어 버전이다.

구분	확인된 내용
2.4.1 이하	이번 사고의 공격 경로가 확인된 버전 범위
2.4.2	지난 8월 별도 보안 취약점을 수정한 버전
2.4.7	11월 2일 기준 신뢰할 만한 핫월렛 탈취 신고가 접수되지 않은 최신 버전
정확한 침입 방식	조사 중
총 피해 금액·피해 서버 수	공개되지 않음

여기서 주의할 점은 최신 버전에서 피해 신고가 없다는 사실이 해당 버전의 절대적인 안전성을 입증하지는 않는다는 것이다.

또한 2.4.2 이상을 사용한다는 이유만으로 모든 운영 환경이 안전하다고 단정할 수도 없다. 서버 운영체제, 접근 권한, 지갑 구성, 추가 설치된 서비스에 따라 위험 수준이 달라질 수 있기 때문이다.

10월 29일 공개된 BTCPay Server 2.4.7 릴리스는 보안과 안정성 문제를 수정한 업데이트다. 공식 GitHub 릴리스 기록에는 보안 점검 과정에서 발견된 다수의 문제가 수정됐다고 명시돼 있다.

다만 이번 11월 사고의 구체적인 공격 원인과 2.4.7의 수정 항목을 직접 연결하는 공식 기술 분석은 아직 공개되지 않았다.

관리자 권한 탈취가 핫월렛 자금 유출로 이어지는 이유

이번 사건의 핵심은 단순한 서버 접속 장애가 아니라, 서버에 연결된 지갑의 자금이 실제로 이동했다는 점이다.

핫월렛은 인터넷에 연결된 환경에서 거래를 생성하고 서명할 수 있도록 구성된 지갑이다. 비트코인 결제를 자동으로 처리해야 하는 사업자에게는 운영상 편리하지만, 서버의 보안 수준에 따라 자금이 직접 노출될 수 있다.

공격자가 관리자 권한을 확보하면 서버 설정을 변경하거나 중요 파일과 지갑 기능에 접근할 가능성이 커진다. 실제로 어떤 자격증명과 서명 기능이 노출되는지는 해당 서버의 구성에 따라 다르다.

반면 콜드월렛은 개인키를 온라인 서버와 분리해 보관하는 방식이다. 결제 서버가 침해되더라도 자금 이동에 필요한 서명 권한이 별도 장치에 남아 있다면 피해 확산을 제한할 수 있다.

이 때문에 BTCPay Server 운영 환경에서는 결제 자동화의 편의성과 서버에 보관하는 자금의 규모를 함께 관리해야 한다.

가맹점이 결제대금을 장기간 핫월렛에 쌓아두는 구조라면 서버 침해 한 번으로 운영자금 상당 부분이 위험에 노출될 수 있다.

지난 8월 LND 취약점 사고와 동일한 공격인가

BTCPay Server는 올해 8월에도 보안 사고를 공개했다.

당시 공식 발표에 따르면 공격자는 취약한 서버에서 라이트닝 네트워크 구현체인 LND의 관리자 인증정보를 확보할 수 있었고, 이를 악용해 연결된 지갑의 자금을 탈취했다.

프로젝트는 버전 2.4.2에서 해당 문제를 수정하고 관련 인증정보를 다시 생성하도록 조치했다.

이번 사고 역시 오래된 버전에서 발생했다는 공통점이 있다. 그러나 두 사건이 동일한 취약점을 이용했는지는 확인되지 않았다.

8월 사고에서 공개된 핵심은 LND 관리자 인증정보 노출이었다. 반면 이번 사고에서는 구버전 서버에 대한 관리자 로그인과 핫월렛 자금 인출이 보고됐다.

두 사고를 하나의 공격 수법으로 단정하면 기술적 원인을 잘못 전달할 위험이 있다.

오히려 반복되는 사건에서 확인할 부분은 보안 업데이트가 적용되지 않은 자체 호스팅 인프라가 장기간 공격 표면으로 남을 수 있다는 사실이다.

자체 호스팅 결제 시스템의 구조적 위험

BTCPay Server의 장점은 결제사업자가 외부 수탁기관에 의존하지 않고 자신의 결제 인프라를 운영할 수 있다는 점이다.

그러나 자금 통제권을 직접 확보한다는 것은 서버 보안과 운영 책임도 직접 부담한다는 뜻이다.

중앙화된 결제사업자라면 서비스 운영자가 전체 시스템의 업데이트를 일괄적으로 적용할 수 있다. 반면 자체 호스팅 방식에서는 개별 가맹점이 자신의 서버를 관리해야 한다.

일부 운영자가 오래된 버전을 유지하면 전체 프로젝트에서 보안 패치를 제공하더라도 해당 서버에는 위험이 남는다.

이번 사고 당시 일부 호스팅 업체가 구버전 서버를 선제적으로 중단한 것도 이러한 구조와 관련이 있다.

서버 중단은 추가 자금 유출을 방지하기 위한 대응이 될 수 있지만, 동시에 가맹점의 비트코인 결제 처리에도 영향을 줄 수 있다.

따라서 사업자는 보안 패치뿐 아니라 사고 발생 시 결제 서비스를 어떻게 일시 중단하고 복구할 것인지에 대한 운영 계획도 갖춰야 한다.

운영자가 확인해야 할 대응 절차

BTCPay Server 측의 초기 긴급 경고는 사고 조사가 끝날 때까지 서버 운영을 중단하라는 내용이었다. 후속 발표에서는 2.4.1 이하 버전이 공격 대상이라는 사실을 확인하고 최신 버전 유지의 중요성을 강조했다.

실제 운영자는 다음 사항을 우선 점검할 필요가 있다.

현재 버전 확인: 사용 중인 BTCPay Server 버전과 공식 릴리스 정보를 대조한다.
운영 중단 여부 판단: 프로젝트의 최신 보안 공지에 따라 취약한 서버의 운영을 일시 중단한다.
침해 흔적 보존: 비정상적인 관리자 로그인, 지갑 인출 내역, 서버 로그를 확보한다.
자금 및 권한 분리: 서버에 보관된 핫월렛 잔액과 개인키·인증정보의 노출 가능성을 점검한다.
안전한 복구: 침해된 서버라면 단순 업데이트만으로 복구가 끝났다고 판단하지 않고 관리자 계정과 인증정보를 재설정하는 등 별도 대응을 검토한다.

특히 이미 관리자 권한이 탈취된 서버에서는 소프트웨어를 업데이트하더라도 공격자가 남긴 접근 수단이 그대로 존재할 가능성을 배제할 수 없다.

따라서 피해가 의심되는 경우에는 로그를 보존하고 공식 보안 대응팀의 안내에 따라 복구 절차를 진행하는 것이 중요하다.