라이트코인이 협의 공격을 당해 크로스 체인으로 60만 달러의 손실을 입었습니다: 보안 연구원이 '제로데이 취약점' 을 일축합니다

深潮TechFlow

이 글을 읽으려면 13 분

공식 계정이 비판자를 후퇴시키며 "얕은 물에 머물러" 우롱한 후, 커뮤니티에서 강력한 반발이 일어났다.

원문 제목: "라이트코인 적중 더블 스펜드 공격 긴급 롤백, '제로데이 취약점' 주장에 보안 연구원들 반박"

딥다이브 내용: 라이트코인은 4월 25일 협조 공격을 경험했습니다. MWEB 프라이버시 레이어 취약점이 악용되어 공격자가 업데이트되지 않은 노드를 통해 약 32분 안에 무효 거래를 실행하고 크로스 체인 프로토콜에서 더블 스펜드를 시도했습니다. NEAR Intents는 약 60만 달러의 리스크를 보고했습니다.

네트워크는 13개 블록을 재조직하여 체인 상태를 복구했지만 보안 연구원들은 이 취약점이 37일 전에 이미 비공식적으로 해결되었다는 것을 발견했으며 '제로데이 공격' 주장이 의심받았습니다. 공식 계정은 나중에 비판자들을 풍자하며 "얕은 물 속에 머물러 있으십시오"라고 말해 커뮤니티의 강한 반발을 일으켰습니다.

라이트코인 네트워크는 2022년 MWEB(미음나무 증강 블록, 라이트코인의 프라이버시 거래 레이어) 활성화 이후 처음으로 중대한 보안 사태를 겪었습니다. 공격자는 MWEB 레이어의 합의 취약점을 악용하며 마이닝 풀에 대한 서비스 거부 공격과 협조하여 약 32분 안에 무효 거래가 포함된 분기 블록을 만들고 여러 크로스 체인 프로토콜에서 더블 스펜드 공격을 수행했습니다.

The Block에 따르면, Aurora Labs CEO Alex Shevchenko는 최초로 X 플랫폼에서 이 이상형을 식별하여 이를 '협조 공격'으로 지칭했으며, 관련된 블록 #3,095,930부터 #3,095,943까지의 영향을 받았으며 복구 과정은 3시간 이상 소요되었습니다.

공격은 두 단계로 진행됨: 먼저 마이닝 풀 마비, 그리고 업데이트되지 않은 노드 이용

라이트코인 재단이 4월 25일 발표한 공식 성명에 따르면, 공격 경로는 두 부분으로 나뉩니다.

첫 번째 단계는 주요 마이닝 풀에 대한 DoS 공격으로 업데이트된 클라이언트를 실행하는 노드의 해시파워 비율을 낮추는 것입니다. 두 번째 단계는 MWEB 레이어의 합의 취약점을 악용하여 여전히 이전 버전 소프트웨어를 실행 중인 노드에 무효한 MWEB 거래를 주입하는 것입니다.

이러한 업데이트되지 않은 노드는 이 거래를 정당한 것으로 오인하고, 공격자는 MWEB 프라이버시 레이어에서 자금을 'peg out'하여(프라이버시 레이어의 자금을 메인 체인으로 이체함) 이를 제3자 탈중앙화 거래소로 라우팅했습니다.

Shevchenko는 공격자의 온체인 활동을 더 상세히 공개했습니다: 공격자는 LTC를 ETH로 교환하려고 계획했으며, 이용한 주소는 공격 발생 38시간 전에 바이낸스로부터 자금을 받았습니다. 그는 공격자가 취약점 정보를 미리 파악했다고 판단했습니다.

보통 라이트코인의 블록 생성 간격은 약 2.5분이며, 13개의 블록은 약 32분 내에 생성되어야 합니다. 그러나 이번에는 13개의 블록 생성에 3시간 이상이 걸려, 이러한 이상 현상으로 인해 일부 관측자들이 51% 공격으로 오해하게 되었습니다.

실제로는 DoS 공격이 중지되자, 업데이트된 코드를 실행하는 노드들이 다시 채굴 우위를 차지하여 네트워크는 13개 블록의 재조직을 자동으로 수행하여 무효 트랜잭션을 주 체인에서 제거했습니다. 라이트코인 재단은 재조직 기간 동안 발생한 모든 합법적인 트랜잭션이 영향을 받지 않았다고 밝혔습니다.

크로스체인 프로토콜이 실제 피해를 입다, NEAR Intents가 60만 달러의 노출 보고

공격자는 포크 윈도우 기간을 이용하여 여러 크로스체인 스왑 프로토콜에서 더블 스펜딩을 수행했습니다. 이러한 프로토콜들은 재조직으로 무효화된 MWEB peg-out 트랜잭션을 수용하여 실제로 손해를 보았습니다.

Shevchenko는 X 플랫폼에서 NEAR Intents의 위험 노출이 약 60만 달러임을 밝히며, 해당 팀이 사용자 손실을 보상할 것이라고 밝혔습니다. 그는 동시에 LTC를 수용하는 모든 거래소들이 트랜잭션 기록과 잔고를 심사해야 한다고 경고하며, 체인에는 많은 양의 더블 스펜딩이 존재한다고 설명했습니다.

Bitcoin News에 따르면, 라이트코인이 무효 트랜잭션이 주 체인에서 제거된 후, NEAR Intents의 실제 결산 손실은 초기 추정치보다 낮을 수 있지만, 이 프로토콜은 아직 후속 성명을 발표하지 않았습니다. LTC 관련 업무를 일시 중단한 다른 크로스체인 프로토콜들도 위험 노출을 재평가 중입니다.

라이트코인 재단은 영향을 받는 채굴 풀의 이름을 공개하지 않았으며, 무효 MWEB 트랜잭션으로 발생한 LTC의 양도 공개하지 않았습니다.

PoW 네트워크의 고질적 문제: 업그레이드는 자발적, 안전은 운에 달려있다

Zcash 창시자 Zooko Wilcox는 이후 발생한 이벤트에 대해, 이러한 롤백과 더블 스펜딩 공격은 PoW 네트워크에서 흔한 일이 아니라고 언급했으며, Monero와 Grin도 최근 몇 년 동안 비슷한 사건을 겪었다고 설명했습니다. 2025년 9월, Monero는 역사상 가장 대규모인 12년 만의 블록 재조직을 경험하며, 18개 블록이 롤백되고 117개 트랜잭션이 무효화되었습니다.

CoinDesk의 분석에 따르면, 이번 사건은 PoW 네트워크의 한 구조적 모순을 드러냈는데, 비트코인과 라이트코인에는 강제 업데이트 메커니즘이 없어 노드가 옛 버전 소프트웨어를 무기한으로 실행할 수 있습니다. 이러한 설계는 분산화 철학적으로 가치가 있지만, 보안 패치가 모든 사용자에게 도달하기 전에 공격자가 취약점을 악용하는 상황에서 치명적인 창구가 발생할 수 있습니다.

Yahoo Finance의 분석에 따르면, 라이트코인의 작은 해시파워 규모와 낮은 보안 예산으로 인해 비트코인보다 공격 받기 쉽다고 합니다. 비트코인 네트워크에서 13개 블록 롤백을 하려면 50% 이상의 해시파워를 제어해야 하는데, 이는 수십억 달러의 비용이 듭니다. 그러나 라이트코인에서는 취약점 하나와 DoS 공격 한 번으로 동등한 심도의 재조직을 일으킬 수 있습니다.

공식 PR에서 무산: 비판자를 조롱하며 "얕은 물에 남아 있으라"라고 말한 솔라나(Solana)의 반격

공격 그 자체보다는 사후 조치가 더 큰 신뢰 손실을 가져왔을 수도 있습니다.

4월 26일, 라이트코인 공식 X 계정이 "몇몇 분들이 PoW, 해시파워, 정상 운영 시간, 재조직 및 채굴자/체인 관계에 대해 아무것도 모르는 것은 명백합니다. 얕은 물에 머물러 있으십시오, 거기가 여러분에게 더 안전할 겁니다."라는 게시물을 올렸습니다.

Bitcoin News에 따르면, 해당 글은 수백 개의 적대적인 댓글을 일으켰다고 합니다. 사용자들은 이를 "거만하다", "어린이 같다", "전문가가 아니다"라고 비판했으며, 누군가는 "여러 해 제 라이트코인을 보유했지만, 이것이 당신들이 올린 글인가요?"라고 썼습니다. 커뮤니티는 기술적 투명성과 사후 분석을 기대하며 조롱을 원치 않습니다.

솔라나(Solana)의 공식 계정도 이 상호 작용에 참여했습니다. 4월 25일, @solana가 "소중한 어린 친구, 주말은 어떻게 보냈나요?"라고 답했습니다. 커뮤니티는 이를 라이트코인이 이전에 솔라나의 다운타임 역사를 자주 조롱했다는 직접적인 반격으로 해석했습니다.

해당 사건이 발표된 이후 라이트코인은 대략 56 달러로 거래되었으며, 해당 날짜에 약 1% 하락했습니다. 올해 들어 하락률은 약 25%에 달합니다. 시장의 즉각적인 반응은 비교적 무관심했습니다.

2026년 DeFi 보안 난제: 크로스체인 인프라가 가장 큰 공격 대상

The Block의 데이터에 따르면, 2026년부터 4월 중순까지 DeFi 프로토콜은 다양한 공격으로 7.5억 달러 이상의 손실을 입었습니다. 이 중엔 4월 19일 Kelp DAO 브릿지 공격(2.92억 달러)과 4월 1일 솔라나 펄프 대립 공격(2.85억 달러)도 포함됩니다.

대부분의 주요 사건은 크로스체인 인프라와 관련이 있으며, 라이트코인 공격자가 크로스체인 스왑 프로토콜을 이용해 현금화한 방식과 비슷합니다.

라이트코인 사태는 다시 한 번, PoW 체인 자산을 수용하는 동안 마주하는 확인 수 문제가 예상보다 훨씬 더 심각함을 보여주었습니다. 클라이언트 측에서 한 취약점 공개만으로 13개 블록의 재조직이 트리거되는 상황에서, 6번의 확인이 안전하다고 여겨지는 것은 더는 이론적인 문제가 아닙니다.