QRコードをスキャンしてダウンロードしてください。
BTC $78,109.92 +0.55%
ETH $2,336.25 +0.98%
BNB $632.61 -0.32%
XRP $1.42 -1.03%
SOL $85.82 -0.62%
TRX $0.3239 -0.07%
DOGE $0.0977 -0.55%
ADA $0.2497 -0.50%
BCH $452.97 -0.16%
LINK $9.32 -0.77%
HYPE $41.27 -0.02%
AAVE $93.95 -0.59%
SUI $0.9491 +0.33%
XLM $0.1703 -1.80%
ZEC $355.96 -0.66%
BTC $78,109.92 +0.55%
ETH $2,336.25 +0.98%
BNB $632.61 -0.32%
XRP $1.42 -1.03%
SOL $85.82 -0.62%
TRX $0.3239 -0.07%
DOGE $0.0977 -0.55%
ADA $0.2497 -0.50%
BCH $452.97 -0.16%
LINK $9.32 -0.77%
HYPE $41.27 -0.02%
AAVE $93.95 -0.59%
SUI $0.9491 +0.33%
XLM $0.1703 -1.80%
ZEC $355.96 -0.66%

損失は4千万ドルを超え、GMX攻撃の原理分析

Summary: GMXはハッカーに再入可能な脆弱性を利用され、レバレッジメカニズムの設計欠陥により4000万ドル以上の損失を被った。核心的な問題は、リデンプションロジックがAUMに対して過度に信頼していることにある。
BlockSec
2025-07-10 11:13:11
コレクション
GMXはハッカーに再入可能な脆弱性を利用され、レバレッジメカニズムの設計欠陥により4000万ドル以上の損失を被った。核心的な問題は、リデンプションロジックがAUMに対して過度に信頼していることにある。

著者:BlockSec

GMXはハッキング攻撃を受け、4000万ドル以上の損失を被りました。攻撃者は再入可能な脆弱性を利用し、契約がレバレッジ機能を有効にしている状況でショートポジションを開設し、攻撃を実施しました。

問題の根源は、executeDecreaseOrder関数が誤って使用されたことにあります。この関数の最初のパラメータは外部アカウント(EOA)であるべきですが、攻撃者はスマートコントラクトのアドレスを渡しました。これにより、攻撃者は償還プロセス中にシステムに再入し、内部状態を操作し、最終的に償還される資産が実際に保有しているGLPの価値を大幅に上回ることができました。

GLPの正常な償還メカニズム

GMXにおいて、GLPは流動性提供者トークンであり、金庫資産(USDC、ETH、WBTCなど)に対する持分を表します。ユーザーがunstakeAndRedeemGlpを呼び出すと、システムは以下の式を使用して返還される資産の数量を計算します:

redeemamount = (userGLP / totalGLPsupply) * AUM
ここで、AUM(管理資産総額)の計算方法は以下の通りです:

AUM = すべてのトークンプールの総価値 + グローバルショートの未実現損失 - グローバルショートの未実現利益 - 予約済み金額 - 予想減額(aumDeduction)

このメカニズムは、GLP保有者が金庫の実際の資産持分を比例的に取得することを保証します。

レバレッジが有効になった後の問題

enableLeverageが有効になると、ユーザーはレバレッジポジション(ロングまたはショート)を開設できます。攻撃者はGLPを償還する前に、大額のWBTCショートポジションを開設しました。

ショートポジションを開設すると、グローバルショートの規模が増加し、価格が変動していない状況でシステムはそのショートを損失と見なします。この未実現損失は金庫の「資産」として計上され、AUMが人為的に上昇します。金庫は実際には追加の価値を得ていないにもかかわらず、償還計算はこの虚高のAUMに基づいて行われ、攻撃者は本来得るべき資産を大幅に上回ることができました。

攻撃の流れ

攻撃取引

https://app.blocksec.com/explorer/tx/arbitrum/0x03182d3f0956a91c4e4c8f225bbc7975f9434fab042228c7acdc5ec9a32626ef?line=93

画像 画像

結論

今回の攻撃は、GMXのレバレッジメカニズムと再入防止設計における深刻な欠陥を暴露しました。核心的な問題は、資産償還ロジックがAUMに対して過度に信頼を置いており、その構成要素(未実現損失など)に対して十分な安全検証が行われていないことです。また、重要な関数が呼び出し元の身元(EOA vs コントラクト)に対する仮定も強制的な検証を欠いています。この事件は、開発者に対して、資金に敏感な操作に関与する際には、システム状態が操作されないことを確保する必要があることを再度思い起こさせます。特に、レバレッジやデリバティブなどの複雑な金融ロジックを導入する際には、再入や状態汚染によるシステミックリスクに対して厳重に警戒する必要があります。

warnning リスク警告
app_icon
ChainCatcher Building the Web3 world with innovations.