NEAR Intents는 2026년 10월 1일 BNB Chain에서 약 $3.8M 규모의 USDT exploit가 발생했음을 공개했으며, 해당 사고의 원인을 Omni 입출금 인프라와 NEAR Intents smart contract 간 상호작용의 버그로 추적했습니다.
이번 사고는 NEAR Protocol layer 1 자체가 아니라 NEAR Intents 주변의 cross-chain 계층에 영향을 미쳤습니다. NEAR는 네트워크가 다운타임 없이 계속 블록을 생성하고 트랜잭션을 처리했다고 밝혔으며, NEAR Intents는 서비스를 중단하고 contract 측 취약점을 패치했습니다. 10월 2일 기준 정확한 버그 클래스와 오류가 발생한 구체적 컴포넌트는 공개되지 않았지만, 현재까지 확인된 사실은 심각한 bridge 회계 및 출금 승인 경계의 문제를 가리킵니다.
핵심 요점: NEAR Intents의 $3.8M exploit는 모든 자산 해제가 연결된 모든 체인에서 실제로 존재하고, 고유하며, 이전에 사용되지 않은 deposit 또는 debit에 대응함을 bridge 보안이 입증해야 하는 이유를 보여줍니다. smart contract 패치는 필요하지만, 완전한 방어 체계는 relayer, bridge 인프라, signer 통제 및 reconciliation 로직까지 포함해야 합니다.
NEAR Intents exploit 동안 무슨 일이 발생했나요?
공격자는 Omni 입출금 인프라와 NEAR Intents smart contract 간 상호작용의 버그를 악용하여 BNB Chain에서 NEAR Intents로부터 약 $3.8M 상당의 USDT를 탈취했습니다. 자금 유출은 공개 발표 이전부터 확인됐으며, NEAR Intents는 서비스를 중단하고 contract 측 문제를 패치했으며 피해 사용자는 전액 보상받을 것이라고 밝혔습니다.
온체인 활동에 따르면 9월 30일 미국 동부 시간 오후에 10 USDT 및 11 USDT의 소액 전송이 자금이 유출된 contract에서 발생했습니다. 이러한 소액 전송은 공격자가 더 큰 규모의 탈취를 시도하기 전에 출금, 회계 또는 해제 경로가 예상대로 동작하는지 테스트하는 검증 단계와 일치합니다.
이후 9월 30일 23:54 UTC부터 10월 1일 06:08 UTC까지 5건의 대규모 전송이 발생했습니다. 각 전송 규모는 약 $35,000에서 $1.5M에 이르렀습니다. 보안 분석에서는 BNB Smart Chain hot wallet에서 $3.865M의 손실이 발생한 것으로 평가했으며, 별도의 온체인 추적에서는 자금이 유출된 contract에서 약 3.87 million USDT가 수집된 것으로 확인됐습니다.
NEAR Intents는 10월 1일 약 12:53 UTC에 exploit를 공개했습니다. 프로토콜은 SHIELD가 비정상 활동을 감지한 후 서비스가 중단됐으며, 약 1시간 내에 contract 수정이 적용됐다고 밝혔습니다. 인프라가 복구되는 동안 11개 네트워크 전반의 deposit 및 withdrawal은 약 12시간 더 사용할 수 없을 것으로 예상됐습니다.
| 사고 단계 | 날짜 또는 시간 | 구체적 사건 | 보안상 의미 |
|---|---|---|---|
| 초기 탐색 | 9월 30일, 미국 동부 시간 오후 | 10 USDT 및 11 USDT가 자금이 유출된 BNB Chain contract에서 출금됨 | 소액 전송은 자산 해제 경로가 악용 가능한지 드러낼 수 있음 |
| 주요 자금 유출 시작 | 9월 30일, 23:54 UTC | 5건의 대규모 전송 중 첫 번째가 시작됨 | exploit가 탐색 단계에서 자금 탈취 단계로 전환됨 |
| 주요 자금 유출 종료 | 10월 1일, 06:08 UTC | 5번째 대규모 전송이 완료됨 | 확인 가능한 자금 탈취 기간은 여러 시간에 걸쳐 지속됨 |
| 공개 발표 | 10월 1일, 약 12:53 UTC | NEAR Intents가 서비스 중단 및 인프라-contract 상호작용 버그를 공개함 | 사고 커뮤니케이션은 온체인 자금 유출 이후에 이루어짐 |
| 반환 기한 발표 | 10월 2일, 00:18 UTC | 자금 반환을 위한 48시간 기간이 제시됨 | 명시된 기한은 약 10월 4일, 00:18 UTC까지였음 |
공개적으로 보고된 영향 자산은 BNB Chain의 USDT였습니다. 이는 NEAR 기본 네트워크의 침해나 모든 NEAR Intents 자산에 대한 일반적 장애가 아니라 애플리케이션 및 bridge 인프라 사고라는 점에서 중요합니다.
NEAR Intents는 약 35개 blockchain에 걸쳐 $30B 이상을 처리했으며, dashboard는 9월 22일 기준 누적 거래량 $31.4B를 보여줬습니다. 이 정도의 routing 규모를 갖춘 시스템에는 안전한 smart contract만 필요한 것이 아닙니다. 체인 간 일관된 상태 가정, bridge 운영자, settlement contract, 모니터링 시스템 및 운영상 중단 절차가 필요합니다.
NEAR Intents는 일반적으로 체인 간 자산을 어떻게 이동시키나요?
NEAR Intents는 deposit된 token 잔액의 ledger를 유지하고, swap 발생 시 해당 기록을 업데이트하며, withdrawal 및 bridge 경로를 통해서만 token을 해제하는 intents.near Verifier contract를 통해 사용자가 지시한 cross-chain 결과를 settlement합니다. 이번 exploit는 deposit 및 withdrawal 인프라가 해당 settlement 계층과 상호작용하는 경계와 관련이 있습니다.
NEAR Intents 사용자는 모든 실행 단계를 직접 지정하는 대신 의도한 결과에 서명합니다. Solver와 market maker는 그 결과를 이행하기 위해 경쟁하며, 선택된 결과는 온체인에서 settlement됩니다. 이 모델은 cross-chain 실행을 개선할 수 있지만 광범위한 신뢰 및 검증 표면도 만듭니다. 즉, settlement ledger는 무엇이 deposit됐는지, 무엇이 교환됐는지, 무엇을 withdrawal할 수 있는지를 정확히 인식해야 합니다.
NEAR Intents 문서는 서로 다른 신뢰 모델을 가진 3개의 bridge 시스템을 식별합니다.
- Near One이 운영하는 Omni Bridge.
- POA Bridge.
- HOT Bridge.
HOT Bridge 설계는 공개 분석에서 자금이 유출된 BNB Chain contract가 NEAR Intents 문서에 기재된 기본 NEAR Intents vault가 아니라 HOT Bridge treasury address로 식별됐기 때문에 이번 사고 분석과 특히 관련이 있습니다. 이러한 연결은 최종적인 공식 root-cause 판단이 아닌 분석이며, 10월 2일 기준 NEAR Intents는 어떤 컴포넌트가 실패했는지 확인하지 않았습니다.
HOT Bridge에서는 지원되는 각 체인의 locker contract가 native asset을 보관합니다. NEAR의 contract는 일대일 관계로 대응하는 omni-token을 mint합니다. Validator MPC signature는 deposit 및 withdrawal을 승인하며, 설계상 각 nonce는 단 한 번만 사용돼야 합니다.
이 아키텍처에는 타협할 수 없는 몇 가지 보안 속성이 있습니다.
- BNB Chain에서의 자산 해제는 실제 lock, debit 또는 settlement된 entitlement에 대응해야 합니다.
- deposit message는 실행 이후 replay될 수 없어야 합니다.
- signer 승인은 정확한 체인, asset, 수령인, 금액 및 nonce에 바인딩돼야 합니다.
- 외부 컴포넌트가 유효하다고 주장한다는 이유만으로 withdrawal request가 승인되어서는 안 됩니다.
- treasury 잔액은 ledger 및 승인된 bridge 상태와 지속적으로 reconciliation돼야 합니다.
Soken에서 smart contract를 감사해 온 당사의 경험상, 가장 위험한 bridge 실패는 시스템 경계에서 발생합니다. contract가 로컬 규칙을 정확히 적용하더라도 upstream message, off-chain 서비스 또는 cross-chain 회계 가정이 충분한 독립 검증 없이 승인되면 자산을 해제할 수 있습니다.
중단된 11개 네트워크는 NEAR Intents 문서의 HOT Bridge 체인 목록과 일치했습니다. BNB Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll, Plasma입니다. Ethereum, Base, Arbitrum, Solana 및 Bitcoin은 중단되지 않았습니다. 일치하는 체인 목록은 HOT Bridge 중심 가설을 뒷받침하지만, 정확한 취약 컴포넌트를 입증하지는 않습니다.
버그에 관해 알려진 사항과 아직 알려지지 않은 사항은 무엇인가요?
NEAR Intents는 Omni 입출금 인프라와 NEAR Intents smart contract 간 상호작용에 버그가 존재했음을 확인했지만, 10월 2일까지 정확한 컴포넌트나 취약점 클래스는 공개하지 않았습니다. 해당 문제가 확정적으로 signature 우회, replay 결함, 회계 오류 또는 validator 침해라고 주장하는 것은 현재 उपलब्ध한 증거를 넘어서는 것입니다.
“상호작용”이라는 표현이 핵심입니다. 이는 취약점이 반드시 하나의 contract function에 존재하는 단순한 고립형 코딩 결함은 아닐 수 있음을 시사합니다. cross-chain 시스템은 개별적으로는 합리적인 두 컴포넌트가 상태 전환의 의미, finality 또는 고유성에 관해 서로 다르게 해석할 때 흔히 실패합니다.
예를 들어, off-chain 컴포넌트가 final 상태가 아니었던 이벤트에 대한 승인을 생성하거나, contract가 withdrawal message를 영구적으로 소모하지 않고 수락하거나, 회계 계층이 기초 locker가 실제로 수령하지 않은 잔액을 credit하면 bridge 자산 해제 경로가 실패할 수 있습니다. 이들은 서로 다른 기술적 메커니즘이지만, 동등한 lock asset 또는 유효한 debit 없이 자산이 해제된다는 동일한 보안 실패를 공유합니다.
NEAR Intents 사건은 확인된 세부 사항에서는 차이가 있지만, 여러 주요 bridge 사고와 유사한 일반적 형태를 보입니다.
| 사고 | 날짜 | 보고된 손실 | 확인된 실패 형태 |
|---|---|---|---|
| Wormhole | 2022년 2월 | 약 $325M | signature 검증 버그로 guardian 승인이 위조됐으며 collateral 없이 120,000 wETH가 mint됨 |
| Nomad | 2022년 8월 | 약 $190M | upgrade가 신뢰된 root를 zero로 설정하여 모든 message가 입증된 것으로 처리됨 |
| LayerZero를 통한 Kelp DAO | 2026년 4월 | 약 $292M에서 $293M | 1-of-1 verifier 구성으로 인해 phantom burn이 Ethereum에서 자금 해제를 가능하게 함 |
| Liquid Network | 2026년 9월 6일 | 약 $320M | range-proof 검증 cache 버그로 뒷받침되지 않은 L-BTC가 실제 BTC로 peg out될 수 있었음 |
| NEAR Intents | 2026년 10월 1일 | 약 $3.8M | Omni 입출금 인프라와 NEAR Intents smart contract 간 상호작용에서 확인된 버그 |
Wormhole, Nomad, Kelp DAO 및 Liquid Network는 bridge가 실제 lock 또는 debit에 대응하지 않는 credit, proof 또는 message를 수락했다는 공통적인 해제 측 실패 패턴을 공유합니다. NEAR Intents는 10월 1일 exploit가 정확히 그 메커니즘을 따랐는지 아직 확인하지 않았지만, bridge treasury 맥락상 이 불변성은 post-mortem이 가장 먼저 다뤄야 할 사항입니다.
Ronin Bridge는 유용한 대조 사례입니다. 2022년 3월 Ronin 사고는 9개 validator key 중 5개가 침해된 사건이었습니다. 이는 contract가 뒷받침되지 않은 credit을 정당한 것으로 잘못 인식한 사례라기보다는 주로 key 관리 및 validator threshold 실패입니다.
NEAR Intents는 release 프로세스에 formal verification을 추가하겠다고 약속했습니다. formal method는 bridge 불변성을 직접 인코딩하는 데 사용될 경우 이 분야에서 가치가 있습니다. 유효한 withdrawal은 사용자의 settlement된 entitlement를 초과할 수 없고, withdrawal message는 두 번 실행될 수 없으며, 총 해제량은 bridge 시스템 전반의 검증된 backing을 초과할 수 없습니다.
유사한 인프라를 설계하는 프로토콜의 경우, 각 contract, 서비스 또는 signer domain을 별도의 보안 경계로 취급하기보다 전체 deposit-to-release lifecycle을 technical security reviews로 테스트해야 합니다.
대응 및 containment 결정이 중요한 이유는 무엇인가요?
NEAR Intents는 SHIELD가 비정상 활동을 감지한 후 서비스를 중단하고, 약 1시간 내에 contract 측 취약점을 패치했으며, 영향을 받은 11개 네트워크에서 deposit 및 withdrawal을 중단함으로써 사고를 containment했습니다. 신속한 containment는 추가 탈취를 제한하지만, 완전한 복구는 추적, 법적 대응 강화 및 재개된 bridge 흐름이 수정된 보안 불변성을 충족한다는 입증에 달려 있습니다.
즉각적인 서비스 중단은 불확실성에 대한 적절한 대응이었습니다. cross-chain withdrawal 경로가 backing 없는 자산 해제를 생성할 수 있는 상황에서 정상 운영을 지속하면 제한적인 exploit가 더 광범위한 treasury 고갈 사고로 확대될 수 있습니다. 그 대가로 정상 사용자에게 심각한 서비스 중단이 발생하므로, bridge 중단 통제는 세분화되고, 반복 훈련되며, 관측 가능해야 합니다.
NEAR Intents는 법 집행기관에 사고를 신고했으며, 보안 및 blockchain 분석 파트너와 자금을 추적하고 회수를 추진하고 있다고 밝혔습니다. 공개 보도에 따르면 탈취 자금은 KuCoin으로 전송된 후 Bitcoin으로 bridge됐습니다. 별도의 추적에서는 약 1.5M USDT가 CoW Protocol settlement contract를 통해 이동한 것으로 확인됐습니다.
NEAR Intents 관계자는 exploit 실행자에게 자금 반환을 위한 48시간의 기간을 부여하고 Bitcoin, BNB Chain 및 Solana의 반환 address를 공개했으며, 명시된 bounty는 제공하지 않았습니다. 10월 2일 기준 자금 반환이나 상환 일정은 보고되지 않았습니다.
보상 약속도 중요합니다. NEAR 공동 창립자인 Illia Polosukhin은 모든 피해 사용자가 전액 보상받을 것이라고 밝혔습니다. 이 약속은 고객 영향을 다루지만, 영향받은 경로를 복구하기 전에 정확한 post-mortem 및 remediation 기록을 공개해야 한다는 기술적 요구사항을 대체하지는 않습니다.
유용한 사고 후 대응 패키지에는 다음이 포함돼야 합니다.
- 정확한 취약 컴포넌트 및 버그 클래스.
- exploit 경로를 제거하는 contract 및 인프라 변경 사항.
- message, nonce, ledger, signer 또는 reconciliation 불변성 중 어떤 것이 실패했는지 여부.
- 수정 사항에 대한 독립적 검토 결과.
- BNB Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll 및 Plasma에 대한 체인별 복구 계획.
- 동일한 비정상 withdrawal 형태를 더 일찍 탐지할 수 있는 모니터링 규칙.
이번 사고는 코드 외의 거버넌스 및 운영 문제도 제기합니다. 반환 address 공개, 자금 추적, exchange 조율, 사용자 보상 및 법 집행기관 대응은 각각 법률 및 공시 결정을 수반합니다. bridge 복구 절차를 준비하는 팀은 특히 custody, 사용자 청구, sanctions screening 또는 국경 간 자금 회수가 관련될 수 있는 경우 기술 통제를 legal and compliance support와 연계해야 합니다.
NEAR Intents 사고 이후 cross-chain 팀은 무엇을 바꿔야 하나요?
cross-chain 팀은 모든 bridge withdrawal을 가치 보존 증명으로 취급해야 합니다. 자산 해제는 검증된 lock 또는 debit, 고유한 message, 특정 목적지 및 제한된 금액에 바인딩돼야 합니다. NEAR Intents 사고는 모니터링과 비상 중단이 필수적임을 보여주지만, 예방은 잘못된 컴포넌트 간 상태가 승인되는 것을 불가능하게 만드는 데 달려 있습니다.
첫 번째 엔지니어링 과제는 bridge의 핵심 불변성을 비즈니스 및 기술적 용어로 정의하는 것입니다. HOT Bridge 스타일 시스템에서 그 불변성은 단순히 “MPC signature가 유효하다”가 아닙니다. 더 정확하게는 “이 정확한 withdrawal은 이에 상응하는 finalised 상태이며 사용되지 않은 deposit 또는 ledger debit 이후에, 이 asset과 수령인을 위해 단 한 번 승인된다”에 가깝습니다.
이 불변성은 다음과 같은 실패 모드 전반에서 테스트돼야 합니다.
- 중복 message 및 nonce 재사용;
- 일치하지 않는 체인 식별자;
- 일치하지 않는 token address 또는 decimal 변환;
- 오래된 signer 승인;
- 부분적인 인프라 장애;
- 일관되지 않은 ledger 및 locker 잔액;
- 비상 중단 전환;
- upgrade 또는 contract migration 이후의 replay 시도.
둘째, 프로토콜은 탐지와 신뢰를 분리해야 합니다. SHIELD는 NEAR Intents 사고 동안 비정상 활동을 감지했고, 이는 containment를 촉발하는 데 도움이 됐습니다. 하지만 모니터링이 회계 오류와 treasury 손실 사이의 유일한 장벽이 되어서는 안 됩니다. 모니터링 시스템은 의심스러운 행동이 시작된 후 이를 식별합니다. contract 및 bridge 검증 규칙은 전송이 실행 가능해지기 전에 잘못된 가치 이동을 거부해야 합니다.
셋째, 팀은 source-chain lock, settlement-ledger credit, destination-chain release 및 미결 withdrawal 승인 내역을 비교하는 reconciliation을 구축해야 합니다. 불일치가 발생하면 자동으로 한도를 축소하거나 영향받은 경로를 중단해야 합니다. 이 통제는 유효해 보이는 트랜잭션이 그렇지 않으면 유동 자산을 신속하게 이동시킬 수 있는 hot-wallet 및 treasury 경로에서 특히 중요합니다.
넷째, formal verification은 산술적 안전성만이 아니라 bridge 비즈니스 모델에 중요한 속성을 대상으로 해야 합니다. NEAR Intents의 formal verification 도입 약속은 deposit, solver settlement, bridge message 생성 및 withdrawal 실행 전반의 상태 전환을 포괄한다면 올바른 방향입니다. 외부 인프라 컴포넌트가 잘못됐지만 승인된 전제를 해당 function에 제공할 수 있다면, 하나의 contract function에 대한 formal proof만으로는 충분하지 않습니다.
Soken의 research hub는 로컬 contract 검사와 시스템 전반의 보안 보장 간 차이를 포함하여 반복적으로 발생하는 smart contract 및 프로토콜 보안 실패 모드를 분석합니다. bridge 팀에 대한 실무적 교훈은 일관됩니다. audit 범위에는 contract, message 형식, signer 정책, 운영 통제, 모니터링 telemetry 및 복구 절차가 포함돼야 합니다.
이제 NEAR Intents는 약속한 post-mortem을 검증 가능한 복구 계획으로 전환해야 합니다. 실패한 상호작용을 식별하고, 수정된 경로가 backing 없는 USDT를 해제할 수 없는 이유를 입증하며, 재개되는 모든 HOT Bridge 경로를 독립적으로 테스트해야 합니다. 유사한 cross-chain 인프라를 운영하는 팀은 모든 withdrawal 승인을 그 기반이 되는 lock 또는 debit에 매핑하는 것부터 시작한 뒤, 재시도, 지연, upgrade 및 적대적인 message 순서에서도 그 연결이 유지되는지 테스트해야 합니다.