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

During the past week (Feb 9–Feb 15, 2026), BlockSec detected and analyzed three attack incidents, with total estimated losses of ~$657K. The table below summarizes these incidents, and detailed analyses for each case are provided in the following subsections.

1. Unknown Incident

Brief Summary

On February 10, 2026, contract 0x560d39 on BNB Smart Chain was exploited, resulting in an estimated loss of ~$10K. The root cause was flawed business logic in function 0xb1a87f2c(), which made its liquidity addition process vulnerable to a sandwich attack.

Background

In contract 0x560d39, function 0xb1a87f2c() transfers a corresponding amount of USDT from the user based on the input parameter. The received USDT is processed, and 85% of the total is allocated for subsequent liquidity operations.

From this 85% portion, half is swapped for AFX through a PancakeSwap pool, and the acquired AFX is transferred to contract 0x671ce4. The function then withdraws AFX from 0x671ce4.

Next, via the PancakeSwap V2 Router, the remaining half of the 85% USDT and the AFX withdrawn from 0x671ce4 are used to add liquidity to the USDT-AFX trading pair. Any leftover USDT or AFX is refunded to the user.

After completing the USDT-AFX liquidity addition, the function pulls additional AFX from address 0x146933. The amount pulled from 0x146933 is set equal to the amount of AFX previously withdrawn from 0x671ce4. The function then calculates the required amount of AHT based on the current price ratio in the PancakeSwap V2 AFX-AHT pool, and uses the AFX pulled from 0x146933 together with the calculated AHT to add liquidity to the AFX-AHT trading pair.

Vulnerability Analysis

The vulnerable contract is 0x560d39. Contract 0x146933 serves as the funding source for the AFX used in the AFX-AHT liquidity addition and ultimately bears the loss.

The root cause lies in the flawed business logic of function 0xb1a87f2c() in 0x560d39. When retrieving the AFX obtained from swapping USDT via contract 0x671ce4, the function does not verify the balance change of AFX in 0x671ce4 before and after the swap. Instead, it withdraws all AFX held by 0x671ce4.

This allows an attacker to donate a large amount of AFX to 0x671ce4 in advance and then invoke 0xb1a87f2c() with only a small amount of USDT. Because the amount of AFX pulled from 0x146933 is defined to match the AFX withdrawn from 0x671ce4, inflating the withdrawal from 0x671ce4 directly forces 0x146933 to contribute an inflated amount of AFX into the AFX-AHT liquidity addition.

The attacker can recover their donation through refunds of remaining USDT and AFX from 0x560d39, while 0x146933 absorbs the cost of the oversized liquidity provision.

The attacker then profits by sandwiching the AFX-AHT liquidity addition, front-running with an AFX to AHT swap and back-running with an AHT to AFX swap around the victim transaction.

Attack Analysis

The key steps of the attack transaction are summarized as follows:

• Step 1: The attacker flash-loaned 1,130,500e18 AFX tokens on PancakeSwap V2.

• Step 2: The attacker transferred 511,965e18 AFX to contract 0x671ce4.

  

• Step 3: The attacker used the remaining AFX to swap for 52,316e18 AHT in the AFX-AHT pool on PancakeSwap V2. Since AHT is a fee-on-transfer token, the attacker ultimately received only 26,158e18 AHT.

  

• Step 4: The attacker called contract 0x560d39, invoking the function 0xb1a87f2c() with the parameter set to 100. Because the function withdrew all AFX from 0x671ce4 (including the attacker's donated tokens), it attempted to add a disproportionately large amount of liquidity to both the USDT-AFX and AFX-AHT pairs. Any remaining USDT and AFX that could not be paired were refunded to the attacker, allowing them to recover most of their cost.

• Step 5: The attacker swapped 26,158e18 AHT for 1,129,417e18 AFX.

  

• Step 6: The attacker repaid the flash loan and swapped the remaining AFX for USDT, earning ~$10K in profit.

Conclusion

This incident was caused by contract 0x560d39 directly withdrawing all AFX from contract 0x671ce4 when retrieving the AFX obtained through swapping USDT, without verifying the change in AFX balance of contract 0x671ce4 before and after the swap.

2. OCA Incident

Brief Summary

On February 14, 2026, an unknown protocol on the BNB Smart Chain suffered an exploit, resulting in a loss of ~$422K. The root cause was flawed business logic: after a swap completes, the protocol calls a recycle function in the OCA Token contract to retrieve tokens from the DEX and return them to the caller and other designated addresses. This single-sided withdrawal of OCA Token artificially reduces the pool's OCA reserves, inflating its on-chain price and allowing an attacker to repeatedly drain USDC from the pool.

Background

The protocol contract (0xe0d5ec) exposes a sellOCA() function (selector 0x9c1dad28) that sells a user-specified amount of OCA for USDC on a DEX. OCA includes a deflationary "recycle" mechanism: after the swap, the contract pulls back the same amount of OCA that was just sold into the pool and redistributes it to the caller and other designated addresses. Since the OCA is removed from the pool after the USDC has already been paid out, the pool's OCA reserves decrease while its USDC reserves remain lower, which artificially pushes up the on-chain OCA price.

Vulnerability Analysis

The core vulnerability is that the post-swap clawback in sellOCA() creates a repeatable price-manipulation primitive. Each invocation has the following net effect on the DEX pool: the pool loses USDC during the swap and also loses OCA when the deflationary mechanism reclaims tokens from the pool, while the caller receives the USDC proceeds and recovers OCA through the redistribution. Because the pool's OCA reserves are reduced without any corresponding USDC inflow to balance the trade, each cycle artificially inflates the OCA/USDC price on the DEX. An attacker can repeat this process by buying OCA, calling sellOCA() to trigger the clawback, and then selling the recovered OCA at the inflated price, progressively draining USDC liquidity from the pool.

Attack Analysis

The key steps of the attack transaction are summarized as follows:

• Step 1: Flash-loaned 8,704,860e18 USDC.

• Step 2: Swapped 8,704,860e18 USDC for 940,991e18 OCA on PancakeSwap.

  

• Step 3: Called sellOCA() with all 940,991e18 OCA. The function swapped the OCA for USDC on the DEX, then the deflationary recycle mechanism clawed back the sold OCA from the pool and redistributed it — returning OCA to the caller. As a result, the attacker received USDC proceeds from the swap while also recovering their OCA tokens. The pool's OCA reserves dropped sharply, inflating the OCA price.

  

• Step 4: Swapped the recovered 940,991e18 OCA back to USDC on PancakeSwap at the now-inflated price, and repeated steps 2–4 to progressively drain the pool.

• Step 5: In the final iteration, the attacker swapped just 9,999e18 OCA for 433,238e18 USDC (reflecting the massively inflated OCA price), then repaid the flash loan to complete the exploit.

  

Conclusion

The fundamental cause of this exploit was a logic flaw in the protocol's sellOCA flow: after swapping user-supplied OCA for USDC, the contract reclaimed essentially all of the OCA input from the DEX via OCA's deflationary ``recovery'' mechanism and redistributed it to the caller and other designated addresses. This post-swap clawback artificially reduced the OCA balance remaining in the liquidity pool, causing the on-chain price of OCA to spike sharply. By repeatedly cycling "buy OCA → invoke sellOCA to trigger the clawback → sell OCA back at the inflated price," the attacker was able to extract nearly all USDC liquidity with relatively little OCA.

3. SOF Incident

Brief Summary

On February 14, 2026, the SOF token on the BNB Smart Chain was exploited, resulting in a loss of ~$225K. The root cause was flawed business logic in the _update() function: during a sell operation, the contract transferred tokens directly from the Uniswap V2 pair to a burn address and immediately called sync(). This manipulation of pool reserves artificially inflated the token price within the same transaction. The attacker constructed a swap transaction that triggered this faulty sell logic, forcing the liquidity pair to burn its own tokens and update reserves, thereby draining the pool's USDT at an artificially inflated price.

Background

SOF is a BEP-20 token deployed on the BNB Smart Chain, designed with custom deflationary mechanics and automated fee management. The token interacts with a Uniswap V2-compatible liquidity pair (specifically PancakeSwap with USDT) to facilitate trading.

For fee-exempted users, buy and sell operations are free of charge. For all other users, buy operations are restricted and will revert.

During sell operations, the contract transfers 90% of the sell amount from the pair to a _destroyAddress directly and calls sync() to update the reserves to reflect the reduced balance immediately.

Vulnerability Analysis

The root cause is flawed business logic in the _update() function of the 0x1f3863 contract. During a sell operation (when to is the Uniswap Pair), the contract executes line 467:

 ///  SOF.sol:462-469
462|          } else if (_isPairs[to]) {
463|              //sell
464|
465|              isSell = true;
466|              taxAmount = takeFee(from, amount);
467|              super._update(_uniswapV2Pair, _destroyAddress, amount - taxAmount);
468|              IUniswapV2Pair(_uniswapV2Pair).sync();
469|          }

This logic transfers tokens directly from the Uniswap Pair address to the burn address (_destroyAddress), draining the liquidity pool's token reserves. The subsequent call to IUniswapV2Pair(_uniswapV2Pair).sync() immediately updates the reserves, causing the token price to spike and allowing the attacker to drain the pool's USDT.

Attack Analysis

The key steps of the attack transaction are summarized as follows:

• Step 1: The attacker flash-loaned 315,520,309e18 USDT for step 2, and transferred 875e18 SOF to address 0xc4DB5B for step 3.

• Step 2: Swapped 313,567,718e18 USDT for 991,223e18 SOF via swapTokensForExactTokens(). The to address was a fee-exempted address, which satisfies the isExcludedFromFees[to] check in the SOF contract, thereby skipping the _isPairs[from] check (otherwise the buy operation would revert). This also bypasses the _antiFlashloanGuard() check — the contract does not record this buy operation, allowing step 3 to proceed without being blocked. Critically, this massive buy was engineered to leave the pair with only 787e18 SOF (alongside 313,816,344e18 USDT), setting up step 3: the 90% burn in the sell logic would destroy nearly the entire remaining SOF balance of the pair.

• Step 3: From address 0xc4DB5B, swapped 875e18 SOF for USDT via swapExactTokensForTokensSupportingFeeOnTransferTokens(). The PancakeSwap Router V2 executes SOF.transferFrom() first, then processes the swap. During SOF.transferFrom(), the sell logic in _update() transfers 90% of 875e18 (i.e., 787e18) from the pair to _destroyAddress — which, as engineered in step 2, was almost the entire SOF balance of the pair. After this burn and sync(), the pair held 313,816,344e18 USDT and only 10e9 SOF. With the SOF price now astronomically inflated, the subsequent swap yielded a massive USDT payout.

• Step 4: The attacker repaid the flash loan and retained the profit of ~$225K.

Conclusion

The SOF incident highlights the risk of manipulating AMM pool reserves inside token transfer logic. The sell path removed tokens from the Uniswap pair balance and immediately called sync(), so when swapExactTokensForTokensSupportingFeeOnTransferTokens() ran, the transfer to the pair changed reserves before the swap completed, distorting pricing and enabling extraction.

The _antiFlashloanGuard() also failed to provide meaningful protection. It only restricts buy and sell for the same user address, and the attacker bypassed it by routing the buy leg to a fee-exempt recipient.

To mitigate similar issues, avoid any transfer hooks or _update() logic that moves tokens from a pair address or calls sync(). If an anti-flashloan guard is needed, enforce a transaction-wide rule by tracking tx.origin along with relevant addresses so attackers cannot split buy and sell across different recipients in one transaction.

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