Web3セキュリティインシデント週次 roundup | 2026年3月30日～4月5日

過去1週間（2026/03/30～2026/04/05）、BlockSecは9件の攻撃インシデントを検出し分析しました。総損失額は約2億8,700万ドルと推定されています。以下の表にこれらのインシデントをまとめ、各ケースの詳細な分析を後続のセクションで提供します。

日付	インシデント	タイプ	推定損失額
2026/03/30	不明なプロトコルインシデント	不備のあるビジネスロジック	約1万ドル
2026/03/30	WDGGトークンインシデント	アクセス制御	約4万ドル
2026/03/31	i6トークンインシデント	不備のあるビジネスロジック	約27.38万ドル
2026/04/01	Drift Protocolインシデント	フィッシング詐欺	約2億8,530万ドル
2026/04/01	LMLステーキングプロトコルインシデント	不備のあるビジネスロジック	約95万ドル
2026/04/01	Tactileインシデント	価格操作	約1.2万ドル
2026/04/02	SASトークンインシデント	不備のあるビジネスロジック	約1.2万ドル
2026/04/03	Unknown-EIP-7702インシデント	アクセス制御	約1.72万ドル
2026/04/03	Silo Financeインシデント	設定ミス	約35.9万ドル

1. 不明なプロトコルインシデント

概要

2026年3月30日、BNB Chain上の不明なプロトコルが、不備のあるビジネスロジックにより約1万ドルの損失を被りました。このプロトコルは、ユーザーの預金の大部分をプラットフォームトークン PSTART の購入と流動性の追加に割り当てており、ユーザーは実質的に市場価格の変動に左右されるLPポジションを保有していました。しかし、出金時に、プロトコルはLPの実際の償還可能価値に基づいて清算しませんでした。代わりに、過去の預金と事前に定義されたルールに基づいて固定額のステーブルコインを約束し続けました。その結果、強制的な投資を通じて資本をコミットした後、攻撃者は事前に合意された固定値で資金を引き出すことができ、LPポジションが負担すべき損失を実質的にプロトコルに転嫁し、最終的にゼロコストで利益を上げました。

背景

プロトコルは次のように動作します。ユーザーが BUSD を預金すると、プロトコルは資金の一部を自動的に購入し、残りの BUSD とペアにしてプールに流動性を追加します。生成された LP 株式は Vault によって保管されますが、プロトコルは内部台帳に、ユーザーに対して固定の日次利回りを約束する注文を記録します。

その後、ユーザーは固定金利で報酬を請求でき、出金時に、Vault は基盤となる LP ポジションの現在の実質純資産価値に基づいて厳密に償還するのではなく、事前に定義されたルールに従って元本と利回りを決済します。

脆弱性分析

この脆弱性は、非合理的なプロトコル (0x587984...73a43c) の設計に起因しています。決済ロジックが基盤となる資産の実際の価値から切り離されています。

ユーザーが BUSD を預金すると、プロトコルはその一部を使用して PSTART を購入し、流動性を追加します。これは、ユーザーの実際の基盤となるポジションが、市場価格の変動に左右される LP エクスポージャーであることを意味します。しかし、ユーザーが出金する際、プロトコルはその時点での LP の実際の償還可能価値に基づいて決済しません。代わりに、過去の預金額と事前に定義された決済ルールに従って、固定額のステーブルコインを支払うことを依然として約束します。

攻撃者は、フラッシュローンを使用して大量の資本を取得し、その後 deposit() を繰り返し実行してこの欠陥を悪用しました。これを行うことで、攻撃者はプロトコルに継続的に PSTART を購入させ、プールの資産構成を変更させ、それによって PSTART の価格を人為的に引き上げ、アービトラージの機会を作り出しました。

攻撃者はその後 withdraw() を実行し、事前に約束された固定値で資金を償還しました。これにより、基盤となる LP ポジションが負担すべき損失を実質的にプロトコル自身に転嫁し、最終的にゼロコストで利益を上げました。

攻撃分析

以下の分析は、トランザクション 0xf3b8...55e7 に基づいています。

ステップ1：攻撃者はフラッシュローンで約 2,000,000e18 の BUSD を取得し、プールで 19,013,120e18 の PSTART と交換しました。
ステップ2：攻撃者は、deposit() 関数を繰り返し呼び出して資金をステークしました。各預金に対して、プロトコルは、流動性を追加するために使用される最終的なトークンと BUSD の比率が、プールの現在の比率にさらに近くなるように、いくらの BUSD を購入すべきかを計算しました。繰り返し預金することで、攻撃者は継続的に BUSD をプールに注入しましたが、PSTART の量はほとんど変化しませんでした。その結果、PSTART の価値は上昇し続けました。この段階では、攻撃者の預金を通じて取得された LP は、実際には損失を被って取得されていました。
ステップ3：攻撃者はその後、ステップ1で購入した PSTART をプールに売却しました。ステップ2でプールの BUSD 準備金が増加したため、このスワップにより約 2,010,655e18 の BUSD が戻ってきました。これにより、単一の攻撃サイクルで約 10,655 BUSD の利益が発生しました。
ステップ4：最後に、攻撃者はステップ2で開かれたすべてのステーキングポジションで withdraw() を実行しました。この時点で、これらのポジションに対応する資産の市場価値は、初期預金額をはるかに下回っていました。通常の経済ロジックでは、全額償還は不可能であったはずです。しかし、プロトコルは過去の預金額に基づいて償還可能な BUSD 金額を計算したため、攻撃者は強制的な投資コストを一切負担することなく、以前の損失を全額回収することができました。

結論

このインシデントの根本原因は、プロトコルが市場価格の変動に左右されるLPポジションにユーザー資金を投資したにもかかわらず、過去の預金額と事前に定義されたルールに基づいた固定額の BUSD での決済を依然として約束していたことです。これにより、プロトコルの負債と基盤となる資産の実際の価値との間に断絶が生じました。

攻撃者は、deposit() を繰り返し使用してプールの資産構造を変更し PSTART の価格を押し上げ、その後外部ポジションを通じてアービトラージを完了し、最後に withdraw() を使用して損失を被ったポジションを帳簿価額で償還することにより、この欠陥を悪用しました。このように、ポジション自体が負担すべき損失はプロトコルに転嫁され、最終的にリスクフリーの利益が可能になりました。

2. WDGGトークンインシデント

概要

2026年3月30日、BNB Chain上の WDGG トークンが約4万ドルの損失を被り、エクスプロイトされました。根本原因は、burnFrom() 関数におけるアクセス制御の欠落でした。具体的には、burnFrom() 関数は、任意のユーザーが任意のウォレットから WDGG トークンを燃焼させることを許可していました。攻撃者はこれを悪用し、PancakeSwapプールから WDGG トークンを燃焼させ、その後 sync() 関数を呼び出してプールの WDGG 準備金を減らし、さらに逆スワップを実行して利益を抽出しました。

背景

このインシデントは、配当分配トークンであり、各送金に手数料を課す単一のトークン WDGG に関係しています。

脆弱性分析

WDGG トークンコントラクト (0x512de7...6b90c5) は、呼び出し元の認証なしに burnFrom() を公開していました。その結果、どのウォレットでも、PancakeSwapプール自体を含む、すべての保有者から WDGG トークンを燃焼させることができました。これは、PancakeSwapの公開呼び出し可能な sync() と組み合わさることで、記録された準備金を実際の残高と一致させます。この欠陥により、正規の取引なしにプールの WDGG 準備金を任意に減らすことができ、定数積不変量を破ることができました。これにより、プールは価格不均衡アービトラージに対して脆弱になりました。

setWdgAddress() の二次的な欠陥により、任意の呼び出し元が任意のウォレットを手数料免除としてマークすることができ、この攻撃サーフェスを通じて抽出可能な利益をさらに最大化できました。

攻撃分析

以下の分析は、トランザクション 0x2da5...0bd1 に基づいています。

ステップ1：攻撃者はまず setWdgAddress() を呼び出して、自身のアドレスを手数料免除として設定し、その後の送金がトークンの送金手数料を回避できるようにしました。

ステップ2：攻撃者はその後、少量の BNB を PancakeSwap プール経由で WDGG トークンとスワップしました。
ステップ3：WDGG を取得した後、攻撃者は burnFrom() を呼び出して、PancakeSwapペアアドレスから直接 WDGG トークンを燃焼させました。
ステップ4：攻撃者はその後 sync() を呼び出し、ペアにその準備金を操作されたトークン残高と一致させるように強制しました。その結果、プール内の WDGG 準備金はわずか1 weiに減少しました。

ステップ5：プールの準備金が著しく歪んだため、攻撃者は逆スワップを実行し、価格の不均衡から利益を抽出しました。

結論

このインシデントの根本原因は、WDGG トークンコントラクトの burnFrom() 関数におけるアクセス制御の欠落でした。その結果、攻撃者は PancakeSwap プールから直接トークンを燃焼させ、sync() を通じてプールの準備金を操作し、結果として生じた価格の不均衡を悪用して利益を得ることができました。

3. i6トークンインシデント

概要

2026年3月31日、BNB Chain上の i6 トークンが約27万3,800ドルの損失を被りました。根本原因は、invest() がプールのスポット価格を変動させた一方で、withdraw() は遅延TWAPで残高を決済し、両者が同じトランザクションで組み合わせ可能であったことです。攻撃者は invest() を通じてスポット価格をインフレさせ、withdraw() を通じて古いTWAPで過剰な i6 を償還し、インフレしたプールに i6 を売却して利益を得ました。

背景

プロトコルは次のように動作します。ユーザーが invest() を呼び出すと、USDT が預金され、一部はPancakeSwapで i6 を購入するために使用されます。購入した i6 は、残りの USDT と共に USDT/i6 プールに流動性として追加され、生成されたLPトークンは燃焼されます。プロトコルは、USDT 建てのユーザーと紹介者の残高を記録します。

withdraw() が呼び出されると、プロトコルはユーザーの累積残高を USDT 建てで計算し、プロトコルで維持されるTWAP価格（twapPrice）を使用して i6 に変換します。

脆弱性分析

プロトコルコントラクト (0x1cb36b...2a18a) の根本原因は、invest() が i6 の購入と流動性の追加の副作用として USDT/i6 プールのスポット価格を変化させる一方で、withdraw() がプロトコルで維持されるTWAP（twapPrice）を使用して累積 USDT 建て残高を i6 に決済し、そのTWAPは時間ウィンドウが経過した後にのみ更新されることです。この2つの関数が同じトランザクションで実行されるのを防ぐものは何もありません。

invest() の呼び出しが、後続の withdraw() がまだ更新されていないTWAPを読み取るのと同じトランザクション内でスポット価格をインフレさせる可能性があるため、両者は実質的に同じプール状態に対して2つの異なる価格を認識します。withdraw() を通じて償還された USDT 建て残高は、古い、はるかに低い価格で i6 で支払われます。たとえ各 i6 が、プール自体でより多くの USDT で実現可能になったとしてもです。このギャップにより、プロトコル上の累積 USDT 残高は、内部決済とライブプールの間の利用可能なスプレッドに変わります。

攻撃分析

以下の分析は、トランザクション 0xc1b9...2f16 に基づいています。

ステップ1：攻撃者はまずフラッシュローンで 270,000 WBNB を取得し、それをVenusに担保として供給し、大量の USDT を借入しました。攻撃者はまた、攻撃コントラクト A を 0xda49 に、ヘルパーコントラクト B を 0x096a にデプロイしました。
ステップ2：攻撃コントラクトは最初の invest() を実行しました。このプロセス中に、プロトコルはまず 531,489e18 の USDT を使用して 234,188e18 の i6 を購入し、次に 354,326e18 の USDT と 72,607e18 の i6 をプールに追加しました。その結果、プールのスポット価格は、約 1.05159 USDT/i6 から約 4.89287 USDT/i6 に急上昇しました。一方、プロトコルに記録された TWAP は依然として 1.05159 のままでした。

ステップ3：攻撃者は次に 124,014,184e18 の USDT をヘルパーコントラクト B に転送しました。ヘルパーコントラクト B は、referrer = A として invest() を呼び出しました。このステップにより、プロトコルは再び大量の USDT -> i6 購入と addLiquidity() を実行させ、プールの準備金を約 15,528 USDT/i6 のスポット価格に対応する新しい状態に押し上げました。しかし、新しい時間ウィンドウが経過しなかったため、プロトコルは TWAP をそれに応じて更新しませんでした。
ステップ4：2回目の invest() が完了した後、紹介者として機能する攻撃コントラクト A は、直ちに USDT 建ての紹介報酬を受け取る権利を得ました。攻撃者はその後 withdraw() を呼び出しました。プロトコルは古い TWAP を使用して支払われる i6 の量を計算し、そのトークンを自身の残高から転送しました。その結果、合計 5,896,508e18 の i6 が支払われました。
ステップ5：受け取った i6 の後、攻撃者は直ちに swapExactTokensForTokensSupportingFeeOnTransferTokens() を呼び出して、すべての 5,896,508e18 の i6 をプールに売却し、代わりに 125,177,224e18 の USDT を受け取りました。これらの i6 トークンは、約 1.05159 USDT/i6 の古い TWAP を使用して決済され、攻撃者によって約 15,528 USDT/i6 に押し上げられたプールスポット価格に対して売却されたため、攻撃者は2つの価格間の巨大なスプレッドを直接実現できました。
ステップ6：フラッシュローンを返済した後、攻撃者は 273,802e18 の USDT を保持しました。これが攻撃による実際の利益でした。

結論

根本原因は、スポット価格に影響を与える関数（invest()）とTWAPで決済される関数（withdraw()）が単一のトランザクションで組み合わせ可能であったことであり、両者が同じプール状態に対して異なる価格を認識することを可能にしました。

このクラスの欠陥を防ぐために、AMMインタラクションと遅延価格設定を組み合わせるプロトコルは、基盤となるプールスポット価格を移動させるコンパニオン関数と同じトランザクションでTWAPでの残高決済を避けるべきであり、代わりに内部決済とライブプールの間のスプレッドを悪用可能にするために、古いまたは派生価格ではなく、ライブで実現可能な価値に基盤を置いた支払いをアンカーするべきです。

4. Drift Protocolインシデント

概要

2026年4月1日（UTC）、Solana上のDrift Protocolが約2億8,530万ドルで侵害されました。根本原因はスマートコントラクトのバグではなく、マルチシグ承認プロセスにおける崩壊でした。これは、ロックタイムがゼロの2/5セキュリティ評議会とSolanaの永続的なノンスメカニズムによって悪化し、事前に収集されたマルチシグ承認が攻撃者がそれらを送信することを選択するまで無期限に有効なままでした。数週間のステージングの後、攻撃者は5人の署名者のうち2人に、永続的なノンスアカウントにバインドされた悪意のあるガバナンストランザクションに事前に署名させた後、それらを送信して管理者権限を奪取し、偽の担保資産（CVT）を導入し、そのオラクル価格をインフレさせ、出金制限を緩和し、Drift Vault (JCNCMF...XJfrw) を通じて実際の資産を drain しました。

背景

Drift Protocolは、マージン取引、貸付、スポット市場、デリバティブをサポートするSolana上のDeFiプロトコルです。管理者変更、市場作成、オラクル設定、リスクパラメータ更新、出金制限調整などの高権限操作は、単一の秘密鍵ではなく、Squadsマルチシグフレームワークによって管理されています。攻撃時、Driftのセキュリティ評議会は、ロックタイムがゼロの2/5閾値設定で運用されており、5人の署名者のうち2人が承認すれば、管理アクションが即座に有効になりました。このシステムのセキュリティは、署名キーの保管だけでなく、完全な承認パイプラインの整合性にも依存します。つまり、どのトランザクションが作成されたか、署名者が何に署名したと考えていたか、そして最終的に実行された指示がそのレビューコンテキストと一致していたかです。

別個に、Solanaの永続的なノンスアカウントは、短命のブロックハッシュを専用アカウントに格納された永続的なノンスで置き換えます。これにより、署名されたトランザクションは、ノンスが進められるまで無期限に有効なままになります。このメカニズムは、オフライン署名や遅延送信などの正当なユースケースのために設計されていますが、トランザクションが署名された時点とオンチェーンで実行された時点を切り離すことにより、重要な攻撃プリミティブを導入します。署名者が永続的なノンストランザクションを承認すると、ノンス権限者がノンスアカウントを手動で進めない限り、その承認は取り消せません。

脆弱性分析

根本原因はスマートコントラクトのバグではなく、Driftのガバナンス設定における3つの構造的な弱点です。これらが組み合わさって、ソーシャルエンジニアリングの機会を2億8,530万ドルの drain に変えました。第一に、永続的なノンスは、暗黙的な署名期限の安全ネットを削除しました。通常のブロックハッシュベースのトランザクションでは、騙された署名者の承認は、すぐに実行されるか、狭いウィンドウ内で無害に期限切れになるかのどちらかで、協調的な悪用を制限します。永続的なノンスは、この制約を解消します。2人のセキュリティ評議会の署名者が、誤解を招く署名要求を通じて悪意のあるガバナンストランザクションを承認するよう誘導された場合、彼らの署名は無期限に悪用可能であり、攻撃者は実行タイミングを完全に制御できました。

第二に、管理アクションに対するゼロロックタイムは、事前に署名されたトランザクションが送信されると、管理者移転が即座に有効になることを意味し、検出または介入のウィンドウが残りませんでした。第三に、管理者ロールの範囲は、単一の特権パスウェイで新しい担保市場を作成し、オラクルソースを切り替え、出金制限を緩和するのに十分広かったため、単一のガバナンス乗っ取りが、追加の承認バリアなしに、任意の資産を実際の資金抽出に変換するのに十分でした。

攻撃分析

攻撃は3つの別々のフェーズで展開されました。攻撃前ステージングでは、攻撃者は偽の担保資産を製造し、誤解を招く署名要求を通じてガバナンスアクセスを取得するために、数週間にわたる操作を実行しました。ガバナンス乗っ取りでは、2つの事前に署名された永続的なノンストランザクションが、管理権限を奪取するために連続して送信されました。そして資金抽出フェーズでは、攻撃者はプロトコルパラメータを操作し、プロトコルの貸付経路を通じて実際の資産を drain しました。以下の図は、これら3つのフェーズにわたる実行フローを示しています。

フェーズ1（攻撃前ステージング）：3月11日から、攻撃者はTornado Cashから10 ETH を引き出し、CarbonVote Token（CVT）をデプロイして7億5000万ユニットをミントし、Raydiumに流動性を供給し、ウォッシュトレードを使用して1ドル付近の人工的な価格履歴を構築しました。並行して、3月23日までに4つの永続的なノンスアカウントが作成され、そのうち2つはDriftセキュリティ評議会のメンバーにリンクされ、2つは攻撃者によって制御されていました。これは、5人の署名者のうち少なくとも2人が、永続的なノンスアカウントに関連付けられたトランザクションにすでに署名していたことを示しています。3月27日、Driftはメンバー変更のため計画されたセキュリティ評議会の移行を実行し、以前に収集された署名を無効にしました。しかし、3月30日までに攻撃者は新しい構成の下で必要な閾値を再取得し、オンチェーンガバナンスの変更の能動的な監視とリアルタイムの適応を示しました。
フェーズ2（ガバナンス乗っ取り）：4月1日、約16:05 UTCに、Driftが保険基金から正当なテスト引き出しを実行した約1分後に、攻撃者は4つのスロット離れた2つの事前に署名された永続的なノンストランザクションを送信しました。最初のトランザクション（2HvMSg...2C4H）は、悪意のある管理者移転提案を作成および承認しました。2番目のトランザクション（4BKBmA...RsN1）は、それを承認および実行し、AdvanceNonceAccount で始まり、保存されたノンスをアクティブ化し、proposalApprove および vaultTransactionExecute を経て、最終的に UpdateAdmin を呼び出して管理者権限を攻撃者制御のウォレットに移譲しました。
フェーズ3（資金抽出）：完全な管理者権限を得て、攻撃者は CVT の担保市場を作成し、攻撃者制御のオラクルに切り替えてその帳簿価格をインフレさせ、主要な資産市場の出金制限を引き上げまたは削除しました。攻撃者はその後、過大評価された CVT を大量にプロトコルに預け、約12分間にわたって31回の迅速な引き出しを実行し、USDC、JLP、SOL、cbBTC、USDT、wETH、dSOL、WBTC、JTO、FARTCOIN を drain し、総損失額は約2億8,530万ドルとなりました。これは、攻撃者の引き出しウォレット（HkGz4K...pZES）に基づいて計算されました。

結論

このインシデントの根本原因は、スマートコントラクトの脆弱性やキーの侵害ではなく、マルチシグ承認プロセスと、永続的なノンスベースの遅延実行、およびゼロロックタイムの管理パスウェイとの組み合わせでした。通常なら数分で期限切れになったであろう事前に収集された承認は、無期限に悪用可能であり、送信されると、管理者乗っ取りとそれに続く資金抽出は介入ウィンドウを残しませんでした。

このクラスのリスクを軽減するには、署名キーの保管だけでなく、完全な承認パイプラインを保護し、高権限操作にロックタイムを強制し、永続的なノンスなどの遅延実行メカニズムを、より高い署名閾値、時間制限または取り消し可能な承認、および無期限に有効な署名付きトランザクションに対する制限を必要とする別の脅威サーフェスとして扱う必要があります。

5. LMLステーキングプロトコルインシデント

概要

2026年4月1日、BNB Chain上の LML ステーキングプロトコルが約95万ドルでエクスプロイトされました。根本原因は、報酬計算ロジックの一貫性のなさでした。報酬変換は3600秒の更新クールダウンにロックされた保存 LML/USDT 価格を読み取っていましたが、支払われた LML はライブAMM価格で償還可能であり、両者の間に逸脱チェックはありませんでした。攻撃者はフラッシュローンを使用してプールのスポット価格をインフレさせ、EIP-7702コード委譲を使用して単一トランザクションで11の事前にステークされたEOAの報酬を一括請求し、古い保存価格で過剰な LML を受け取り、それを現在著しく歪んだプールに売却して利益を上げました。

背景

LML はBNB Chain上のステーキングプロトコルで、ユーザーは APower コントラクトを通じて BNB をステークして報酬として LML トークンを獲得します。報酬は USDT 建てで計算され、配布前にプロトコルで保存された LML/USDT 価格に基づいて LML 量に変換されます。保存価格は updatePrice() によって更新されます。これはAMMスポット価格を読み取りますが、更新間には3600秒のクールダウンを強制します。報酬請求は APower の receive() を通じて msg.sender に基づいてトリガーされるため、元のステーキングアドレスのみが自身の報酬を請求できます。

脆弱性分析

ステーキングコントラクト (0xbe9713...adce19) の中心的な欠陥は、報酬の発生と報酬の償還が、同じプールの2つの異なる価格にアンカーされており、それらの間の整合性チェックがないことです。報酬式 reward += (10^18 * base_reward) / stored_price は、プロトコルで保存された LML/USDT 価格である _prices[] から LML 支払いを計算します。この価格は、3600秒のクールダウン後に updatePrice() によってのみ更新されます。しかし、支払われる LML はライブAMMスポット価格で直ちに償還可能です。このクールダウンウィンドウ内にスポット価格を動かす外部アクティビティは、凍結された発生価格とライブ販売価格の間にギャップを開け、そのギャップが不合理になった場合に請求を拒否するものは何もありません。

報酬ソースが補充される方法における二次的な構造的欠陥があります。PROOF コントラクトの LML 残高が請求の支払いに十分でない場合、swapBack() は super._transfer(swapPair, PROOF, deficit) を呼び出し、次に sync() を呼び出すことでそれを補充します。これは、通常の swaps を経由せずに、LPペアの準備金から直接 LML を移動させ、ペアの保存状態を再調整します。このパスがペアの価格発見をバイパスするため、それをトリガーする各請求は、トークンの流入なしにペアの LML 準備金を減らし、スポット価格をさらにシフトさせます。そのため、繰り返しの請求は、凍結された保存価格とライブ販売価格の間のギャップを機械的に拡大します。

攻撃分析

以下の分析は、トランザクション 0x805d...5b47、0x70f7...3572 に基づいています。

ステップ1：攻撃者はMoolahからフラッシュローンで大量の USDT と WBNB を集め、VenusとMoolah Pool（WBNB を担保として）から借入し、PancakeSwap V4、複数のV3プール、V2プールからフラッシュローンを行いました。この資本は、LML/USDT ペア価格を操作するために必要でした。
ステップ2：攻撃者は LML トークンコントラクトで swapAndTrans() を呼び出し、コントラクトに蓄積された LML 手数料を USDT にスワップしました。これにより、LML コントラクト自身の LML 残高が drain され、ローカルトークンソースとして機能できなくなりました。その後の報酬分配は、swapBack() を介してLPペアから LML を引き出す必要がありました。

ステップ3：攻撃者はPancakeRouter swapExactTokensForTokensSupportingFeeOnTransferTokens を介して USDT を LML にスワップし、受信者はデッドアドレスに設定されました。購入された LML トークンは、攻撃者が受け取るのではなく燃焼されました。唯一の目的は、ペアから LML を drain し、AMM上の LML 価格をインフレさせることでした。攻撃者はトークン自体を必要としておらず、価格の歪みのみが必要でした。

ステップ4：攻撃者は以前に11のEOAアドレスを使用してステーキングプロトコルに預金していました。APowerの receive() が msg.sender に基づいて _claimReward(msg.sender) をトリガーするため、報酬は預金アドレス自体によってのみ請求できます。11のEOAすべての報酬を単一のトランザクションで請求するために、攻撃者はEIP-7702を使用してこれらのEOAにコードを設定し、攻撃者のメインコントラクトによってコントラクトとして呼び出せるようにしました。各EOAは、APowerに少量の BNB を送信する transfer(rst, fte) 関数を実行し、receive()、_claimReward(EOA) をトリガーしました。各請求の中で：updatePrice() はスキップされました（3600秒のクールダウンに達しなかったため、stored_price は歴史的な低値のままでした）。updateUser() は古い低価格を使用して報酬を計算しました。sendMining() は PROOF から APower に LML を転送し、次に swapBack() をトリガーしてLPペアから LML を引き出し sync() を呼び出すことで PROOF を補充し、ペアの準備金をさらに減らしました。最後に claimReward() は LML をEOAに配布し、各EOAは受け取った LML を攻撃者コントラクトに返送しました。

ステップ5：攻撃者は、著しく drain されたプールを介して、非常にインフレした価格で、蓄積された LML を USDT にスワップしました。
ステップ6：すべてのフラッシュローン、借入、および手数料を返済しました。残りの利益を転送しました。

結論

根本原因は、報酬の発生と償還がステーキングコントラクトで一致しないことです。支払いは3600秒のクールダウンにロックされた保存 LML/USDT 価格からサイズ設定されますが、ライブAMM価格を追跡する LML で決済され、両者をリンクする逸脱チェックはありません。swapBack() 補充パスは、請求ごとにLPペアから直接 LML を drain することでこの欠陥を増幅し、保存価格とライブ販売価格の間のギャップを、請求が処理されるほど機械的に拡大します。

AMM由来の価格から報酬をサイズ設定するステーキングプロトコルは、請求時に保存価格と現在のスポット価格の間の逸脱チェックを強制し、ギャップが安全な閾値を超えた場合にロールバックすべきです。また、通常の swap パス外でLP準備金を変更する補充メカニズムを避けるべきです。なぜなら、そのようなメカニズムは、古い価格設定による損害を抑制する価格発見をバイパスするためです。

6. Tactileインシデント

概要

2026年4月1日、Polygon上のティアード預金プロトコルであるTactileが約1万2,000ドルの損失を被りました。根本原因は、預金と出金の決済ロジックにおける不整合でした。エントリーとエグジットの両方が CES の現在のスポット価格に対して変換され、内部株式は当初ミントされた時点での資産価値の記録を持っていませんでした。攻撃者はこれを悪用し、預金前にスポット価格をインフレさせて過剰な株式を取得し、その後、出金前に価格を低下させて、より多くの CES を株式あたりで償還し、ヘルパーコントラクト全体でサイクルを繰り返して利益を抽出しました。

背景

TactileはPolygon上のティアード預金プロトコルで、ユーザーは選択したティアに従って CES を支払いコントラクトに預金します。必要な預金額は、CES の現在のスポット価格とティア設定から計算され、ユーザーはポジションを表す内部会計株式としてクレジットされます。出金時、記録された株式は、元の預金額に対して決済するのではなく、出口時点のスポット価格を使用して CES に変換されるため、ユーザー残高は実質的に固定資産額ではなく、価格依存の会計単位として追跡されます。

脆弱性分析

支払いコントラクト (0x9153e1...09b654) の中心的な欠陥は、預金と出金が2つの異なる時点で同じスポット価格オラクルに対して決済され、それらをリンクする不変のアンカーがないことです。預金時には、コントラクトは getActualPrice() を読み取り、現在の価格に基づいて預金された CES を内部株式に変換します。出金時には、同じ株式が償還時点のスポット価格を使用して CES に変換されます。

株式自体は、ミントされた時点の価格または資産額の記録を持たないため、これら2つの時点間のスポット価格の移動は、預け入れられた CES と支払われた CES の不一致に直接反映され、プロトコルの会計は、基盤となる資産価値ではなく、価格パスに完全にさらされます。

攻撃分析

以下の分析は、トランザクション 0xc321...da74 に基づいています。

ステップ1：攻撃者はまずUniswap V3フラッシュプールから 55,365e18 の CES を借入し、資金を5つのヘルパーコントラクトに配布しました。各ヘルパーはまず 6,426e18 の CES を受け取り、次に deposit(12) を呼び出しました。このプロセス中、各ヘルパーはまず getPriceForLevel(12) をクエリし、次に現在の価格に基づいてこの預金に必要な CES 金額を準備しました。

ステップ2：5つのヘルパーが最初の deposit ラウンドを完了した後、攻撃者は DEX に 300,000 CES を dump し、bank が使用する価格を 1.067585 から 0.688542 に押し下げました。その後、5つのヘルパーは順番に withdraw を実行し、高価格で作成された株式を、現在低下した価格で CES に償還しました。各ヘルパーは 9,427e18 の CES を受け取りました。

ステップ3：最初の withdraw ラウンドを完了した後、攻撃者は取得したカウンターパーティ資産を CES にスワップし、価格を再び押し上げました。その後、攻撃者はステップ2-3を繰り返しました。
ステップ4：最終的に、複数の攻撃サイクルを経て、フラッシュローンとフラッシュ手数料 166.097975017841805126 CES を返済した後、攻撃者は 567,736e18 の CES を利益として残しました。

結論

このインシデントの根本原因は、Tactileが、預金時点の資産額または価格に会計株式をアンカーすることなく、操作可能なスポット価格に対して預金と出金の両方を決済したことであり、その内部会計はエントリーとエグジット間の価格変動に完全にさらされました。

シェアのようなポジションを変動資産に対して発行するプロトコルは、償還時にライブオラクルに対して再価格設定するのではなく、元の経済的価値を再現するように、各シェアをミント時点の具体的な資産額または価格にアンカーすべきです。決済関数が現行価格を参照する必要がある場合は、時間加重またはその他の操作耐性のあるソースを使用し、決済呼び出しと同じトランザクションで移動できるスポット価格を読み取ることを避けるべきです。

7. SASトークンインシデント

概要

2026年4月2日、BNB Chain上の SAS トークンが約1万2,000ドルでエクスプロイトされました。根本原因は、トークンのカスタム送金ロジックにおける欠陥でした。LPプールへの SAS の送信は、グローバルな sellBurn カウンターをインクリメントするだけで、その後の通常の送金は、AMM のスワップロジックを経由せずに、プールから直接 SAS を燃焼させ、sync() を呼び出してその準備金を書き換えることができました。攻撃者は、セールを通じて sellBurn を蓄積し、無関係な通常の送金をトリガーしてプールから SAS を燃焼させ、その準備金を1 weiに押し下げ、その後、残りの SAS を逆スワップして利益を得ることでこれを悪用しました。

背景

SAS は、PancakeSwap V2プールの上に構築されたカスタム送金ロジックを持つBNB Chain上のデフレトークンです。その transfer() 関数は2つのパスを区別します。宛先がLPプールである送金パスは、送信量だけグローバルな sellBurn アキュムレータをインクリメントします。そして、通常の送金パスは、sellBurn がゼロでない場合、LPプールから直接 SAS を燃焼させ、次に sync() を呼び出して準備金をオンチェーン残高と一致させます。この2つのパスは、累積的な売り圧に応じてプールの SAS 準備金を削減するデフレメカニズムとして連携するように設計されています。

脆弱性分析

SAS トークンコントラクト (0xbfa266...3d91c6) の中心的な欠陥は、デフレメカニズムが transfer() にどのように配線されているかです。SAS がLPプールに送信されると、コントラクトは送信量だけ sellBurn アキュムレータをインクリメントします。その後、後続の通常の送金で sellBurn がゼロでない場合、コントラクトは _burnFromPair() を呼び出してLPプールから直接 SAS を燃焼させ、それに sync() を続けます。これはプールの準備金をオンチェーン残高と一致するように書き換えます。

問題は、この燃焼・同期パスが AMM のスワップロジックを経由せずにプールの準備金を書き換えることです。sellBurn がプールへの送金によって増加すると、無関係な通常の送金が燃焼と同期をトリガーするのに十分となり、プールの SAS 準備金をゼロに近づけ、その後通常のスワップで収穫できる大きな価格の歪みを生成します。

攻撃分析

以下の分析は、トランザクション 0x878e...adc5 に基づいています。

ステップ1：攻撃者はフラッシュローンで WBNB を借入しました。
ステップ2：攻撃者は WBNB を SAS にスワップしました。
ステップ3：攻撃者はコントラクトをデプロイし、constructor() で攻撃ロジックを実行しました。これは、トークンコントラクトが transfer() の送信元がホワイトリストに登録されたウォレットまたはEOAであることを要求したため、プロトコルの is_contract() チェックをバイパスするために使用されました。

ステップ4：攻撃者は SAS をプールに転送し、これがセルフパスをトリガーし、sellBurn を蓄積させました。

ステップ5：攻撃者は2番目のコントラクトをデプロイし、再びその constructor() 内で、通常の送金を開始しました。ステップ4から既に sellBurn がゼロでないため、この送金は _burnFromPair() 関数をトリガーし、LPプールから直接 SAS を燃焼させ、次に sync() 関数を呼び出して SAS 準備金を1 weiに削減しました。

ステップ6：攻撃者は逆スワップを実行し、残りの SAS を売却して利益を得ました。

結論

このインシデントの根本原因は、SAS トークンのカスタム送金ロジックにおける欠陥でした。通常の送金は、LPプールから直接 SAS を燃焼させ、その準備金を削減された残高に同期させることができ、累積的な売り圧力をプールの SAS 準備金の任意削減に変換し、そこから通常のスワップで収穫できる大きな価格の歪みを生成しました。

トークンは、外部の AMM プールに侵入して、通常のスワップパス外でその準備金を変更すべきではありません。デフレ設計が実際にプールからの燃焼を必要とする場合、燃焼とそれに伴う sync() は、信頼されたキーパーやレート制限付きスケジュールなどの厳密に制御された内部トリガーにバインドされる必要があります。これは、任意のユーザー転送に依存するのではなく、です。

8. Unknown-EIP-7702インシデント

概要

2026年4月3日、EIP-7702による委譲コードを有効にしていたBNB Chain上のユーザーアカウントが、約1万7,200ドルで drain されました。委譲されたコードは、適切なアクセス制御なしに pancakeV3SwapCallback() 関数を公開していました。攻撃者はこのコールバックを細工されたコールデータで直接呼び出し、被害者アカウントにトークンを攻撃者制御のウォレットに移転させました。

背景

被害者のEOAは、EIP-7702 Type-4トランザクションを使用して委譲コードを設定し、アカウントがスワップ関連ロジックを実行できるようにしました。しかし、委譲された実装には、正当なPancakeSwap V3プールコールバック中にのみ呼び出されるはずの公開 pancakeV3SwapCallback() 関数が含まれていました。

脆弱性分析

根本原因は、委譲されたコントラクト（0x02C809...aEDbAE）の pancakeV3SwapCallback() 関数におけるアクセス制御の欠落です。

正しいUniswapV3/PancakeV3コールバック設計では、コールバックは msg.sender が期待される正規プール（ファクトリー+トークンペア+手数料から派生、または信頼できるプールリストとの検証）であることを検証する必要があります。この場合、その検証が欠落していたため、外部の呼び出し元はコールバックを直接呼び出すことができました。

コールバックは、それをホストするアカウントからトークンを転送するため、msg.sender チェックの欠落は、正の amount0Delta/amount1Delta を持つ外部呼び出しがコールバック内の支払いパスに入り、実際のスワップが発生せずにトークンを被害者アカウントから移動させることができることを意味します。

攻撃分析

以下の分析は、トランザクション 0x5b2c...4261 に基づいています。

ステップ1：攻撃者は、細工されたパラメータで pancakeV3SwapCallback() を直接呼び出し、コールバック転送ロジックをトリガーして、被害者のトークンを攻撃者制御のウォレットに移転させました。

結論

このインシデントは、厳密なコールバック認証なしにEIP-7702アカウントにスワップコールバックロジックをデプロイしたことによって引き起こされました。pancakeV3SwapCallback() にアクセス制御が欠けていたため、コールバックは任意の外部呼び出し元によって呼び出され、正規のスワップが発生することなく被害者アカウントからトークンを移動させるために使用されました。

V3スタイルのコールバックを実装するコントラクトまたは委譲されたEIP-7702コードの場合、開発者は、コールバックが譲渡ロジックに入る前に、msg.sender が正規のPancakeV3プール（信頼できるファクトリー、トークンペア、および手数料ティアから派生）であることを検証する必要があります。

9. Silo Financeインシデント

概要

2026年4月3日、Arbitrum上のSilo Finance soUSDC ボールトが約35万9,000ドルでエクスプロイトされました。根本原因は3つの欠陥の収束でした。市場価格が約0.12に暴落した後も依然として約1.133でトークンを評価していた不変の wstUSR オラクル、ボールト自体の預金のみを制限し外部預金は制限しなかった soUSDC の供給キャップメカニズム、そして totalAssets() 会計上の欠陥で、対応する soUSDC 株式をミントすることなく外部でクレジットされた bUSDC 株式をカウントしていました。攻撃者は、ゼロキャップの wstUSR 市場に USDC を receiver=soUSDC として直接預金することでボールトの株式価格をインフレさせ、過大評価された wstUSR 担保に対して同じ USDC を借入し、インフレした評価額で以前取得した soUSDC 株式を償還しました。その差額は、出金キュー内の他の健全な市場から引き出されました。

背景

Silo Financeは、Arbitrum上のリスク分離型貸付プロトコルです。各Silo市場は双方向の貸付ペア（例：wstUSR/USDC）です。借り手は担保（wstUSR）を預金し、貸付資産（USDC）を借入します。貸し手は USDC を預金し、利息を獲得します。貸し手が特定の市場に USDC を預金すると、その市場の預金株式トークンを受け取ります。借り手が担保を預金すると、担保株式トークン（例：bwstUSR-149）を受け取ります。

soUSDC は、複数のSilo市場の上に位置するSiloVaultで、USDC 貸付を統合します。ユーザーは soUSDC に USDC を預金し、soUSDC 株式を受け取ります。その後、ボールトは、アロケーターによって設定された供給キャップに基づいて、承認されたSilo市場に預金された USDC をルーティングし、ボールト自体は、預金した各市場の bUSDC 株式を保持します。ユーザーが soUSDC 株式を償還すると、ボールトは totalAssets() を使用して株式が USDC でいくらの価値があるかを計算します。これは、出金キュー内のすべての市場を反復処理し、各市場でのボールトの bUSDC 株式残高を合計します。その後、ボールトは市場から USDC を引き出して償還者に支払います。

wstUSR （Wrapped Staked USR）は、Resolvによって発行されたステーブルコイン USR のステーキングデリバティブです。Resolvがエクスプロイトされた後、USR はペッグを失い、stUSR もペッグを失い、wstUSR の二次市場価格は約0.12に暴落しました。しかし、wstUSR のChainlinkフィードは wstUSR/stUSR 交換レート（約1.133）のみを追跡しており、プロトコルは暗黙的に1 stUSR = 1 USDと仮定していたため、オラクルは wstUSR を約1.133で評価し続け、市場現実に対して約10倍のギャップがありました。

脆弱性分析

wstUSR/USDC 市場のオラクルアドレスは、SiloConfig に不変としてハードコードされており、置き換えることができません。オラクルコントラクト自体（0x836a1a...04425e）は ChainlinkV3Oracle であり、その基盤となるChainlinkフィード（説明：「wstUSR / stUSR 交換レート」）は wstUSR から stUSR へのラップ比率（約1.133）のみを追跡し、二次市場価格は追跡しません。プロトコルは暗黙的に1 stUSR = 1 USDと仮定しているため、wstUSR を約1.133で評価しています。USR がペッグを失った後、stUSR もペッグを失い、wstUSR はオープンマーケットで約0.12に暴落しましたが、オラクルは依然として約1.133を報告し続け、約10倍の過大評価でした。

プロトコルはこのリスクを部分的に認識していました。soUSDC の wstUSR 市場に対する供給キャップは0に設定されていたため、ボールトは自発的に USDC をそこへルーティングしませんでした。しかし、このキャップはボールト自身の発信 deposit() コールのみを制限します。wstUSR_Market.deposit() は任意の receiver パラメータを受け入れるため、誰でも USDC を直接 wstUSR 市場に預金し、結果の bUSDC 株式を soUSDC のアドレスにクレジットすることができます。これにより、供給キャップを完全に回避できます。

これにより、コアとなるエクスプロイトパスが作成されます。bUSDC 株式がそのような外部預金を通じて soUSDC の残高に着地すると、totalAssets() はそれらをカウントします。これは、すべての市場を反復処理し、ボールトの実際の株式残高を読み取ります。自発的に入力されたポジションであるかどうかのチェックはありません。一方、ボールト自身のミントロジックが呼び出されなかったため、これらの外部クレジットされたポジションに対応する新しい soUSDC 株式はミントされません。結果として、totalAssets は増加しますが、totalShares は同じままになり、soUSDC の株式価格がインフレします。

攻撃分析

以下の分析は、トランザクション 0xf77a...f3e1 に基づいています。

攻撃者はまず、二次市場で wstUSR を約0.12で（1トークンあたり）購入しました。

ステップ1：Morphoから約4,236,352 USDC をフラッシュローンしました。オラクルによる誤った価格設定だけでは十分ではありません。wstUSR 市場には USDC 流動性がゼロでした（キャップ=0、soUSDC はそこに預金したことがありません）。そのため、過大評価された担保に対して借りるものがありませんでした。フラッシュローンは、後続の預金と寄付のステップに必要な資本を提供します。
ステップ2：wstUSR を wstUSR 市場に担保として預金し、bwstUSR-149 を受け取りました。これはステップ5の借入の準備です。オラクルは13,797 wstUSR を約15,633（1.133あたり）と評価しますが、攻撃者は約1,656しか支払っていません。

ステップ3：約4,222,007 USDC を soUSDC ボールトに預金し、soUSDC 株式（全供給量の約91.5%）を受け取りました。ボールトはこの USDC を既存の健全な市場（wstUSR 市場ではない、キャップ=0のため）にルーティングします。これらの soUSDC 株式は、ステップ6で利益を抽出するための手段です。攻撃者がより多くの株式を保有するほど、株式価格がインフレしたときに利益が増加します。

ステップ4：約14,344 USDC を wstUSR 市場に直接、wstUSR_Market.deposit(receiver=soUSDC) を介して預金し、bUSDC-149 を soUSDC にミントしました。結果の bUSDC 株式は、攻撃者ではなく、soUSDC のアドレスにクレジットされました。これはコアとなる操作です。soUSDC の totalAssets() は、これらの bUSDC 株式を額面価値（約14,344 USDC）で含みますが、ボールト自体の預金ロジックが呼び出されなかったため、新しい soUSDC 株式はミントされません。totalAssets は増加し、totalShares は同じままになり、soUSDC の株式価格がインフレします。同時に、これは以前空だった wstUSR 市場に USDC 流動性を生成し、次のステップで必要になります。

ステップ5：ステップ2で預金した担保を使用して、wstUSR 市場から約14,344 USDC を借入しました。オラクルは担保を約15,633と評価するため、最大LTVの92%で、攻撃者は約14,344を借りることができます。これにより、ステップ4で寄付された USDC が回収されます。借入と寄付はキャッシュニュートラルです。しかし、wstUSR 市場は完全に drain されました。すべての USDC が借入され、ほとんど価値のない wstUSR 担保に裏付けられた未払いのローンのみが残りました。soUSDC は依然として totalAssets() で bUSDC 株式を額面価値で保持しています。

ステップ6：ステップ3で取得したすべての soUSDC 株式を償還しました。ステップ4の寄付により、株式価格はインフレしたため、攻撃者は約4,235,143 USDC を受け取りました。これは、ステップ3で預金した4,222,007よりも約13,136多くなります。ボールトは wstUSR 市場から引き出そうとしますが、流動性がない（ステップ5で借入済み）ため、出金キュー内の他の健全な市場から差額を引き出します。ここで損失が発生します。他の soUSDC 預金者の市場からの実際の USDC が、インフレした償還をカバーするために転送されます。

ステップ7：フラッシュローンを返済しました。

32回のループの後、soUSDC は wstUSR 市場に bUSDC ポジションを保持していますが、その額面価値は約35万9,000ドルですが、wstUSR 担保はそれよりもはるかに価値が低いです。利用率100%、実質的に回収不可能な不良債権は、残りの soUSDC 預金者が負担します。

結論

このインシデントは、ステーキング交換レートを追跡するオラクル（ペッグを失った資産の市場価格ではなく）、totalAssets() で外部クレジットされたポジションを株式をミントせずにカウントするボールト会計システム、そしてボールト自体の預金のみを制限し外部預金は制限しなかった供給キャップメカニズムという3つの欠陥の収束によって引き起こされました。SiloConfig にオラクルアドレスが不変であることが、問題が明らかになった後の緊急修正を防ぎました。

貸付市場を統合するボールトプロトコルは、totalAssets() がボールト自身の預金操作を通じて入力されたポジションのみをカウントし、外部クレジットされた株式残高はカウントしないことを保証すべきです。オラクルアドレスは永久に不変であってはならず、基盤となる資産がペッグを失った場合の価格フィード更新のために、緊急ガバナンスメカニズムが存在すべきです。

BlockSecについて

BlockSecは、フルスタックのブロックチェーンセキュリティおよび暗号コンプライアンスプロバイダーです。私たちは、顧客がコード監査（スマートコントラクト、ブロックチェーン、ウォレットを含む）、リアルタイムでの攻撃傍受、インシデント分析、不正資金追跡、およびAML/CFT義務の遵守を、プロトコルとプラットフォームのライフサイクル全体にわたって実行できるようにする製品とサービスを構築しています。

BlockSecは、著名な会議で複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションの数多くのゼロデイ攻撃を報告し、複数のハッキングをブロックして2,000万ドル以上を救済し、数十億ドル相当の暗号通貨を保護してきました。

公式ウェブサイト：https://blocksec.com/
公式Twitterアカウント：https://twitter.com/BlockSecTeam
🔗 BlockSec監査サービス : リクエストを送信
🔗 Phalcon Security APP: デモを予約
🔗 Phalcon Compliance