Weekly Web3 Security Incident Roundup | Feb 23 – Mar 1, 2026

During the past week (2026/02/23 - 2026/03/01), BlockSec detected and analyzed seven attack incidents, with total estimated losses of ~$13M. The table below summarizes these incidents, and detailed analyses for each case are provided in the following subsections.

1. LAXO Incident

Brief Summary

On February 22, 2026, the ERC20 token LAXO on BNB Smart Chain was exploited, leading to approximately $137,320 in losses from the LAXO-USDT pair. The root cause was a flawed burn mechanism that was activated when LAXO was transferred directly to the PancakeSwap pair. Because the router was whitelisted and does not trigger the burn logic in transfer(), the attacker bypassed it: they sent LAXO to the pair and then called the pair’s low-level swap(), which burned pair tokens and called sync(), inflating the price. The attacker then swapped back to USDT for profit.

Background

The LAXO token implements a burn mechanism. When a transfer's recipient is the USDT–LAXO PancakeSwap pair address, the token treats it as a sell: it burns a corresponding amount of tokens from the pair and then calls sync() to update the pair's reserves. Additionally, the LAXO token implements a whitelist (_isExcludedFromFee) to exempt certain addresses (e.g., swap routers) from the burn mechanism and fees.

Vulnerability Analysis

The root cause of the incident was a flawed burn mechanism in the LAXO token. Specifically, transferring LAXO directly to the pair triggers the burn, removing LAXO from the pair and inflating its price. As a result, an attacker can exploit this to realize profits via price manipulation attacks.

Attack Analysis

The attack analysis is based on the transaction 0xd58f3ef6...d98ac7d3.

1. The attacker flashloaned 350,000e18 USDT from PancakeSwap V3.

2. The attacker swapped USDT to LAXO via PancakeSwap Router. To bypass trading restrictions (buyEnabled = false) and fee logic, the attacker created a BNB–LAXO V2 pair and routed trades through it.
   

3. The attacker transferred all held LAXO directly to the USDT–LAXO pair. This reduced the LAXO reserve in the pool while the USDT reserve remained nearly unchanged, dramatically increasing the price of LAXO in the USDT–LAXO pair.

4. The attacker swapped burnAmount of LAXO for ~487,500e18 USDT based on the manipulated price.

5. The attacker repaid the flash loan and retained the remaining USDT as profit.

Conclusion

The root cause of this incident stems from the flawed burn mechanism of LAXO, which allows attackers to drain USDT from the pool via price manipulation attacks. As a result, the incident incurred total losses of approximately $137.3K. To mitigate such issues, the project must conduct comprehensive testing of their burn mechanism to avoid potential price manipulation attacks.

2. YieldBloxDAO Incident

Brief Summary

On February 22, 2026, a lending pool operated by YieldBlox DAO on Stellar's Blend V2 was exploited, resulting in losses exceeding $10 million [1]. The incident was caused by a misconfiguration by the pool operator (YieldBlox DAO) rather than a vulnerability in the smart contracts.

Specifically, the attacker manipulated the USTRY/USDC market on SDEX. The pool’s configured Reflector oracle path accepted the manipulated price, which overvalued USTRY as collateral and enabled the attacker to drain pool assets, including USDC and XLM.

Background

On the Stellar blockchain, Blend V2 is a liquidity protocol that enables users to create isolated lending pools. These pools facilitate lending and borrowing between users for a set of supported assets. Specifically, the victim pool in this incident allows users to borrow XLM and USDC using USTRY as collateral. Moreover, the pool creator specifies the Reflector oracle [2] as the oracle provider upon creation. The price of USTRY provided by the Reflector oracle updates every five minutes based on the USTRY/USDC market on the Stellar DEX (i.e., SDEX) [3].

Vulnerability Analysis

The root cause was the price manipulation in the illiquid USTRY/USDC market of the SDEX, which led to a vulnerable update of the USTRY price on the Reflector oracle. Specifically, due to extremely shallow liquidity in the USTRY/USDC market, the attacker was able to consume normal orders and place abnormal orders to inflate the USTRY price by 100 times. This inflated USTRY price was then propagated to the Reflector oracle, allowing the attacker to borrow all assets (i.e., XLM and USDC) from the victim pool by collateralizing overvalued USTRY.

Attack Analysis

1. (Tx 1, 2) The attacker manipulated the USTRY price on the SDEX, driving it from $1.06 to approximately $107. As the USTRY/USDC market on the SDEX was extremely shallow, the attacker consumed all normal orders and then placed abnormal orders, sharply pushing the market price higher.
2. (Tx 3) The Reflector oracle pulled the manipulated price from the SDEX and updated its price feed accordingly.
3. (Tx 4, 5) The attacker borrowed 1,000,196e7 USDC by collateralizing 12,881e7 USTRY.
4. (Tx 6, 7) The attacker borrowed 6,124,927,810e7 XLM by collateralizing 14,987,610e7 USTRY.
5. (Txs 8, 9, 10) Lastly, the attacker bridged the drained assets to multiple chains, including Base, BSC, and Ethereum.

The tables below summarize key exploit transactions and the related addresses involved.

Conclusion

Although the YieldBloxDAO incident resulted in significant losses, the underlying issue is not complex: the collateral valuation depends on a price that is vulnerable to manipulation. This incident serves as a reminder that the price dependency for lending protocols must be carefully selected and monitored.

References

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

[2] https://reflector.network/

[3] USTRY/USDC Market on the SDEX

3. STO Incident

Brief Summary

On February 23, 2026, a STO-WBNB pool on PancakeSwap in the BNB Smart Chain was drained, resulting in approximately $16.1K in losses. The root cause was a flawed burn mechanism in the STO token. Specifically, when users sold STO tokens in the pool, the burn mechanism was triggered, burning STO tokens from the pool and inflating the token's price. As a result, the attacker exploited this vulnerability to drain WBNB tokens from the pool.

Background

The STO token introduces a burn mechanism targeting the PancakeSwap V2 pool. This mechanism is triggered only when the STO token’s sell function is enabled (i.e., sellEnabled == true) and pendingBurnFromSell > 0. When a user sells STO tokens, the mechanism burns STO tokens from the pool. Specifically, 94% of the STO tokens sold in the previous transaction are burned during the burning process.

Vulnerability Analysis

The root cause of the incident is the flawed burn mechanism in the STO token. Specifically, when a user sells STO tokens, the burn mechanism removes a certain amount of STO tokens from the pool while also invoking the sync() function of the pair contract to update the reserves. This burn mechanism inflates the price of the STO token in the pool. As a result, attackers could profit from this mechanism by conducting a price manipulation attack.

Attack Analysis

The following analysis is based on the transaction 0x8ba17bea...5a54020c.

1. The attacker borrowed 360,894e18 WBNB via the flash loan.

2. The attacker invoked the function initializeLiquidity() to enable the buying and selling functionality of the STO token.

3. The attacker exchanged 360,894e18 WBNB for 7,848,832e18 STO.

4. The attacker invoked the function transfer(), triggering the burn mechanism to manipulate the pair's reserves (i.e., increased the price of the STO token), while also setting the amount of STO tokens to be burned in the next transaction to 173,391e18.

5. The attacker invoked the function swap() to swap STO for WBNB. This step allowed the attacker to gain profits based on the manipulated price.

6. The attacker repeated steps 4 and 5 to drain the pool's WBNB.

7. The attacker repaid the flash loan and realized a profit of 26e18 WBNB.

Conclusion

The root cause of this incident stems from the flawed burn mechanism of STO, which allows attackers to drain WBNB from the pool. To mitigate such issues, the project must implement proper access controls within the system and conduct comprehensive testing of their burn mechanism to avoid potential price manipulation attacks.

4. HedgePay Incident

Brief Summary

On February 25, 2026, the HedgePay protocol on BNB Smart Chain was exploited, resulting in approximately $15.7K in losses. The root cause was flawed business logic in the staking contract of HedgePay protocol. Specifically, the function forceExit() of the vulnerable staking contract (i.e., 0xBe189fe9f84cA531CD979630E1f14757b88dD80d) allowed users to withdraw their staked assets without updating their staked balances. As a result, the attacker was able to repeatedly invoke the function forceExit() to drain the contract’s HPAY tokens.

Background

The HedgePay protocol is a staking protocol that allows users to earn rewards by staking HPAY tokens. The function forceExit() allows users to withdraw their staked assets.

Vulnerability Analysis

The root cause of the incident is flawed business logic in the function forceExit(). Specifically, when users stake HPAY tokens via the function stake(), their staked amount (i.e., _balances[msg.sender]) is updated accordingly. However, when users withdraw their staked HPAY tokens via the function forceExit(), the contract fails to update _balances[msg.sender]. As a result, the attacker is able to drain HPAY tokens in the staking contract by repeatedly invoking the function forceExit().

Attack Analysis

The following analysis is based on the transaction 0x5f2ea6cb...46ed137f.

1. The attacker borrowed 1,247,859e18 HPAY via the flash loan. In the flashloan callback function:

   a.The attacker staked 1,197,944e18 HPAY via the function stake().

   b.The attacker repeatedly invoked the function forceExit() to drain the contract’s HPAY tokens.

2. The attacker repaid the flash loan and swapped 57,389,615e18 HPAY for 26e18 WBNB (i.e., profited 26e18 WBNB).

Conclusion

The root cause of this incident was that the forceExit() function did not update the user’s _balances[msg.sender], allowing the attacker to drain HPAY tokens in the staking contract. To prevent such issues, the project should conduct proper state-oriented tests to ensure that the state invariants are correctly maintained in each function.

5. Ploutos Incident

Brief Summary

On February 26, 2026, a pool of the Ploutos protocol on Ethereum suffered losses of approximately $390,000 due to an oracle misconfiguration. Specifically, the oracle was incorrectly set to use a BTC/USD Chainlink price feed for USDC. As a result, the attacker exploited this misconfiguration to borrow 187 ETH by collateralizing only 8 USDC.

Vulnerability Analysis

Ploutos is a fork of Aave v3.0.2 deployed across multiple networks. The incident was caused by an incorrect oracle configuration in the lending pool (0xD060...F945D2). In block 24538896, the price oracle for USDC was misconfigured to reference a BTC/USD Chainlink feed instead of a USDC/USD feed. In the subsequent block (24538897), the attacker detected the misconfiguration and executed the exploit. As a result, the attacker borrowed approximately 187.3 ETH as profit by collateralizing approximately 8.88 USDC.

Attack Analysis

1. The attacker monitored the Ploutos protocol's oracle configuration operations, which incorrectly set the oracle source of USDC to Chainlink BTC/USDC Price Feed in Tx 0xcfedf6...bd193ab6.

2. The attacker instantly sent a transaction (0xa17dc37e...705f8474), which allows the attacker to borrow ~187.3 ETH by collateralizing only ~8.8 USDC due to the oracle misconfiguration.

3. The attacker paid ~5.6 ETH in builder bribes and netted ~181.7 ETH in profit.

Conclusion

The root cause of the incident was an oracle misconfiguration, resulting in losses of approximately $390,000. This serves as a reminder that sensitive operations like Oracle configuration should be protected by multisig wallets or timelock to avoid potential losses.

References

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

6. FOOMCASH Incident

Brief Summary

On February 26, 2026, the FOOMCASH protocol was exploited due to a vulnerable Groth16 proof verification [1], resulting in total losses of over $2.26M.

Background

The FOOMCASH protocol is a lottery protocol on Base and Ethereum that uses Groth16 proofs for withdrawal verifications. In the contract FoomLottery, the function collect() verifies the provided proof (i.e., _pA, _pB, and _pC) by invoking the function WithdrawG16Verifier.verifyProof(). Specifically, the verification is performed based on the trusted setup (i.e., gamma and delta) in the contract WithdrawG16Verifier. Once the proof is verified as valid, the function collect() then proceeds to transfer assets (i.e., FOOM tokens) based on the user's inputs (e.g., _recipient and _rewardbits).

Vulnerability Analysis

The root cause of the incident was a vulnerable Groth16 setup. Specifically, in the contract WithdrawG16Verifier, the variables gamma ($\gamma \backslash gamma$) and delta ($\delta \backslash delta$) shared the same value (i.e., $G\mathrm{\_}2G\backslash \_\{2\}$), allowing the attacker to forge valid proofs with arbitrary inputs. As a result, the attacker circumvented the Groth16 proof verification in the contract WithdrawG16Verifier and drained all assets in the contract FoomLottery with malicious inputs.

Attack Analysis

The attack analysis is based on the transaction 0xce204482...4e275e48.

The attacker created a malicious contract to construct a valid proof and malicious inputs. In the malicious contract's fallback logic:

1. It constructed a valid proof.

2. It invoked the function collect()of the contract FoomLottery with a valid proof and malicious inputs (e.g., _recipient and _rewardbits).

   1. In the invocation of the function collect(), the proof verification (i.e., WithdrawG16Verifier.verifyProof()) was circumvented and the assets (i.e., FOOM tokens) were transferred to the attacker.

3. It repeated the steps 1-2 for 30 times and drained a total of 19,695,576,757,802e18 FOOM tokens.

Conclusion

The root cause of the incident was a vulnerable Groth16 verification setup, resulting in losses of approximately $2.26M. This underscores that complex cryptographic setups must be thoroughly reviewed and audited before deployment.

References

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

7. Unknown Incident

Brief Summary

On February 27, 2026, an unknown contract on BNB Smart Chain was exploited [1], resulting in losses of approximately $180K. The root cause of this incident was improper input validation. Specifically, the function _verifySignatures() of the victim contract failed to perform an empty-list check, allowing the attacker to circumvent the signature verification without providing signatures and signers. As a result, the attacker leveraged this vulnerability to drain all USDT tokens in the victim contract.

Vulnerability Analysis

The root cause of this incident is improper validation in the signature verification flow. Specifically, the function _verifySignatures() only checks that allSigners.length == signatures.length and does not require either array to be non-empty. As a result, when both arrays are empty, the attacker can circumvent the signature verification and withdraw assets.

Attack Analysis

The following analysis is based on this transaction 0x91f45260...41cfd784.

1. The attacker invoked the function 0x2d0cb456() of their malicious contracts. In the invocation,

   a. The malicious contract invoked the function poolWithdraw() with empty inputs allSigners and signatures, circumventing the intended signature verification logic.
   b. After bypassing the signature verification logic, the victim contract transferred USDT to the attacker.
   

Conclusion

The root cause of this incident was improper input validation, leading to losses of approximately $180K. The incident underscores the importance of basic boundary checks such as non-empty checks for inputs.

References

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

About BlockSec

BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.

BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.

• Official website: https://blocksec.com/

• Official Twitter account: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Submit a request

• 🔗 Phalcon Security APP: Book a demo

• 🔗 Phalcon Compliance