주간 Web3 보안 사고 요약 | 2026년 2월 23일 – 3월 1일

지난 한 주(2026/02/23 - 2026/03/01) 동안, BlockSec은 총 7건의 공격 사례를 탐지하고 분석하였으며, 총 추정 손실액은 약 $13M입니다. 아래 표는 각 사례를 요약한 것이며, 각 사례에 대한 상세 분석은 이후 소절에서 제공됩니다.

1. LAXO 사례

간략한 요약

2026년 2월 22일, BNB 스마트 체인의 ERC20 토큰 LAXO가 공격을 받아 LAXO-USDT 페어에서 약 $137,320의 손실이 발생하였습니다. 근본 원인은 LAXO가 PancakeSwap 페어로 직접 전송될 때 활성화되는 결함 있는 소각 메커니즘이었습니다. 라우터는 화이트리스트에 등록되어 있어 transfer()의 소각 로직을 트리거하지 않으므로, 공격자는 이를 우회하였습니다: LAXO를 페어에 전송한 후 페어의 저수준 swap()을 호출하여 페어 토큰을 소각하고 sync()를 호출해 가격을 인위적으로 부풀렸습니다. 그런 다음 공격자는 USDT로 다시 스왑하여 이익을 얻었습니다.

배경

LAXO 토큰은 소각 메커니즘을 구현합니다. 전송의 수신자가 USDT–LAXO PancakeSwap 페어 주소인 경우, 토큰은 이를 매도로 처리합니다: 페어에서 해당 수량의 토큰을 소각하고 sync()를 호출하여 페어의 준비금을 업데이트합니다.

또한, LAXO 토큰은 화이트리스트(_isExcludedFromFee)를 구현하여 특정 주소(예: 스왑 라우터)를 소각 메커니즘과 수수료에서 면제합니다.

취약점 분석

이 사례의 근본 원인은 LAXO 토큰의 결함 있는 소각 메커니즘이었습니다. 구체적으로, LAXO를 페어에 직접 전송하면 소각이 트리거되어 페어에서 LAXO가 제거되고 가격이 부풀려집니다. 그 결과, 공격자는 이를 악용하여 가격 조작 공격을 통해 이익을 실현할 수 있습니다.

공격 분석

공격 분석은 트랜잭션 0xd58f3ef6...d98ac7d3을 기반으로 합니다.

1. 공격자는 PancakeSwap V3에서 350,000e18 USDT를 플래시론으로 빌렸습니다.

2. 공격자는 PancakeSwap 라우터를 통해 USDT를 LAXO로 스왑하였습니다. 거래 제한(buyEnabled = false) 및 수수료 로직을 우회하기 위해, 공격자는 BNB–LAXO V2 페어를 생성하고 이를 통해 거래를 라우팅하였습니다.

3. 공격자는 보유한 모든 LAXO를 USDT–LAXO 페어에 직접 전송하였습니다. 이로 인해 풀의 LAXO 준비금이 감소하는 반면 USDT 준비금은 거의 변화가 없어, USDT–LAXO 페어에서 LAXO의 가격이 급격히 상승하였습니다.

4. 공격자는 조작된 가격을 기반으로 burnAmount의 LAXO를 약 487,500e18 USDT로 스왑하였습니다.

5. 공격자는 플래시론을 상환하고 나머지 USDT를 이익으로 보유하였습니다.

결론

이 사례의 근본 원인은 LAXO의 결함 있는 소각 메커니즘에서 비롯되며, 이로 인해 공격자가 가격 조작 공격을 통해 풀에서 USDT를 탈취할 수 있었습니다. 그 결과, 이 사례에서 총 약 $137.3K의 손실이 발생하였습니다. 이러한 문제를 완화하기 위해, 프로젝트는 잠재적인 가격 조작 공격을 방지할 수 있도록 소각 메커니즘에 대한 포괄적인 테스트를 수행해야 합니다.

2. YieldBloxDAO 사례

간략한 요약

2026년 2월 22일, Stellar의 Blend V2에서 YieldBlox DAO가 운영하는 대출 풀이 공격을 받아 $10M 이상의 손실이 발생하였습니다 [1]. 이 사례는 스마트 컨트랙트의 취약점이 아닌 풀 운영자(YieldBlox DAO)의 잘못된 설정으로 인해 발생하였습니다.

구체적으로, 공격자는 SDEX의 USTRY/USDC 마켓을 조작하였습니다. 풀에 설정된 Reflector 오라클 경로는 조작된 가격을 수용하였으며, 이로 인해 USTRY가 담보로서 과대평가되어 공격자가 USDC 및 XLM을 포함한 풀 자산을 탈취할 수 있었습니다.

배경

Stellar 블록체인에서 Blend V2는 사용자가 격리된 대출 풀을 생성할 수 있게 해주는 유동성 프로토콜입니다. 이러한 풀은 지원되는 자산 집합에 대해 사용자 간 대출 및 차입을 가능하게 합니다. 구체적으로, 이 사례의 피해 풀은 사용자가 USTRY를 담보로 XLM 및 USDC를 차입할 수 있도록 합니다. 또한, 풀 생성자는 생성 시 Reflector 오라클 [2]을 오라클 제공자로 지정합니다. Reflector 오라클이 제공하는 USTRY 가격은 Stellar DEX(즉, SDEX) [3]의 USTRY/USDC 마켓을 기반으로 5분마다 업데이트됩니다.

취약점 분석

근본 원인은 SDEX의 유동성이 낮은 USTRY/USDC 마켓에서의 가격 조작이었으며, 이로 인해 Reflector 오라클의 USTRY 가격이 취약하게 업데이트되었습니다. 구체적으로, USTRY/USDC 마켓의 유동성이 극히 낮았기 때문에, 공격자는 정상 주문을 소진하고 비정상적인 주문을 배치하여 USTRY 가격을 100배 부풀릴 수 있었습니다. 이렇게 부풀려진 USTRY 가격이 Reflector 오라클에 전파되어, 공격자는 과대평가된 USTRY를 담보로 피해 풀의 모든 자산(즉, XLM 및 USDC)을 차입할 수 있었습니다.

공격 분석

1. (Tx 1, 2) 공격자는 SDEX에서 USTRY 가격을 $1.06에서 약 $107로 조작하였습니다. SDEX의 USTRY/USDC 마켓은 유동성이 극히 낮았으므로, 공격자는 모든 정상 주문을 소진한 후 비정상적인 주문을 배치하여 시장 가격을 급격히 올렸습니다.

2. (Tx 3) Reflector 오라클은 SDEX에서 조작된 가격을 가져와 그에 따라 가격 피드를 업데이트하였습니다.

3. (Tx 4, 5) 공격자는 12,881e7 USTRY를 담보로 1,000,196e7 USDC를 차입하였습니다.
4. (Tx 6, 7) 공격자는 14,987,610e7 USTRY를 담보로 6,124,927,810e7 XLM을 차입하였습니다.

5. (Txs 8, 9, 10) 마지막으로, 공격자는 탈취한 자산을 Base, BSC, Ethereum을 포함한 여러 체인으로 브릿지하였습니다.

아래 표는 주요 공격 트랜잭션 및 관련 주소를 요약합니다.

결론

YieldBloxDAO 사례는 상당한 손실을 야기하였지만, 근본적인 문제는 복잡하지 않습니다: 담보 가치 평가가 조작에 취약한 가격에 의존하고 있다는 점입니다. 이 사례는 대출 프로토콜의 가격 의존성을 신중하게 선택하고 모니터링해야 한다는 것을 상기시켜 줍니다.

참고 자료

[1] https://blocksec.com/blog/yieldblox-dao-incident-on-stellar-oracle-misconfiguration-enabled-a-10m-drain

[2] https://reflector.network/

[3] SDEX의 USTRY/USDC 마켓

3. STO 사례

간략한 요약

2026년 2월 23일, BNB 스마트 체인의 PancakeSwap에 있는 STO-WBNB 풀이 탈취되어 약 $16.1K의 손실이 발생하였습니다. 근본 원인은 STO 토큰의 결함 있는 소각 메커니즘이었습니다. 구체적으로, 사용자가 풀에서 STO 토큰을 매도하면 소각 메커니즘이 트리거되어 풀에서 STO 토큰이 소각되고 토큰 가격이 부풀려집니다. 그 결과, 공격자는 이 취약점을 악용하여 풀에서 WBNB 토큰을 탈취하였습니다.

배경

STO 토큰은 PancakeSwap V2 풀을 대상으로 하는 소각 메커니즘을 도입합니다. 이 메커니즘은 STO 토큰의 매도 기능이 활성화된 경우(즉, sellEnabled == true)이고 pendingBurnFromSell > 0인 경우에만 트리거됩니다. 사용자가 STO 토큰을 매도하면, 이 메커니즘은 풀에서 STO 토큰을 소각합니다. 구체적으로, 소각 과정에서는 이전 트랜잭션에서 매도된 STO 토큰의 94%가 소각됩니다.

취약점 분석

이 사례의 근본 원인은 STO 토큰의 결함 있는 소각 메커니즘입니다. 구체적으로, 사용자가 STO 토큰을 매도하면, 소각 메커니즘이 풀에서 일정량의 STO 토큰을 제거하는 동시에 페어 컨트랙트의 sync() 함수를 호출하여 준비금을 업데이트합니다. 이 소각 메커니즘은 풀에서 STO 토큰의 가격을 부풀립니다. 그 결과, 공격자는 가격 조작 공격을 수행하여 이 메커니즘으로부터 이익을 얻을 수 있습니다.

공격 분석

다음 분석은 트랜잭션 0x8ba17bea...5a54020c을 기반으로 합니다.

1. 공격자는 플래시론을 통해 360,894e18 WBNB를 빌렸습니다.

2. 공격자는 initializeLiquidity() 함수를 호출하여 STO 토큰의 매수 및 매도 기능을 활성화하였습니다.

3. 공격자는 360,894e18 WBNB를 7,848,832e18 STO로 교환하였습니다.

4. 공격자는 transfer() 함수를 호출하여 소각 메커니즘을 트리거하고 페어의 준비금을 조작(즉, STO 토큰의 가격 인상)하였으며, 동시에 다음 트랜잭션에서 소각될 STO 토큰의 양을 173,391e18로 설정하였습니다.

5. 공격자는 swap() 함수를 호출하여 STO를 WBNB로 스왑하였습니다. 이 단계에서 공격자는 조작된 가격을 기반으로 이익을 얻었습니다.

6. 공격자는 4단계와 5단계를 반복하여 풀의 WBNB를 탈취하였습니다.

7. 공격자는 플래시론을 상환하고 26e18 WBNB의 이익을 실현하였습니다.

결론

이 사례의 근본 원인은 STO의 결함 있는 소각 메커니즘에서 비롯되며, 이로 인해 공격자가 풀에서 WBNB를 탈취할 수 있었습니다. 이러한 문제를 완화하기 위해, 프로젝트는 시스템 내에 적절한 접근 제어를 구현하고 잠재적인 가격 조작 공격을 방지할 수 있도록 소각 메커니즘에 대한 포괄적인 테스트를 수행해야 합니다.

4. HedgePay 사례

간략한 요약

2026년 2월 25일, BNB 스마트 체인의 HedgePay 프로토콜이 공격을 받아 약 $15.7K의 손실이 발생하였습니다. 근본 원인은 HedgePay 프로토콜의 스테이킹 컨트랙트에 있는 결함 있는 비즈니스 로직이었습니다. 구체적으로, 취약한 스테이킹 컨트랙트(즉, 0xBe189fe9f84cA531CD979630E1f14757b88dD80d)의 forceExit() 함수가 사용자의 스테이킹 잔액을 업데이트하지 않고 스테이킹된 자산을 인출할 수 있도록 허용하였습니다. 그 결과, 공격자는 forceExit() 함수를 반복적으로 호출하여 컨트랙트의 HPAY 토큰을 탈취할 수 있었습니다.

배경

HedgePay 프로토콜은 사용자가 HPAY 토큰을 스테이킹하여 보상을 얻을 수 있는 스테이킹 프로토콜입니다. forceExit() 함수는 사용자가 스테이킹된 자산을 인출할 수 있게 해줍니다.

취약점 분석

이 사례의 근본 원인은 forceExit() 함수의 결함 있는 비즈니스 로직입니다. 구체적으로, 사용자가 stake() 함수를 통해 HPAY 토큰을 스테이킹하면 스테이킹 금액(즉, _balances[msg.sender])이 그에 따라 업데이트됩니다. 그러나 사용자가 forceExit() 함수를 통해 스테이킹된 HPAY 토큰을 인출할 때 컨트랙트는 _balances[msg.sender]를 업데이트하지 못합니다. 그 결과, 공격자는 forceExit() 함수를 반복적으로 호출하여 스테이킹 컨트랙트의 HPAY 토큰을 탈취할 수 있습니다.

공격 분석

다음 분석은 트랜잭션 0x5f2ea6cb...46ed137f을 기반으로 합니다.

1. 공격자는 플래시론을 통해 1,247,859e18 HPAY를 빌렸습니다. 플래시론 콜백 함수에서:

   a.공격자는 stake() 함수를 통해 1,197,944e18 HPAY를 스테이킹하였습니다.

   b.공격자는 forceExit() 함수를 반복적으로 호출하여 컨트랙트의 HPAY 토큰을 탈취하였습니다.

2. 공격자는 플래시론을 상환하고 57,389,615e18 HPAY를 26e18 WBNB로 스왑하였습니다(즉, 26e18 WBNB의 이익 실현).

결론

이 사례의 근본 원인은 forceExit() 함수가 사용자의 _balances[msg.sender]를 업데이트하지 않아, 공격자가 스테이킹 컨트랙트의 HPAY 토큰을 탈취할 수 있었다는 것입니다. 이러한 문제를 방지하기 위해, 프로젝트는 각 함수에서 상태 불변량이 올바르게 유지되는지 확인하는 적절한 상태 중심 테스트를 수행해야 합니다.

5. Ploutos 사례

간략한 요약

2026년 2월 26일, Ethereum의 Ploutos 프로토콜 풀이 오라클 잘못된 설정으로 인해 약 $390,000의 손실을 입었습니다. 구체적으로, 오라클이 USDC에 대해 BTC/USD Chainlink 가격 피드를 사용하도록 잘못 설정되었습니다. 그 결과, 공격자는 이 잘못된 설정을 악용하여 단 8 USDC를 담보로 187 ETH를 차입하였습니다.

취약점 분석

Ploutos는 여러 네트워크에 배포된 Aave v3.0.2의 포크입니다. 이 사례는 대출 풀(0xD060...F945D2)의 잘못된 오라클 설정으로 인해 발생하였습니다.

블록 24538896에서 USDC의 가격 오라클이 USDC/USD 피드 대신 BTC/USD Chainlink 피드를 참조하도록 잘못 설정되었습니다. 다음 블록(24538897)에서 공격자는 이 잘못된 설정을 감지하고 공격을 실행하였습니다. 그 결과, 공격자는 약 8.88 USDC를 담보로 약 187.3 ETH를 이익으로 차입하였습니다.

공격 분석

1. 공격자는 Ploutos 프로토콜의 오라클 설정 작업을 모니터링하였으며, Tx 0xcfedf6...bd193ab6에서 USDC의 오라클 소스가 Chainlink BTC/USDC 가격 피드로 잘못 설정된 것을 확인하였습니다.

2. 공격자는 즉시 트랜잭션(0xa17dc37e...705f8474)을 전송하였으며, 오라클 잘못된 설정으로 인해 단 약 8.8 USDC를 담보로 ~187.3 ETH를 차입할 수 있었습니다.

3. 공격자는 약 5.6 ETH를 빌더 뇌물로 지불하고 약 181.7 ETH의 순이익을 얻었습니다.

결론

이 사례의 근본 원인은 오라클 잘못된 설정이었으며, 약 $390,000의 손실이 발생하였습니다. 이는 오라클 설정과 같은 민감한 작업이 잠재적인 손실을 방지하기 위해 멀티시그 지갑이나 타임락으로 보호되어야 한다는 것을 상기시켜 줍니다.

참고 자료

[1] https://x.com/Phalcon_xyz/status/2026943448734114011

6. FOOMCASH 사례

간략한 요약

2026년 2월 26일, FOOMCASH 프로토콜이 취약한 Groth16 증명 검증 [1]으로 인해 공격을 받아 총 $2.26M 이상의 손실이 발생하였습니다.

배경

FOOMCASH 프로토콜은 Base 및 Ethereum에서 운영되는 복권 프로토콜로, 출금 검증에 Groth16 증명을 사용합니다. FoomLottery 컨트랙트에서 collect() 함수는 WithdrawG16Verifier.verifyProof() 함수를 호출하여 제공된 증명(즉, _pA, _pB, _pC)을 검증합니다. 구체적으로, 검증은 WithdrawG16Verifier 컨트랙트의 신뢰 설정(즉, gamma 및 delta)을 기반으로 수행됩니다. 증명이 유효한 것으로 검증되면, collect() 함수는 사용자의 입력(예: _recipient 및 _rewardbits)에 따라 자산(즉, FOOM 토큰)을 전송합니다.

취약점 분석

이 사례의 근본 원인은 취약한 Groth16 설정이었습니다. 구체적으로, WithdrawG16Verifier 컨트랙트에서 변수 gamma ($\gamma \backslash gamma$)와 delta ($\delta \backslash delta$)가 동일한 값(즉, $G\mathrm{\_}2G\backslash \_\{2\}$)을 공유하여, 공격자가 임의의 입력으로 유효한 증명을 위조할 수 있었습니다. 그 결과, 공격자는 WithdrawG16Verifier 컨트랙트의 Groth16 증명 검증을 우회하고 악의적인 입력으로 FoomLottery 컨트랙트의 모든 자산을 탈취하였습니다.

공격 분석

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

공격자는 유효한 증명과 악의적인 입력을 구성하기 위해 악성 컨트랙트를 생성하였습니다. 악성 컨트랙트의 폴백 로직에서:

1. 유효한 증명을 구성하였습니다.

2. 유효한 증명과 악의적인 입력(예: _recipient 및 _rewardbits)을 사용하여 FoomLottery 컨트랙트의 collect() 함수를 호출하였습니다.

a. collect() 함수 호출 과정에서, 증명 검증(즉, WithdrawG16Verifier.verifyProof())이 우회되었고 자산(즉, FOOM 토큰)이 공격자에게 전송되었습니다.

3. 1~2단계를 30회 반복하여 총 19,695,576,757,802e18 FOOM 토큰을 탈취하였습니다.

결론

이 사례의 근본 원인은 취약한 Groth16 검증 설정이었으며, 약 $2.26M의 손실이 발생하였습니다. 이는 복잡한 암호화 설정이 배포 전에 철저히 검토되고 감사를 받아야 한다는 점을 강조합니다.

참고 자료

[1] https://x.com/Phalcon_xyz/status/2026941738141778394

7. 알 수 없는 사례

간략한 요약

2026년 2월 27일, BNB 스마트 체인의 알 수 없는 컨트랙트가 공격을 받아 [1] 약 $180K의 손실이 발생하였습니다. 이 사례의 근본 원인은 부적절한 입력 검증이었습니다. 구체적으로, 피해 컨트랙트의 _verifySignatures() 함수가 빈 목록 검사를 수행하지 않아, 공격자가 서명과 서명자를 제공하지 않고도 서명 검증을 우회할 수 있었습니다. 그 결과, 공격자는 이 취약점을 이용하여 피해 컨트랙트의 모든 USDT 토큰을 탈취하였습니다.

취약점 분석

이 사례의 근본 원인은 서명 검증 흐름의 부적절한 유효성 검사입니다. 구체적으로, _verifySignatures() 함수는 allSigners.length == signatures.length만 확인하고 두 배열 모두 비어있지 않아야 한다는 조건을 요구하지 않습니다. 그 결과, 두 배열이 모두 비어있을 때 공격자는 서명 검증을 우회하고 자산을 인출할 수 있습니다.

공격 분석

다음 분석은 트랜잭션 0x91f45260...41cfd784을 기반으로 합니다.

1. 공격자는 악성 컨트랙트의 0x2d0cb456() 함수를 호출하였습니다. 호출 과정에서,

a. 악성 컨트랙트는 빈 입력값 allSigners와 signatures를 사용하여 poolWithdraw() 함수를 호출하였으며, 의도된 서명 검증 로직을 우회하였습니다.

b. 서명 검증 로직을 우회한 후, 피해 컨트랙트는 USDT를 공격자에게 전송하였습니다.

결론

이 사례의 근본 원인은 부적절한 입력 검증이었으며, 약 $180K의 손실이 발생하였습니다. 이 사례는 입력값에 대한 비어있지 않음 검사와 같은 기본적인 경계 검사의 중요성을 강조합니다.

참고 자료

[1] https://x.com/Phalcon_xyz/status/2027328894710505581

BlockSec 소개

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

BlockSec은 저명한 컨퍼런스에 다수의 블록체인 보안 논문을 발표하였으며, 여러 DeFi 애플리케이션의 제로데이 공격을 보고하였고, 2천만 달러 이상을 구제하기 위해 여러 해킹을 차단하였으며, 수십억 달러의 암호화폐를 보호하였습니다.

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

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

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

• 🔗 Phalcon 보안 앱: 데모 예약

• 🔗 Phalcon 컴플라이언스