Injective 인젝티브(INJ)에서 ‘치명적 취약점’을 제보한 화이트햇 해커가 프로젝트 측의 대응을 공개 비판하며 논란이 커지고 있다. 해커는 수개월간 연락이 끊긴 데다 버그바운티도 ‘최대치 대비 10분의 1’ 수준으로 제시받았다고 주장했다.
익명의 암호화폐 보안 연구자 ‘al_f4lc0n’은 최근 깃허브(GitHub)에 ‘injective-wall-of-shame’라는 저장소를 만들고, 인젝티브의 취약점 제보 과정과 보상 협의를 둘러싼 갈등을 상세히 공개했다. 이 취약점은 잘못된 검증 시스템으로 인해 최대 5억달러(약 7,454억5,000만원·1달러=1,490.90원 기준)가 위험에 노출될 수 있었다는 게 보고서의 핵심이다.
al_f4lc0n은 저장소 README 제목을 “I Saved Injective’s $500M. They Pay Me $50K(인젝티브의 5억달러를 구했는데 5만달러를 준다고?)”로 달고, 해당 취약점이 “어떤 사용자든 체인 상의 어떤 계정이든 직접 털 수 있다. 특별한 권한이 필요 없다”고 주장했다.
기술 보고서에 따르면 문제의 핵심은 ‘서브계정(subaccount) 검증’이 허술했던 점이다. 공격자는 이 허점을 이용해 다른 이용자 계정 명의로 시장가 주문을 제출할 수 있었고, 결과적으로 피해자 자산이 원치 않는 거래에 동원될 수 있었다는 설명이다.
공격 시나리오는 비교적 단순하다고 보고서는 적었다. 먼저 공격자가 가치 없는 토큰을 만들고, 이를 테더(USDT)와 짝지은 현물 시장을 개설한다. 인젝티브에서는 이 과정이 ‘퍼미션리스(permissionless)’로 가능하다는 주장이다. 이후 공격자가 가짜 토큰의 매도 주문을 내면, 피해자 계정이 공격자가 지정한 가격으로 해당 토큰을 USDT로 ‘강제 매수’하도록 유도할 수 있고, 이렇게 확보한 USDT는 별도 승인 없이 인젝티브에서 이더리움(ETH)으로 브리지 전송할 수 있다고 설명했다.
보고서는 이 문제로 당시 체인 내 가치 전반이 위험에 처했으며, 제보 시점 기준 위험 노출 규모가 5억달러를 넘었다고 주장했다. 다만 현재 해당 규모는 2억8,000만달러(약 4,174억5,200만원) 수준이며, 대부분이 인젝티브(INJ) 토큰에 묶여 있다고 덧붙였다.
인젝티브는 바이낸스, 점프, 구글, 판테라 등을 파트너로 내세우는 블록체인 네트워크로 알려져 있다. 암호화폐 업계에서 버그바운티는 외부 보안 전문가(화이트햇)가 취약점을 제보하면 프로젝트가 보상을 지급하는 방식으로, 상시 모니터링을 ‘크라우드소싱’하는 대표적 보안 체계로 자리 잡았다.
인젝티브는 보안 플랫폼 이뮤너파이(ImmuneFi) 페이지에서 블록체인 및 스마트컨트랙트 관련 ‘치명적 위협(critical)’에 대해 최대 50만달러(약 7억4,545만원) 보상을 내걸고 있다. 그러나 al_f4lc0n은 팀이 취약점의 심각성을 충분히 인지했음에도, 사후 커뮤니케이션이 부실했다고 주장한다.
그는 “버그 수정용 메인넷 업그레이드가 거버넌스 투표로 올라갔다. 인젝티브 팀은 심각성을 분명히 이해하고 있었다”며, 수정 이후 3개월 동안 연락이 사실상 끊겼다고 했다. 이어 뒤늦게 돌아온 제안이 최대치의 10분의 1인 5만달러(약 7,454만5,000원)였고, “명확히 하자면 그 5만달러조차 아직 지급되지 않았다”고 강조했다.
이번 보도와 관련해 매체 프로토스(Protos)는 인젝티브 측에 al_f4lc0n의 주장에 대한 입장을 요청했지만, 기사 발행 전까지 답변을 받지 못했다고 전했다.
결국 이번 논란은 취약점 자체의 기술적 위험뿐 아니라, 프로젝트가 외부 제보를 어떤 기준과 절차로 처리하고 보상을 산정하는지에 대한 신뢰 문제로도 번지고 있다. 디파이(DeFi)와 브리지 연동이 확대될수록 단일 취약점이 연쇄 피해로 이어질 수 있는 만큼, 버그바운티 운영의 투명성과 대응 속도가 보안 경쟁력의 핵심 지표로 재차 부각되는 분위기다.
기사요약 by TokenPost.ai
🔎 시장 해석
- 인젝티브(INJ)에서 ‘권한 없이 타 계정 자금 유출이 가능했다’는 수준의 치명적 취약점 제보가 공개되며, 기술 리스크뿐 아니라 프로젝트 신뢰(거버넌스·보상·대응 프로세스) 문제가 동시에 부각됨
- 디파이/브리지 연동 구조상 단일 취약점이 체인 전반 자산(당시 최대 5억달러 노출 주장)에 연쇄 피해를 유발할 수 있어 “보안 대응 속도·투명성”이 네트워크 프리미엄을 좌우하는 국면
- 버그바운티가 ‘보상 규모’보다도 ‘응답 속도·정산 확실성·분류 기준’에 의해 평판이 갈리는 사례로 확산 중
💡 전략 포인트
- 사용자 관점: 자산을 DEX/파생/브리지에 상시 노출하기보다, 사용량 대비 최소 잔고만 운영하고 브리지 이용 시 단계적 전송(소액 테스트→분할 전송)으로 사고 반경을 축소
- 투자/리스크 관점: (1) 과거 보안 이슈 대응 이력 (2) 버그바운티 지급·커뮤니케이션 사례 (3) 거버넌스 업그레이드 공지의 투명성 을 ‘기술적 펀더멘털’로 함께 점검
- 프로젝트 관점(시사점): 치명적 제보는 ‘확인→패치→공개→보상’의 SLA(응답기한)와 등급 산정 근거를 문서화하지 않으면, 패치가 끝나도 평판 리스크가 장기화될 수 있음
📘 용어정리
- 화이트햇(Whitehat): 시스템을 보호하기 위해 취약점을 찾아 제보하는 윤리적 해커/보안 연구자
- 버그바운티(Bug bounty): 취약점 제보에 대해 프로젝트가 현금·토큰 등으로 보상하는 제도
- 서브계정(Subaccount): 하나의 계정 아래에서 포지션/주문/자산을 분리해 관리하는 하위 계정 구조
- 퍼미션리스(Permissionless): 별도 승인 없이 누구나 기능(시장 생성 등)을 실행할 수 있는 운영 방식
- 브리지(Bridge): 서로 다른 블록체인 간 자산을 이동시키는 연결 인프라(해킹 시 피해가 커지기 쉬움)
Q.
이번 취약점은 사용자에게 어떤 위험을 만들 수 있었나요?
제보 내용대로라면 서브계정 검증 허점으로 인해 공격자가 피해자 명의로 주문을 제출해 원치 않는 거래를 유발하고, 결과적으로 피해자의 USDT 등 자산이 유출될 수 있는 시나리오가 가능했습니다. 특히 브리지로 다른 체인(예: 이더리움)으로 옮길 수 있으면 추적·회수가 더 어려워질 수 있습니다.
Q.
버그바운티 보상 논란은 왜 중요한가요?
버그바운티는 외부 연구자들이 취약점을 조기 발견하도록 만드는 핵심 안전장치입니다. 프로젝트가 치명적 제보에 대해 장기간 미응답이거나, 보상 산정 기준이 불명확하고 지급이 지연되면 연구자들이 ‘비공개 제보’ 대신 ‘공개 폭로’로 전환할 유인이 커져 생태계 신뢰와 보안 수준 모두에 악영향을 줄 수 있습니다.
Q.
초보 사용자는 이런 이슈가 있을 때 무엇을 점검해야 하나요?
(1) 공식 채널의 패치/업그레이드 공지와 적용 여부, (2) 브리지·DEX 등 고위험 기능에 보관 중인 자산 비중, (3) 동일 프로젝트의 과거 보안사고 대응 이력과 버그바운티 운영 투명성을 확인하는 것이 좋습니다. 단기적으로는 사용하지 않는 자산을 지갑/거래소 등으로 분산하고, 브리지 전송은 소액 테스트 후 분할 전송하는 방식이 리스크를 줄이는 데 도움이 됩니다.
TP AI 유의사항
TokenPost.ai 기반 언어 모델을 사용하여 기사를 요약했습니다. 본문의 주요 내용이 제외되거나 사실과 다를 수 있습니다.
<저작권자 ⓒ TokenPost, 무단전재 및 재배포 금지>