주간 Web3 보안 사고 요약 | 2026년 4월 6일 – 4월 12일

지난 한 주(2026/04/06 - 2026/04/12) 동안 BlockSec은 네 건의 공격 사건을 탐지하고 분석했으며, 총 추정 손실액은 약 $928.6K입니다. 아래 표는 이번 사건들을 요약한 것이며, 각 사례에 대한 상세 분석은 다음 하위 섹션에서 제공됩니다.

*Denaria 사건은 지난주 보고서에서 다루지 않았으며, 완전한 기록을 위해 이번에 포함되었습니다.

이번 주부터 각 보고서의 상단에 주목할 사건 하나를 강조합니다. 선정 기준은 반드시 손실 규모에 따른 것이 아니며, 참신한 프로토콜 설계, 독창적인 공격 기법, 또는 커뮤니티에 주는 더 넓은 교훈을 기준으로 선택될 수 있습니다.

주간 하이라이트: Denaria 사건

퍼페추얼 DEX Denaria는 복잡한 코드 로직으로 뒷받침된 참신한 회계 메커니즘을 도입했습니다. 그러나 감사 이후 진행된 리팩터링에서 반올림 비대칭이 발생했고, 이는 미묘한 엣지 케이스인 음수 값을 생성할 수 있었으며, 결국 안전하지 않은 형변환을 통해 천문학적인 금액 탈취가 가능해졌습니다.

2026년 4월 5일, Linea 체인의 퍼페추얼 DEX Denaria가 약 $165.6K의 손실을 입는 공격을 받았습니다. 근본 원인은 getLpLiquidityBalance()에서 발생한 두 가지 복합적 결함이었습니다. 감사 이후 진행된 LP 잔액 회계 리팩터링에서 반올림 비대칭이 도입되어 약간의 음수 중간값이 생성될 수 있었고, 안전하지 않은 int256에서 uint256으로의 형변환이 해당 음수 값을 되돌리는 대신 조용히 거의 최대에 가까운 부호 없는 정수로 래핑했습니다. 공격자는 단일 사이드 LP 예치와 롱 포지션 거래를 통해 이를 악용하고, 볼트에서 인위적으로 부풀려진 PnL을 출금했습니다.

배경

Denaria는 동적 가상 AMM을 기반으로 구축된 Linea의 퍼페추얼 DEX입니다. 거래와 정산을 두 가지 구성 요소로 분리합니다. PerpPair 마켓은 사용자 포지션과 LP 회계를 관리하고, Vault는 담보를 보유하고 실현 PnL을 정산합니다.

PerpPair에서 LP 소유권은 명시적인 토큰 잔액으로 표현되지 않습니다. 대신, 프로토콜은 자산 사이드와 스테이블 사이드로 구성된 두 가지 장부 구성 요소로 이루어진 내부 회계 매트릭스에서 각 LP의 상태를 재구성합니다. 자산 사이드는 가격 변동에 대한 풀의 노출에서 LP의 지분을 추적하고, 스테이블 사이드는 풀의 스테이블 표시 가치에서 LP의 지분을 추적합니다. 이 두 구성 요소는 함께 LP의 가치가 추적되고 정산되는 방식을 결정합니다.

중요한 점은, 이러한 구성 요소들이 정적 스냅샷으로 저장되지 않는다는 것입니다. 거래가 발생할 때마다 PerpPair는 전역 유동성 상태를 업데이트하고, 각 LP의 재구성된 잔액은 누적 전역 값과 LP의 진입점 스냅샷 간의 차이에서 도출됩니다. 이 회계 메커니즘은 감사 이후 리팩터링에서 원래의 지분 기반 누산기를 직접 잔액 추적으로 대체하면서 도입되었습니다. 그러나 리팩터링된 감산 경로에서 반올림 비대칭이 도입되어, 특정 거래 순서에서 재구성된 LP 구성 요소가 약간 음수가 될 수 있었습니다.

취약점 분석

취약한 PerpPair 컨트랙트(0xb683...36ae17)에는 두 가지 복합적 결함이 있습니다.

1. 리팩터링된 회계에서의 반올림 비대칭. 직접 잔액 추적을 도입한 감사 이후 리팩터링은 감산 재구성 경로에서 반올림 비대칭을 생성했습니다. 특정 거래 순서에서 반올림 후 전역 누적 값이 LP의 진입점 스냅샷보다 약간 작아져, 감산 결과가 0 대신 작은 음수가 될 수 있었습니다. 이론적으로 이 값은 0이거나 0에 가까워야 했습니다. 이 비대칭은 감산 회계의 고유한 특성이 아니라 이 리팩터링된 구현에 특유한 결함이었습니다.

2. 안전하지 않은 부호 있는 정수에서 부호 없는 정수로의 형변환. getLpLiquidityBalance()에서 재구성된 LP 잔액 구성 요소가 검증 없이 int256에서 uint256으로 형변환되었습니다. Solidity에서 음수 int256을 uint256으로 형변환하면 되돌리지 않고 2^256로 모듈로 연산한 값으로 래핑되어, -1 같은 작은 음수가 거의 최대에 가까운 부호 없는 정수(2^256 - 1)로 변환됩니다. 이 재구성된 잔액이 정산을 위한 calcPnL()에 입력되었기 때문에, 음수 입력은 엄청난 LP 포지션으로 해석되어 공격자가 인위적으로 부풀려진 이익을 실현하고 볼트에서 자금을 탈취할 수 있었습니다.

어떤 결함도 단독으로는 악용될 수 없었습니다. 반올림 비대칭은 약간의 음수 값만 생성했으며, 일반적인 int256 산술에서는 단순히 무시할 수 있는 오류를 나타냈을 것입니다. 그러나 그 음수 값이 보호되지 않은 형변환에 도달하면 거의 최대에 가까운 부호 없는 정수로 래핑됩니다. 이후의 경계 검사는 래핑된 값을 풀의 총 자산 사이드 유동성으로 제한하여, 결과적으로 오버플로를 시장의 전체 자산 사이드에 대한 청구권으로 전환했습니다.

공격 분석

다음 분석은 공격 트랜잭션 0xcb0744...0c606447을 기반으로 합니다.

• 1단계: 공격자는 Aave 플래시 론을 통해 60,000 USDC를 대출했습니다.

• 2단계: 헬퍼 주소가 30,000 USDC를 담보로 예치하고 19,980 스테이블 토큰의 스테이블 전용 LP 포지션을 추가했습니다. 스테이블 사이드에만 예치함으로써, 헬퍼는 자산 사이드 LP 구성 요소가 거의 0에서 시작하도록 하여 반올림으로 인해 음수 영역으로 넘어가기 더 쉽게 만들었습니다.

• 3단계: 두 번째 헬퍼 주소가 15,000 USDC를 예치하고 100,000 명목 롱 포지션을 열어, 핵심 반올림 오류를 도입하는 liquidityM 업데이트를 발생시켰습니다. 풀의 유동성 대비 큰 명목 규모가 거래당 반올림 영향을 증폭시켜, 첫 번째 헬퍼의 재구성된 자산 사이드 잔액을 0 아래로 밀어냈습니다.

• 4단계: 첫 번째 헬퍼가 realizePnL()을 호출했습니다. LP 잔액 재구성 중에 음수 lpAssetBalance가 거의 최대에 가까운 uint256으로 래핑되었습니다. 이 큰 값은 시장의 전체 자산 사이드 유동성으로 제한되어 크게 부풀려진 이익을 생성했습니다. 사실상 프로토콜은 LP가 시장의 전체 자산 사이드를 소유하고 있다고 믿게 되었습니다.

• 5단계: 공격자는 볼트에서 부풀려진 PnL을 출금했습니다.

동일한 패턴이 남은 볼트 유동성이 소진될 때까지 반복되었습니다. 플래시 론을 상환한 후, 공격자는 약 $165.6K의 이익을 실현했습니다.

결론

이 익스플로잇은 궁극적으로 부호 있는 정수에서 부호 없는 정수로의 변환에서 경계 검증이 누락되어 발생했습니다. 즉각적인 수정은 간단합니다. 단순 형변환을 SafeCast.toUint256()으로 교체하면 래핑하는 대신 음수 입력 시 되돌립니다.

더 넓은 관점에서, 이 사건은 외부 검토를 우회하는 감사 이후 리팩터링의 위험성을 보여줍니다. 공식 사후 분석에 따르면, 반올림 비대칭은 팀이 원래의 누산기를 직접 잔액 추적으로 대체한 최종 외부 감사 이후에 도입되었습니다. 리팩터링이 오버플로 우려를 해결했지만, 내부 테스트에서 발견하지 못한 새로운 엣지 케이스를 만들었습니다. 프로토콜이 핵심 회계 로직을 리팩터링할 때, 특히 재구성된 값이 PnL 정산이나 출금 로직에 직접 입력되는 경우, 새로운 코드 경로는 보안에 중요한 것으로 간주하고 재감사해야 합니다.

HB Token 사건

2026년 4월 7일, BNB 체인에서 매수/매도 훅이 내장된 커스텀 ERC-20 토큰 HB가 약 $193K의 손실을 입는 공격을 받았습니다. 근본 원인은 결함 있는 보상 정산 로직이었습니다. 트리거되면 swapBack()을 호출하는데, 이는 PancakeSwap 쌍에서 직접 HB 준비금을 제거하고 sync()를 호출하여 풀의 가격을 재책정했습니다. 공격자가 쌍의 HB 대부분을 매수한 후, 이어진 swapBack() 실행이 남은 유동성을 더 줄이고 현물 가격을 급격히 높였습니다. 그런 다음 공격자는 왜곡된 풀에 소량의 HB를 팔아 불균형적으로 많은 양의 USDT를 얻었고, 쌍이 소진될 때까지 이 사이클을 반복했습니다.

배경

HB는 BNB 체인의 커스텀 ERC-20 토큰으로, _transfer()에 매수 및 매도 훅이 내장되어 있습니다. 사용자가 AMM 쌍에서 매수할 때, _handleBuy()는 원가 정보를 기록합니다. 사용자가 매도할 때, _handleSell()은 쌍의 상태에 따라 다른 세금 및 정산 경로로 분기됩니다.

토큰에는 swapBack()을 트리거할 수 있는 보상 정산 메커니즘도 포함되어 있습니다. 일반적인 라우터 매개 스왑을 수행하는 대신, swapBack()은 PancakeSwap 쌍에서 PROOF 주소로 직접 HB를 전송한 다음 sync()를 통해 쌍을 강제로 재동기화합니다. 이를 통해 컨트랙트는 일반적인 AMM 거래 흐름 외부에서 쌍의 HB 준비금을 줄이고 즉시 풀을 상향 재책정할 수 있습니다.

취약점 분석

HB 토큰 컨트랙트(0x62ce...87a4b0)의 핵심 결함은 swapBack()이 treasury나 라우터 매개 스왑을 통하지 않고 AMM 쌍에서 직접 토큰을 가져와 보상 재원을 마련했다는 것입니다. swapBack()이 보상 정산 경로를 통해 접근 가능했기 때문에, 비거래 코드 경로가 쌍 준비금을 직접 변경하고 현물 가격을 변경할 수 있었습니다.

쌍의 HB 준비금이 낮을 때, swapBack() 호출은 남은 HB를 더 줄이고 가격 왜곡을 증폭시켜, 극도로 부풀려진 가격에 소량의 HB를 팔 수 있게 했습니다.

공격 분석

다음 분석은 공격 트랜잭션 0x19671f...d71594ed을 기반으로 합니다.

• 1단계: 공격자는 Venus에서 대량의 자금을 대출했습니다.

• 2단계: 공격자는 약 1,496 HB를 토큰 컨트랙트에 전송하여 컨트랙트의 HB 잔액을 늘렸으며, 이후 swapBack()이 쌍에서 더 많은 양을 가져올 수 있도록 했습니다.

• 3단계: PancakeSwap 쌍에 소량의 HB를 전송함으로써, 공격자는 _swapAndLiquify()를 트리거하여 토큰 컨트랙트가 보유한 약 4,163 HB를 10 USDT로 교환하고 공격자의 청구 가능한 HB 보상을 증가시켰습니다.

• 4단계: 공격자는 72,117,360 USDT를 사용하여 73,608,753 HB를 매수하여, 쌍에 남은 HB 유동성이 매우 적게 되었습니다.

• 5단계: 다음으로, 공격자는 보상 부족 경로를 트리거했습니다. 보상을 충족시키기 위해 토큰이 swapBack()을 호출하여 PancakeSwap 쌍에서 추가 HB를 가져오고 sync()를 강제 실행하여 HB 가격을 급격히 올렸습니다.

• 6단계: 공격자는 쌍의 USDT 준비금을 보충하기 위해 직접 USDT를 쌍에 전송한 다음, 왜곡된 가격으로 단 0.000582 HB만 팔아 37,582,322 USDT를 획득했습니다.

6단계를 반복하여 왜곡된 가격에 HB 토큰을 매도함으로써, 공격자는 풀에서 거의 모든 USDT를 추출했습니다.

결론

HB 토큰 사건은 보상 로직이 AMM 준비금을 직접 변경하도록 허용하는 것이 얼마나 위험한지를 보여줍니다. 준비금에 영향을 미치는 함수는 보상 정산 경로에서 절대 접근 가능해서는 안 되며, 프로토콜은 보안에 민감한 제어 흐름에서 내부 토큰 잔액과 AMM 준비금 회계를 혼용하지 않아야 합니다. 내부적으로 풀을 교란한 후 현물 AMM 가격에 의존하는 설계는 본질적으로 가격 조작에 취약합니다.

Squid Multicall 사건

2026년 4월 7일, Squid 사용자가 승인 관련 사건으로 여러 체인에 걸쳐 약 $517K의 손실을 입었습니다. 사용자가 의도한 Squid Router 대신 실수로 SquidMulticall 컨트랙트를 승인했습니다. 이로 인해 공격자는 권한 없이 접근 가능한 SquidMulticall.run() 함수를 호출하여 임의의 외부 호출을 실행할 수 있었습니다. 따라서 공격자는 컨트랙트에 승인된 모든 허용량을 사용하여 이를 승인한 사용자에 대해 토큰 transferFrom() 호출을 실행할 수 있었습니다.

배경

Squid의 일반적인 흐름에서 사용자는 Squid Router를 승인해야 하며, SquidMulticall은 실행 헬퍼로만 작동합니다. 헬퍼 컨트랙트는 라우팅 로직의 일부로 배치된 호출을 실행하도록 설계되었지만, 사용자가 토큰 전송을 위해 직접 승인하는 지출자가 되어서는 안 됩니다.

ERC-20 허용량 검사는 지출자 주소에 대해서만 수행되기 때문에, 사용자 승인과 무제한 임의 호출 기능을 결합한 모든 컨트랙트는 위험한 승인 싱크를 만듭니다. 일단 승인되면, 누군가가 어떤 호출을 할지 제어할 수 있다면 해당 컨트랙트는 일반적인 토큰 인출 벡터가 될 수 있습니다.

취약점 분석

이 사건은 스마트 컨트랙트 취약점으로 인한 것이 아닙니다. 손실은 두 가지 조건이 동시에 발생하여 초래되었습니다. Router 대신 SquidMulticall을 대상으로 한 잘못된 승인과, 임의의 호출자로부터 임의의 대상과 calldata를 허용하는 run()의 무허가 설계입니다.

SquidMulticall은 Router의 흐름에서 다운스트림 단계로 배치된 호출을 실행하도록 의도되었으며, 입력은 신뢰할 수 있는 라우팅 로직에 의해 구성됩니다. 의도한 대로 사용되면 무허가 설계는 위험하지 않습니다. 그러나 잘못된 승인은 이를 완전히 바꿉니다. MEV 봇이 활성화된 허용량을 감지하고, 조작된 calldata로 run()을 호출하여 transferFrom(victim, attacker, amount)를 실행하고, 피해자로부터 추가 조치 없이 각 체인에서 승인된 토큰을 탈취했습니다.

공격 분석

이 사건은 BNB 체인, Arbitrum, Optimism, Avalanche, Base 전반에 걸쳐 한 사용자에게 영향을 미쳤습니다. 다음 분석은 공격 트랜잭션 0x81d0c4...9b1301e9을 기반으로 합니다.

• 1단계: 피해자(0xacc0...f40e98)가 의도한 Squid Router 대신 실수로 SquidMulticall을 승인했습니다.

• 2단계: MEV 봇이 이 허용량을 감지하고 조작된 calldata로 SquidMulticall.run()을 호출했습니다.

• 3단계: 임의 호출을 통해 SquidMulticall이 transferFrom(victim, attacker, amount)를 실행하여 피해자의 지갑에서 승인된 자산을 전송했습니다.

결론

이 사건은 무허가 임의 호출 컨트랙트가 사용자 대면 승인 흐름과 공존할 때의 위험성을 보여줍니다. 직접적인 원인은 잘못된 승인이었으며, SquidMulticall이 무제한 호출자, 임의의 대상, 임의의 calldata를 허용했기 때문에 잘못 지시된 모든 승인은 즉시 완전히 악용 가능했습니다. 실행 헬퍼 컨트랙트를 사용하는 프로토콜은 호출자 제한을 추가하거나 해당 함수가 허용하는 호출 대상을 제한하는 것을 고려해야 하며, 그래야 잘못된 승인이 쉽게 무기화될 수 없습니다.

XBIT 사건

2026년 4월 11일, BNB 체인의 XBIT 토큰이 약 $53K의 손실을 입는 공격을 받았습니다. 근본 원인은 XBITVault에서 열린 상태로 실패하는 접근 제어 결함이었습니다. transfer() 함수의 권한 검사는 조건부였으며, xbitContract가 0이 아닌 경우에만 msg.sender == xbitContract를 강제했고, 그렇지 않으면 조용히 통과했습니다. bindXBIT()가 컨트랙트를 초기화하기 위해 한 번도 호출되지 않았기 때문에, 이 결함은 영구적으로 노출되어 임의의 호출자가 XBIT/USDT PancakeSwap 쌍을 포함한 모든 주소에서 XBIT 잔액을 이동할 수 있었습니다. 공격자는 이를 사용하여 쌍에서 XBIT를 탈취한 다음, 소량의 XBIT를 풀에 반복적으로 팔아 불균형적으로 많은 양의 USDT를 획득했습니다.

배경

XBITVault는 수동적인 treasury 컨트랙트가 아닙니다. 이는 XBIT 토큰 시스템의 잔액 및 허용량 백엔드로, transfer(), approve(), mintForXBIT()와 같은 토큰 유사 함수를 노출합니다. 의도된 설계에서 소유자는 먼저 bindXBIT()를 호출하여 xbitContract, pancakePair, pairContract, xbitDecimals를 설정함으로써 볼트를 초기화해야 합니다. 초기화 후, 민감한 상태 변경 함수는 바인딩된 XBIT 컨트랙트에 의해서만 호출 가능하도록 설계되었습니다. 즉, 볼트의 보안 모델은 공개 사용 전 성공적인 초기화에 의존합니다.

취약점 분석

핵심 결함은 취약한 XBITVault 컨트랙트(0xc879...42391a)에서 접근 제어가 조건부라는 것입니다. transfer() 함수는 xbitContract != address(0)일 때만 msg.sender == xbitContract를 확인합니다. 즉, xbitContract가 설정되지 않은 경우 함수는 되돌리지 않고 누구나 공개적으로 호출할 수 있게 됩니다. 잔액이 _balances에 저장되어 있으므로, 소스 주소에 충분한 잔액이 있는 한 외부 호출자가 어떤 주소에서든 XBIT를 다른 주소로 이동할 수 있습니다.

의도된 초기화 경로는 bindXBIT()였지만, 한 번도 호출되지 않았기 때문에 볼트는 초기화되지 않은 열린 상태로 남아 있었습니다. 그 결과는 사실상 무제한 임의 잔액 전송 기본 요소였습니다.

공격 분석

다음 분석은 공격 트랜잭션 0xbc877f...4df1b694을 기반으로 합니다.

• 1단계: 무제한 transfer() 함수를 통해, 공격자는 어떠한 USDT도 제공하지 않고 XBIT/USDT 쌍에서 1,526,216.569 XBIT를 이동시켰습니다.

• 2단계: 공격자는 sync()를 호출하여 쌍의 XBIT 준비금을 단 1-2 단위로 붕괴시켰습니다.

• 3단계: 쌍에 거의 0에 가까운 XBIT 유동성이 남은 후, 공격자는 XBIT를 반복적으로 팔아 쌍에서 약 53,112 USDT를 탈취했습니다.

결론

이 사건은 초기화에 의존하는 접근 제어 검사가 열린 상태로 실패하여 발생했습니다. xbitContract가 설정되지 않은 경우 transfer()는 제한이 없었으며, bindXBIT()가 한 번도 호출되지 않았기 때문에 볼트는 공개적인 임의 잔액 전송 기본 요소를 영구적으로 노출했습니다. 권한 있는 함수는 초기화가 완료될 때까지 되돌려야 하며, 배포 시 바인딩 단계는 운영상의 가정이 아닌 온체인 강제 전제 조건이어야 합니다.

BlockSec 소개

BlockSec은 풀스택 블록체인 보안 및 암호화폐 컴플라이언스 제공업체입니다. 저희는 고객이 코드 감사(스마트 컨트랙트, 블록체인, 지갑 포함)를 수행하고, 실시간으로 공격을 차단하며, 사고를 분석하고, 불법 자금을 추적하고, 프로토콜과 플랫폼의 전체 수명 주기에 걸쳐 AML/CFT 의무를 이행할 수 있도록 돕는 제품과 서비스를 구축합니다.

BlockSec은 권위 있는 학회에서 다수의 블록체인 보안 논문을 발표하고, 여러 DeFi 애플리케이션의 제로데이 공격을 보고하며, 2천만 달러 이상을 구조하기 위해 여러 해킹을 차단하고, 수십억 달러의 암호화폐를 보호했습니다.

• 공식 웹사이트: https://blocksec.com/

• 공식 트위터 계정: https://twitter.com/BlockSecTeam

• 🔗 BlockSec 감사 서비스 : 요청 제출

• 🔗 Phalcon Security APP: 데모 예약

• 🔗 Phalcon Compliance