During the past week (Jan 25-Feb 1, 2026), BlockSec detected and analyzed six attack incidents, with total estimated losses of ~$18.05M. The table below summarizes these incidents, and detailed analyses for each case are provided in the following subsections.
| Date | Incident | Type | Estimated Loss |
|---|---|---|---|
| 2026/01/25 | SwapNet Incident | Improper input validation | ~$13.41M |
| 2026/01/25 | Aperture Finance Incident | Improper input validation | ~$3.67M |
| 2026/01/27 | PGNLZ Incident | Token design flaw | ~$100K |
| 2026/01/28 | XPlayer Incident | Token design flaw | ~$717K |
| 2026/01/28 | Holdstation Incident | Key compromise | ~$100K |
| 2026/01/30 | Revert Finance Incident | Business logic flaw | ~$50K |
1. SwapNet Incident
Brief Summary
On January 25, 2026, the SwapNet protocol on Base, BSC, and Arbitrum was exploited, resulting in approximately $13.41 million in losses. The incident stemmed from insufficient validation of user-supplied inputs, which allowed an attacker to craft calls that invoked transferFrom() with attacker-controlled parameters. By abusing existing token allowances, the attacker effectively executed transfers in the form of token.transferFrom(victim, attacker, amount), enabling them to drain victims' approved assets.
Background
The protocol SwapNet is a DEX aggregator designed to find optimal swap routes by aggregating liquidity from multiple onchain sources, including AMMs and private market makers. The protocol also allows users to specify custom routers or pools when executing swaps, offering additional flexibility.
Vulnerability Analysis
This incident stems from insufficient validation of user-supplied inputs, which allows an attacker to trigger transferFrom() calls with arbitrary parameters. As a result, assets that had been previously approved to the victim contracts (e.g., 0x616000e384Ef1C2B52f5f3A88D57a3B64F23757e) could be transferred to the attacker.
Based on decompiled bytecode, the function 0x87395540() appears to lack proper validation on critical inputs. By replacing the expected router or pool address with a token address (e.g., USDC), the contract incorrectly treats the token as a valid execution target. This leads to a low-level call being executed with attacker-controlled calldata.
Consequently, the victim contract performs calls of the form: approvedAsset.transferFrom(victim, attacker, amount), allowing the attacker to siphon all approved assets.
Attack Analysis
Multiple attacks were observed against SwapNet. Here we use the Base transaction 0xc15df1d131e98d24aa0f107a67e33e66cf2ea27903338cc437a3665b6404dd57 as an example. The attacker simply invoked the function 0x87395540() of the victim contract with malicious inputs. This invocation consists of two main steps.
-
A key internal variable (e.g.,
v51) was set toUSDC, bypassing intended routing logic.
-
A low-level call was executed using attacker-controlled calldata, resulting in
USDC.transferFrom()being invoked and all approvedUSDCbeing drained.
Conclusion
The incident is caused by insufficient validation of user-supplied inputs, and adding proper input parameter checks to the function would help mitigate this issue.
2. Aperture Finance Incident
Brief Summary
On January 25, 2026, the Aperture protocol on Ethereum, Base, and Arbitrum was exploited, resulting in approximately $3.67 million in losses. The root cause was insufficient validation of user-supplied inputs, which allowed an attacker to trigger transferFrom() calls with arbitrary parameters via the internal function 0x1d33(). As a result, the attacker was able to perform calls like approvedToken.transferFrom(victim, attacker, amount), enabling them to siphon off all approved assets.
Background
Aperture Finance is a DeFi protocol that manages concentrated liquidity positions, such as Uniswap V3 LPs, on behalf of users. Its closed-source contracts (e.g., 0xD83d960deBEC397fB149b51F8F37DD3B5CFA8913) allow users to mint and manage Uniswap V3 positions using native tokens.
Intended Workflow for Minting Uniswap V3 Positions
When minting Uniswap V3 positions via the function 0x67b34120(), the contract follows an intended three-step workflow:
-
Wrap native tokens
-
Swap wrapped tokens via the internal function
0x1d33() -
Mint UniswapV3 positions
The issue arises in Step 2: The internal function 0x1d33() performs a customized swap through a low-level call, where critical parameters (e.g., the call target and calldata) appear to be user-controlled and insufficiently validated, enabling unintended external calls. More details are provided in the following sections.
Vulnerability Analysis
The incident is caused by insufficient input validation on low-level calls. When the function 0x67b34120() is invoked, the internal function 0x1d33() executes a low-level call using calldata supplied by the user, without enforcing strict constraints on the call target or function selector.
As shown in the figure below, the calldata used to trigger the low-level call is purely based on the attacker's inputs.
This enables attackers to construct malicious calldata that results in: approvedToken.transferFrom(victim, attacker, amount) executed in the context of the victim contract. As a result, not only ERC20 tokens but also approved Uniswap V3 position NFTs can be siphoned.
Attack Analysis
Multiple attacks were observed against Aperture Finance. In this section, we use the Ethereum transaction 0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25a as a representative example.
-
The attacker created an attack contract
0x5c92884dFE0795db5ee095E68414d6aaBf398130. -
The attack contract invoked the function
0x67b34120()with malicious inputs and 100 wei ETHs (i.e., msg.value == 100).
-
a. The native ETHs was wrapped into WETHs via the function
WETH.deposit().
-
b. The internal function
0x1d33()was invoked to perform a low-level call. In this step, a call ofWBTC.transferFrom(victim, attacker, amount)is invoked in the context of the victim contract, allowing the attacker to siphon approved tokens. It is worth noting that a balance check was passed at the end of the function0x1d33(). Specifically, the function0x1d33()compared the balance changes with the a swap output value (i.e.,varg2.word2) specified by the attacker as well. As a result, were executed successfully by receiving nothing.
-
c. Lastly, the function
NonfungiblePositionManager.mint()was invoked to mint a position for the attacker using 100 wei WETH.
Interesting Findings
By comparing normal and abnormal minting transactions, we observed that both transactions approved tokens to the same spender (e.g., OKX DEX: TokenApprove) but specified different router addresses (i.e., DexRouter and WBTC). This suggests that the contract may enforce validation on the approval spender while failing to validate the actual execution target, leaving a critical gap exploitable via arbitrary calls.
Normal transaction: tx link1
Abnormal transaction: tx link2
Conclusion
The incident is caused by insufficient validation of user-supplied inputs. Adding proper input validations would help mitigate this issue.
3. PGNLZ Incident
Brief Summary
On January 27, 2026, the PancakeSwap V2 USDT–PGNLZ pool on BNB Smart Chain was exploited, causing approximately $100K in losses. The root cause was a flawed burn mechanism in the PGNLZ token that allowed the attacker to burn PGNLZ directly from the pool’s balance. This artificially reduced the pool's PGNLZ reserves, creating a sharp reserve imbalance and distorting the on-chain price. The attacker then leveraged the manipulated price to execute swaps that drained USDT from the pool.
Background
The PGNLZ token introduces a burn mechanism targeting a PancakeSwap V2 pool. The burn mechanism can be triggereed under certain conditions. Specifically, for each purchases in the pool, the token checks whether the pool’s USDT balance has reached a predefined threshold. Once the threshold is reached, it burns a certain amount of PGNLZ from the pool and sets tradingEnabled = true, enabling regular users to interact with the pool thereafter. When the trading mode is enabled and a user sells PGNLZ in the pool, the token first burns an amount of PGNLZ held by the pool based on the previous user’s PGNLZ selling amount.
Vulnerability Analysis
The core issue was the flawed burn mechanism introduced by the token PGNLZ, which is vulnerable to a price manipulation attack. Specificaly, an attacker is allowed to circumvent the trading mode limitation to manipulate the pool's reserves (i.e., buying PGNLZ) by setting the recipient as the isExcludedFromFee address (i.e., 0xdEaD). Then, the attacker leverage the burn mechanism (i.e., via the function _executeBurnFromLP()) to directly burn PGNLZ from the pool, further manipulating the pool's reserves. As a result, the attacker can make profits by performing a reverse swap (i.e., selling PGNLZ) in the manipulated pool.
Attack Analysis
The following analysis is based on the transaction: 0xc7270212846136f3d103d1802a30cdaa6f8f280c4bce02240e99806101e08121
-
The attacker borrowed
1,059e18 BTCBvia a flash loan in Moolah and borrowed30,000,000e18 USDTby supplying1,059e18 BTCBin Venus. -
The attacker swapped
23,337,952e18 USDTfor978,266e18 PGNLZin the PancakeSwap V2 pool when the trading mode was disabled. The attacker made the swap possible by setting the recipient to0xdEaD, which bypassed the corresponding validations. -
The attacker swapped preciously owned
17e18 PGNLZforUSDTin the PancakeSwap V2 pool. During this swap, the function_executeBurnFromLP()was triggered, burning4,240e18 PGNLZfrom the pool (i.e., based on the previousPGNLZsell amount). This burning process left the pool's reserve with only0.00000001e18 PGNLZ, further manipulating the pool'sPGNLZreserve. With the depletedPGNLZreserve, the attacker was able to drain23,438,853e18 USDTfrom the pool with just17e18 PGNLZ. -
The attacker repaid the position in Venus and ultimately made a profit of
100,901e18 USDT.
Conclusion
The root cause of this incidents steams from the flawed burn mechanism of PGNLZ, which allowed attackers to drain USDTfrom the pool by perform a price manipulation attack. As a result, the incident incurred total losses of approximately $100K. To mitigate such issues, the project must implement a proper access controls within the system and conduct a comprehensive testing of their burn mechanism to avoid potential price manipulation attacks.
4. XPlayer Incident
Brief Summary
On January 28, 2026, the PancakeSwap V2 XPL/USDT pool on BNB Smart Chain was exploited, resulting in approximately $717K in losses. The incident was caused by a flawed burn mechanism in the XPL token that allowed an attacker to burn XPL directly from the pool’s balance. By artificially reducing the pool's XPL reserves, the attacker created a severe reserve imbalance and distorted the swap price, then exploited the manipulated pricing to drain USDT from the pool.
Background
The token XPL introduces a burn mechanism, which burns XPL tokens from the corresponding pool and then calls the function sync() to refresh the pool's reserves. Specifically, in the contract NodeDistributePlus, the function DynamicBurnPool() can be called to perform a daily burn task within a execution window. The burning amount must not exceed the remaining daily burn cap.
Vulnerability Analysis
The root cause of this incident stems from the flawed burn mechanism of the contract XPL. In particular, the function DynamicBurnPool() in the contract XPL allows certain privileged addresses to burn XPL directly from the liquidity pair.
One of these privileged addresses is the contract NodeDistributePlus (i.e., nodeShareAddress), which implements a daily burn schedule. After a privileged account sets the daily burn target, any caller can call NodeDistributePlus.DynamicBurnPool()within a 2-day window until the daily burn cap is reached.
As a result, this design allows anyone to burn XPL from the corresponding pool and force a reserve update. An attacker can leverage this design to manipulate the pool reserves and execute a reverse swap to siphon off USDT in the pool.
Attack Analysis
The following analysis is based on the transaction: 0x9779341b2b80ba679c83423c93ecfc2ebcec82f9f94c02624f83d8a647ee2e49
-
The attacker borrowed approximately
239,523,169e18 USDTvia flash loans.
-
The attacker swapped
100e18 USDTfor69e18 XPL. This step synced the pool's reserves with the current balances.
-
The attacker swapped
217,118,801e18USDTfor approximately691,022e18XPL. This step was carefully sized to set up the pool state for the subsequent reserve manipulation.
-
The attacker invoked the function
DynamicBurnPool()to burn3,078e18 XPLfrom the pool. This burning process further manipulated the pool'sXPLreserve to an extremely small value (e.g., 1 wei).
-
The attacker swapped
69e18 XPLfor218,083,490e18 USDTwith the manipulated reserves.
-
The attacker repaid the flash loan and made a profit of
718,844e18 USDT.
Conclusion
This incident is caused by a flawed burn mechanism, which allows anyone to burn XPL directly from the pool to manipulate its reserves. As a result, this flawed design allows attackers to peform a price manipulation attack to drain valuable assets in the pool. To mitigate similar issues, projects should prevent arbitrary burning of assets from the pool.
5. Holdstation Incident
Brief Summary
On January 28, 2026, Holdstation reported a compromise involving a takeover of a project-controlled wallet, with total estimated losses of ~$100K. The attacker drained multiple assets worth ~$66K, including WLD, USD1, BNB, and BERA, across World Chain, BSC, Berachain, and zkSync, then consolidated the proceeds on Ethereum at approximately 22.41 ETH before bridging them to Bitcoin at about 0.755 BTC. The incident was traced to the compromise of a team member's device, reportedly through a malicious IDE or browser extension, which enabled the wallet takeover.
Vulnerability Analysis
The breach originated from a malicious coding or browser extension installed by a core developer, representing an operational-level human error. Specifically, the developer installed a malicious and untrusted IDE/browser extension, which resulted in account compromise and financial losses.
Attack Analysis
The related addresses and bridging transactions are listed below:
Attacker Addresses
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d0x9d3a398cc667b97841a2a92ba808ee8dd368a1f2bc1qykmc6mllm3s4zpldww764v6vcgtqwshyw02k9c
Victim Addresses
- (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
Bridging Transactions
-
World Chain → Ethereum
- Amount:
114,308 WLD → 15.317 ETH - Sender:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Recipient:
0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d - TXs:
- Amount:
-
BSC → Ethereum
- Amount:
10.09 BNB → 2.992 ETH - Sender:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Recipient:
0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d - TXs:
- Amount:
-
BSC → Ethereum
- Amount:
6,101.6 USD1 → 2.027 ETH - Sender:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Recipient:
0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d - TXs:
- Amount:
-
Berachain → Ethereum
- Amount:
7,185 BERA → 1.45 ETH - Sender:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Recipient:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - TXs:
- Amount:
-
Ethereum → Ethereum
- Amount:
22.41 ETH → 22.41 ETH - Sender:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Recipient:
0x9D3A398cC667B97841a2A92ba808ee8dD368a1f2 - TXs:
- Amount:
-
Ethereum → Bitcoin
- Amount:
22.41 ETH → 0.755 BTC - Sender:
0x9d3a398cc667b97841a2a92ba808ee8dd368a1f2 - Recipient:
bc1qykmc6mllm3s4zpldww764v6vcgtqwshyw02k9c - TXs:
- Amount:
Conclusion
The root cause of this incident stems from a key comprimise. Admin keys, particularly those associated with key roles (e.g., owner) in core contracts, should be carefully managed. It is recommended to use multisig wallets to avoid single points of failure and enhance systemic robustness.
6. Revert Finance Incident
Brief Summary
On January 30, 2026, Revert Finance on Base was exploited, resulting in approximately $50K in losses. The root cause was a business logic flaw in the GaugeManager contract that allowed an attacker to withdraw collateral without repaying the corresponding debt. By abusing executeV3UtilsWithOptionalCompound(), the attacker bypassed the intended debt repayment flow and extracted funds.
Background
Revert Finance is a comprehensive tool platform designed for Automated Market Maker (AMM) liquidity providers (LPs). It primarily offers analysis, management, automation, and lending features to help LPs improve capital efficiency and risk control.
In the protocol, users can deposit their Uniswap v3 positions as collateral to borrow assets from the Revert Finance's lending pools. Additionally, the protocol allows users to stake their positions, which are used as collateral, to earn extra rewards via the function stakePosition().
Vulnerability Analysis
The root cause of the incident was the lack of a solvency check when unstaking positions, which are used as collateral. Specifically, the function executeV3UtilsWithOptionalCompound() allows users to unstake a position by indicating a corresponding instruction (i.e., whatToDo= 1). However, this function lacks a solvency check when unstaking collateralized positions. As a result, an attacker can redeem a collateralized position without repaying the outstanding debts.
Attack Analysis
The following analysis is based on the transaction: 0x10429eaeb479f9149854e4aeb978a35ac02d9688f6e22371712b3878c63a64ab
-
The attacker borrowed
10e8 cbBTCand10,000,000e6 USDCvia a flash loan to mint a position (i.e., NFT). -
The attacker pledged the NFT as collateral and borrowed
49,000e6 USDC. -
The attacker staked the collateralized NFT via the function
stakePosition(). -
The attacker instantly unstaked the collateralized NFT using the function
executeV3UtilsWithOptionalCompound(). Specifically, the collateralized position was burned, and the corresponding underlying assets were collected by the attacker. Due to the absence of solvency checks in the unstaking process, the collateralized position was burned without settling its corresponding debts.
- The attacker repaid the flash loan and made a profit of
49,000e6 USDC.
Conclusion
The root cause of the incident is the lack of a solvency check when unstaking collateralized positions. This incident underscores the importance of solvency checks in lending-like protocols. Implementing robust solvency measures for every use of the position is essential to ensure stability and reliability.
References
[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
