Web3セキュリティインシデント週次まとめ | 2026年1月25日~2月1日

Web3セキュリティインシデント週次まとめ | 2026年1月25日~2月1日

過去1週間(2026年1月25日〜2月1日)、BlockSecは6件の攻撃インシデントを検出し分析し、総損失額は約1,805万ドルと推定されます。表はこれらのインシデントをまとめたもので、各ケースの詳細な分析は以下のセクションで提供されます。

日付 インシデント タイプ 推定損失額
2026/01/25 SwapNetインシデント 不適切な入力検証 約1,341万ドル
2026/01/25 Aperture Financeインシデント 不適切な入力検証 約367万ドル
2026/01/27 PGNLZインシデント トークン設計上の欠陥 約10万ドル
2026/01/28 XPlayerインシデント トークン設計上の欠陥 約71.7万ドル
2026/01/28 Holdstationインシデント キーの侵害 約10万ドル
2026/01/30 Revert Financeインシデント ビジネスロジックの欠陥 約5万ドル

1. SwapNetインシデント

概要

2026年1月25日、SwapNetプロトコルがBase、BSC、Arbitrumで悪用され、約1,341万ドルの損失が発生しました。このインシデントは、ユーザー提供の入力の検証が不十分だったことに起因し、攻撃者が攻撃者制御のパラメータでtransferFrom()を呼び出すコールを細工することを可能にしました。既存のトークン承認を悪用することで、攻撃者は効果的にtoken.transferFrom(victim, attacker, amount)という形式の転送を実行し、被害者の承認済み資産を奪うことができました。

背景

SwapNetプロトコルは、AMMやプライベートマーケットメーカーなど、複数のオンチェーンソースからの流動性を集約して最適なスワップルートを見つけるように設計されたDEXアグリゲーターです。また、ユーザーがカスタムルーターまたはプールを指定してスワップを実行できるようにし、さらなる柔軟性を提供しています。

脆弱性分析

このインシデントは、ユーザー提供の入力の検証が不十分であったことに起因し、攻撃者が任意のパラメータでtransferFrom()コールをトリガーすることを可能にしました。その結果、以前に被害者コントラクト(例: 0x616000e384Ef1C2B52f5f3A88D57a3B64F23757e)に承認されていた資産が攻撃者に転送される可能性がありました。

逆コンパイルされたバイトコードに基づくと、関数0x87395540()は重要な入力に対する適切な検証を欠いているようです。期待されるルーターまたはプールのアドレスをトークンアドレス(例: USDC)に置き換えることで、コントラクトは誤ってトークンを有効な実行ターゲットとして扱います。これにより、攻撃者制御のcalldataで低レベルコールが実行されます。 1.1.png 1.2.png 結果として、被害者コントラクトはapprovedAsset.transferFrom(victim, attacker, amount)という形式のコールを実行し、攻撃者が承認済みのすべての資産を吸い上げることができるようになります。

攻撃分析

SwapNetに対して複数の攻撃が観測されました。ここでは、Baseトランザクション0xc15df1d131e98d24aa0f107a67e33e66cf2ea27903338cc437a3665b6404dd57を例として使用します。攻撃者は単に被害者コントラクトの関数0x87395540()を悪意のある入力で呼び出しました。この呼び出しは、主に2つのステップで構成されます。

  1. 内部の主要変数(例: v51)がUSDCに設定され、意図されたルーティングロジックをバイパスしました。 1.3.png

  2. 攻撃者制御のcalldataを使用した低レベルコールが実行され、USDC.transferFrom()が呼び出され、承認済みのすべてのUSDCが吸い上げられました。 1.4.png

結論

このインシデントは、ユーザー提供の入力の検証が不十分であったことに起因しており、関数に適切な入力パラメータチェックを追加することで、この問題を緩和することができます。

2. Aperture Financeインシデント

概要

2026年1月25日、ApertureプロトコルがEthereum、Base、Arbitrumで悪用され、約367万ドルの損失が発生しました。根本原因は、ユーザー提供の入力の検証が不十分であったことで、攻撃者が内部関数0x1d33()を介して任意のパラメータでtransferFrom()コールをトリガーすることを可能にしました。その結果、攻撃者はapprovedToken.transferFrom(victim, attacker, amount)のようなコールを実行し、承認済みのすべての資産を吸い上げることができました。

背景

Aperture Financeは、ユーザーに代わってUniswap V3 LPなどの集中流動性ポジションを管理するDeFiプロトコルです。そのクローズドソースコントラクト(例: 0xD83d960deBEC397fB149b51F8F37DD3B5CFA8913)により、ユーザーはネイティブトークンを使用してUniswap V3ポジションをミントおよび管理できます。

Uniswap V3ポジションのミントを意図したワークフロー

関数0x67b34120()を介してUniswap V3ポジションをミントする際、コントラクトは意図された3段階のワークフローに従います。

  1. ネイティブトークンのラップ

  2. 内部関数0x1d33()を介したラップトークンのスワップ

  3. UniswapV3ポジションのミント

問題はステップ2で発生します。内部関数0x1d33()は、低レベルコールを介してカスタムスワップを実行します。ここで、重要なパラメータ(例: コールターゲットおよびcalldata)はユーザー制御であり、検証が不十分であるため、意図しない外部コールが可能になります。詳細は以下のセクションで提供されます。

脆弱性分析

このインシデントは、低レベルコールに対する入力検証が不十分であったことに起因します。関数0x67b34120()が呼び出されると、内部関数0x1d33()は、コールターゲットまたは関数セレクターに対する厳密な制約を強制することなく、ユーザーが提供したcalldataを使用して低レベルコールを実行します。 2.1.png

以下の図に示すように、低レベルコールをトリガーするために使用されるcalldataは、攻撃者の入力のみに基づいています。 2.2.png

これにより、攻撃者は以下のような結果をもたらす悪意のあるcalldataを構築できます。approvedToken.transferFrom(victim, attacker, amount)が被害者コントラクトのコンテキストで実行されます。その結果、ERC20トークンだけでなく、承認済みのUniswap V3ポジションNFTも吸い上げられる可能性があります。

攻撃分析

Aperture Financeに対して複数の攻撃が観測されました。このセクションでは、Ethereumトランザクション0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25aを代表的な例として使用します。

  1. 攻撃者は攻撃コントラクト0x5c92884dFE0795db5ee095E68414d6aaBf398130を作成しました。

  2. 攻撃コントラクトは、悪意のある入力と100 weiのETH(つまり、msg.value == 100)で関数0x67b34120()を呼び出しました。

    • a. ネイティブETHは、関数WETH.deposit()を介してWETHにラップされました。 2.3.png

    • b. 内部関数0x1d33()が低レベルコールを実行するために呼び出されました。このステップでは、WBTC.transferFrom(victim, attacker, amount)のコールが被害者コントラクトのコンテキストで呼び出され、攻撃者が承認済みトークンを吸い上げることが可能になりました。 0x1d33()関数の最後で、残高チェックが通過したことは注目に値します。具体的には、関数0x1d33()は、残高変更を攻撃者が指定したスワップ出力値(すなわち、varg2.word2)と比較しました。その結果、何も受け取らずに実行が成功しました。 2.4.png

    • c. 最後に、関数NonfungiblePositionManager.mint()が呼び出され、100 weiのWETHを使用して攻撃者のポジションがミントされました。

興味深い発見

通常のミントトランザクションと異常なミントトランザクションを比較すると、両方のトランザクションが同じスペンダー(例: OKX DEX: TokenApprove)にトークンを承認しましたが、異なるルーターアドレス(すなわち、DexRouterWBTC)を指定していることが観察されました。これは、コントラクトが承認スペンダーに対する検証を強制する一方で、実際の実行ターゲットの検証に失敗する可能性を示唆しており、任意のコールを介して悪用される可能性のある重大なギャップを残しています。

通常のトランザクション: tx link1 2.5.png

異常なトランザクション: tx link2 2.6.png

結論

このインシデントは、ユーザー提供の入力検証が不十分であったことに起因します。適切な入力検証を追加することで、この問題を緩和することができます。

3. PGNLZインシデント

概要

2026年1月27日、BNB Smart Chain上のPancakeSwap V2 USDT–PGNLZプールが悪用され、約10万ドルの損失が発生しました。根本原因は、PGNLZトークンのバーンメカニズムに欠陥があり、攻撃者がプールの残高から直接PGNLZをバーンできることでした。これにより、プールのPGNLZ準備金が人工的に減少し、急激な準備金バランスの不均衡が生じ、オンチェーン価格が歪められました。攻撃者はその後、操作された価格を利用して、プールからUSDTを吸い上げるスワップを実行しました。

背景

PGNLZトークンは、PancakeSwap V2プールを対象としたバーンメカニズムを導入しています。バーンメカニズムは特定の条件下でトリガーできます。具体的には、プールでの購入ごとに、トークンはプールのUSDT残高が所定のしきい値に達したかどうかを確認します。しきい値に達すると、プールから一定量のPGNLZがバーンされ、tradingEnabled = trueが設定され、それ以降は通常のユーザーがプールとやり取りできるようになります。取引モードが有効になっているときにユーザーがプールでPGNLZを売却すると、トークンはまず、前のユーザーのPGNLZ売却額に基づいて、プールが保有するPGNLZの量をバーンします。 3.1.png

脆弱性分析

中心的な問題は、PGNLZトークンによって導入された、価格操作攻撃に対して脆弱な、欠陥のあるバーンメカニズムでした。具体的には、攻撃者は取引モードの制限を回避して、受取人をisExcludedFromFeeアドレス(すなわち、0xdEaD)に設定することで、プールの準備金を操作(すなわち、PGNLZを購入)することが許可されました。その後、攻撃者はバーンメカニズム(すなわち、_executeBurnFromLP()関数を介して)を利用して、プールの準備金をさらに操作しながら、プールから直接PGNLZをバーンしました。その結果、攻撃者は操作されたプールで逆スワップ(すなわち、PGNLZを売却)を実行することで利益を得ることができました。 3.2.png 3.3.png

攻撃分析

以下の分析は、トランザクションに基づいています: 0xc7270212846136f3d103d1802a30cdaa6f8f280c4bce02240e99806101e08121

  1. 攻撃者は、Moolahでフラッシュローンを介して1,059e18 BTCBを借り入れ、Venusに1,059e18 BTCBを供給することで30,000,000e18 USDTを借りました。

  2. 攻撃者は、取引モードが無効になっているときに、PancakeSwap V2プールで23,337,952e18 USDT978,266e18 PGNLZにスワップしました。攻撃者は、受取人を0xdEaDに設定することで、対応する検証をバイパスしてスワップを可能にしました。

  3. 攻撃者は、以前所有していた17e18 PGNLZをPancakeSwap V2プールでUSDTにスワップしました。このスワップ中に、_executeBurnFromLP()関数がトリガーされ、プールから4,240e18 PGNLZがバーンされました(すなわち、以前のPGNLZ売却額に基づいています)。このバーンプロセスにより、プールの準備金は0.00000001e18 PGNLZのみとなり、プールのPGNLZ準備金はさらに操作されました。PGNLZ準備金が枯渇したことで、攻撃者はわずか17e18 PGNLZでプールから23,438,853e18 USDTを吸い上げることができました。

  4. 攻撃者はVenusでポジションを返済し、最終的に100,901e18 USDTの利益を上げました。

結論

このインシデントの根本原因は、PGNLZの欠陥のあるバーンメカニズムにあり、攻撃者は価格操作攻撃を実行してプールからUSDTを吸い上げることができました。その結果、このインシデントにより総損失額は約10万ドルとなりました。このような問題を緩和するためには、プロジェクトはシステム内で適切なアクセス制御を実装し、潜在的な価格操作攻撃を回避するためにバーンメカニズムの包括的なテストを実施する必要があります。

4. XPlayerインシデント

概要

2026年1月28日、BNB Smart Chain上のPancakeSwap V2 XPL/USDTプールが悪用され、約71.7万ドルの損失が発生しました。このインシデントは、XPLトークンのバーンメカニズムに欠陥があり、攻撃者がプールの残高から直接XPLをバーンできることに起因していました。プールのXPL準備金を人工的に減少させることで、攻撃者は深刻な準備金バランスの不均衡を生じさせ、スワップ価格を歪め、その後、操作された価格設定を利用してプールからUSDTを吸い上げました。

背景

XPLトークンはバーンメカニズムを導入しており、対応するプールからXPLをバーンし、その後sync()関数を呼び出してプールの準備金を更新します。具体的には、NodeDistributePlusコントラクトでは、DynamicBurnPool()関数を呼び出して、毎日のバーンキャップを超えない範囲で、毎日のバーンタスクを実行できます。

脆弱性分析

このインシデントの根本原因は、XPLコントラクトの欠陥のあるバーンメカニズムにあります。特に、XPLコントラクトのDynamicBurnPool()関数は、特定の特権アドレスが流動性ペアから直接XPLをバーンすることを許可しています。 4.1.png

これらの特権アドレスの1つが、毎日のバーンスケジュールを実装するコントラクトNodeDistributePlus(すなわち、nodeShareAddress)です。特権アカウントが毎日のバーンターゲットを設定した後、任意の呼び出し元が、毎日のバーンキャップに達するまで、2日間のウィンドウ内でNodeDistributePlus.DynamicBurnPool()を呼び出すことができます。 4.2.png

その結果、この設計により、誰でも対応するプールからXPLをバーンし、準備金の更新を強制することができます。攻撃者はこの設計を利用して、プールの準備金を操作し、逆スワップを実行してプール内のUSDTを吸い上げることができます。

攻撃分析

以下の分析は、トランザクションに基づいています: 0x9779341b2b80ba679c83423c93ecfc2ebcec82f9f94c02624f83d8a647ee2e49

  1. 攻撃者はフラッシュローンで約239,523,169e18 USDTを借りました。 4.png

  2. 攻撃者は100e18 USDT69e18 XPLにスワップしました。このステップで、プールの準備金は現在の残高と同期されました。 4.3.png

  3. 攻撃者は217,118,801e18 USDTを約691,022e18 XPLにスワップしました。このステップは、後続の準備金操作のためにプールの状態を設定するように慎重にサイズ設定されました。 4.4.png

  4. 攻撃者はDynamicBurnPool()関数を呼び出して、プールから3,078e18 XPLをバーンしました。このバーンプロセスにより、プールのXPL準備金はさらに極めて小さな値(例: 1 wei)に操作されました。 4.5.png

  5. 攻撃者は、操作された準備金で69e18 XPL218,083,490e18 USDTにスワップしました。 4.6.png

  6. 攻撃者はフラッシュローンを返済し、718,844e18 USDTの利益を上げました。 4.7.png

結論

このインシデントは、誰でもプールから直接XPLをバーンして準備金を操作できる、欠陥のあるバーンメカニズムに起因します。その結果、この欠陥のある設計により、攻撃者は価格操作攻撃を実行してプール内の価値のある資産を吸い上げることができます。同様の問題を緩和するため、プロジェクトはプールからの資産の任意のバーンを防ぐべきです。

5. Holdstationインシデント

概要

2026年1月28日、Holdstationはプロジェクト管理ウォレットの乗っ取りを伴う侵害を報告し、総推定損失額は約10万ドルでした。攻撃者はWorld Chain、BSC、Berachain、zkSyncにわたるWLDUSD1BNBBERAなどの複数の資産を吸い上げ、その後Ethereumで約22.41ETHに集約してから、約0.755BTCにブリッジしました。このインシデントは、チームメンバーのデバイスの侵害に起因しており、悪意のあるIDEまたはブラウザ拡張機能を通じて発生したと報告されており、ウォレットの乗っ取りを可能にしました。

脆弱性分析

侵害は、コア開発者によってインストールされた悪意のあるコーディングまたはブラウザ拡張機能に端を発しており、運用レベルの人為的ミスを表しています。具体的には、開発者は信頼できない悪意のあるIDE/ブラウザ拡張機能をインストールし、それがアカウント侵害と経済的損失につながりました。

攻撃分析

関連するアドレスとブリッジングトランザクションは以下の通りです。

攻撃者アドレス

  • 0x54e127b8dbf3bebf64bb1d62a195a6f60113130d
  • 0x9d3a398cc667b97841a2a92ba808ee8dd368a1f2
  • bc1qykmc6mllm3s4zpldww764v6vcgtqwshyw02k9c

被害者アドレス

  • (World Chain) 0xa92e09e0a52b7EdEaD75d3125e21bDFB9752C69e
  • (World Chain) 0xD768da05e0E6771Ea81b441026CE9355421eF7c9
  • (World Chain) 0xA581ED1dEB42E8496E5275468C79D250b91d6a75
  • (World Chain) 0x9BD647B2C8Fed689ADd2e7AA8b428d3eD12f75cb
  • (BSC) 0x2Edf158DDCe35733d6f7D9D7227610ca0531f0AD
  • (BSC) 0xA581ED1dEB42E8496E5275468C79D250b91d6a75
  • (Bera Chain) 0xA581ED1dEB42E8496E5275468C79D250b91d6a75
  • (Bera Chain) 0x628cEf732301aDF6d62bB2bcDFeBB291750C4D9a
  • (zkSync) 0xA581ED1dEB42E8496E5275468C79D250b91d6a75
  • (zkSync) 0x8C826F795466E39acbfF1BB4eEeB759609377ba1
  • (zkSync) 0x4Cf7baB01b8D3572b3dC08642ebbE2AD1aCF3B99
  • (zkSync) 0x2Edf158DDCe35733d6f7D9D7227610ca0531f0AD
  • (zkSync) 0x2D2D047c50d7828Aedb6A151bA1717766606Bf33

ブリッジングトランザクション

  • World Chain → Ethereum

    • 金額: 114,308 WLD → 15.317 ETH
    • 送信者: 0x54e127b8dbf3bebf64bb1d62a195a6f60113130d
    • 受信者: 0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d https://relay.link/transaction/0x3c9ca5e83151a4ee146a3a5bb0eacc5614ca7b746b39672b36ac665c5f1ac216
  • BSC → Ethereum

    • 金額: 10.09 BNB → 2.992 ETH
    • 送信者: 0x54e127b8dbf3bebf64bb1d62a195a6f60113130d
    • 受信者: 0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d https://relay.link/transaction/0x60534c760f5233b02630e7ebda98511807421d6a475f0de12e502b2c1c85f67a
  • BSC → Ethereum

    • 金額: 6,101.6 USD1 → 2.027 ETH
    • 送信者: 0x54e127b8dbf3bebf64bb1d62a195a6f60113130d
    • 受信者: 0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d https://relay.link/transaction/0xdddc9df8398727e7ccab44a9d904cfb60bac55ed8cc5c79fdbfc0523e3d84440
  • Berachain → Ethereum

    • 金額: 7,185 BERA → 1.45 ETH
    • 送信者: 0x54e127b8dbf3bebf64bb1d62a195a6f60113130d
    • 受信者: 0x54e127b8dbf3bebf64bb1d62a195a6f60113130d https://www.gas.zip/scan/tx/0x80aea4b294aef92a5eb45d257a5b1f1125d2d74c8373d0b5ba9fc9b069522bdd
  • Ethereum → Ethereum

    • 金額: 22.41 ETH → 22.41 ETH
    • 送信者: 0x54e127b8dbf3bebf64bb1d62a195a6f60113130d
    • 受信者: 0x9D3A398cC667B97841a2A92ba808ee8dD368a1f2 https://app.blocksec.com/phalcon/explorer/tx/eth/0xf4ddf8f50a09e845f273e0a6368cece215f565233f5034a4a6c63ca038959c3c https://app.blocksec.com/phalcon/explorer/tx/eth/0x5d45d28236a0d76a69dd27e78b05f6baf6378e674734a136b6141dbf80687480
  • Ethereum → Bitcoin

    • 金額: 22.41 ETH → 0.755 BTC
    • 送信者: 0x9d3a398cc667b97841a2a92ba808ee8dd368a1f2
    • 受信者: bc1qykmc6mllm3s4zpldww764v6vcgtqwshyw02k9c https://relay.link/transaction/0xafd628dd1e0d508c40d3e3c2895f39902d14d42f9760b25beacdcc25c3419143

結論

このインシデントの根本原因はキーの侵害にあります。コアコントラクトのキーロール(例: オーナー)に関連する管理者キーは慎重に管理する必要があります。単一障害点を回避し、システム全体の堅牢性を高めるために、マルチシグウォレットの使用が推奨されます。

6. Revert Financeインシデント

概要

2026年1月30日、Base上のRevert Financeが悪用され、約5万ドルの損失が発生しました。根本原因は、GaugeManagerコントラクトのビジネスロジックの欠陥であり、攻撃者が対応する債務を返済せずに担保を引き出すことを可能にしました。executeV3UtilsWithOptionalCompound()を悪用することで、攻撃者は意図された債務返済フローをバイパスし、資金を抽出しました。

背景

Revert Financeは、Automated Market Maker(AMM)流動性プロバイダー(LP)向けに設計された包括的なツールプラットフォームです。主に、LPが資本効率とリスク管理を改善するのに役立つ分析、管理、自動化、および貸付機能を提供します。

プロトコルでは、ユーザーはUniswap v3ポジションを担保として預け入れ、Revert Financeの貸付プールから資産を借り入れることができます。さらに、プロトコルは、ユーザーが担保として使用されるポジションをステークして、stakePosition()関数を通じて追加報酬を獲得できるようにします。

脆弱性分析

このインシデントの根本原因は、担保として使用されるポジションをアンステークする際のソルベンシーチェックが欠如していたことです。具体的には、関数executeV3UtilsWithOptionalCompound()は、対応する指示(すなわち、whatToDo= 1)を示すことで、ユーザーがポジションをアンステークすることを許可します。しかし、この関数は担保付きポジションをアンステークする際にソルベンシーチェックを欠いています。その結果、攻撃者は未払い債務を返済せずに担保付きポジションを償還できます。

6.1.png 6.2.png

攻撃分析

以下の分析は、トランザクションに基づいています: 0x10429eaeb479f9149854e4aeb978a35ac02d9688f6e22371712b3878c63a64ab

  1. 攻撃者はフラッシュローンを使用して10e8 cbBTC10,000,000e6 USDCを借り入れ、ポジション(すなわちNFT)をミントしました。

  2. 攻撃者はNFTを担保として抵当に入れ、49,000e6 USDCを借りました。

  3. 攻撃者はstakePosition()関数を介して担保付きNFTをステークしました。

  4. 攻撃者は関数executeV3UtilsWithOptionalCompound()を使用して、直ちに担保付きNFTをアンステークしました。具体的には、担保付きポジションはバーンされ、対応する基盤資産は攻撃者によって回収されました。アンステークプロセスにおけるソルベンシーチェックの不在により、担保付きポジションは対応する債務を決済することなくバーンされました。

6.3.png
6.3.png
  1. 攻撃者はフラッシュローンを返済し、49,000e6 USDCの利益を上げました。

結論

このインシデントの根本原因は、担保付きポジションをアンステークする際のソルベンシーチェックが欠如していたことです。このインシデントは、貸付のようなプロトコルにおけるソルベンシーチェックの重要性を強調しています。安定性と信頼性を確保するためには、ポジションのすべての使用に対して堅牢なソルベンシー対策を実装することが不可欠です。

参照

[1] SwapNet & Aperture https://blocksec.com/blog/17m-closed-source-smart-contract-exploit-arbitrary-call-swapnet-aperture

[2] PGNLZ: https://x.com/Phalcon_xyz/status/2016154398817505595

[3] XPlayer: X Player Official https://x.com/XPlayer_Media/status/2016700861578403910

[4] XPlayer: X Blocksec Phalcon https://x.com/Phalcon_xyz/status/2016521384609067103

[5] Holdstation: https://x.com/Phalcon_xyz/status/2016823122373296583

[6] Revert Finance: https://paragraph.com/@revertfinance/post%E2%80%91mortem-aerodrome-lend-vault-incident-on-base?referrer=0x8cadb20A4811f363Dadb863A190708bEd26245F8

Sign up for the latest updates
Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

During the week of February 9 to February 15, 2026, three blockchain security incidents were reported with total losses of ~$657K. All incidents occurred on the BNB Smart Chain and involved flawed business logic in DeFi token contracts. The primary causes included an unchecked balance withdrawal from an intermediary contract that allowed donation-based inflation of a liquidity addition targeted by a sandwich attack, a post-swap deflationary clawback that returned sold tokens to the caller while draining pool reserves to create a repeatable price-manipulation primitive, and a token transfer override that burned tokens directly from a Uniswap V2 pair's balance and force-synced reserves within the same transaction to artificially inflate the token price.

Top 10 "Awesome" Security Incidents in 2025

Top 10 "Awesome" Security Incidents in 2025

To help the community learn from what happened, BlockSec selected ten incidents that stood out most this year. These cases were chosen not only for the scale of loss, but also for the distinct techniques involved, the unexpected twists in execution, and the new or underexplored attack surfaces they revealed.

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

On August 29, 2025, Panoptic disclosed a Cantina bounty finding and confirmed that, with support from Cantina and Seal911, it executed a rescue operation on August 25 to secure roughly $400K in funds. The issue stemmed from a flaw in Panoptic’s position fingerprint calculation algorithm, which could have enabled incorrect position identification and downstream fund risk.