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.

Date	Incident	Type	Estimated Loss
2026/02/10	Unknown Incident	Flawed Business Logic	~$10K
2026/02/14	`OCA` Incident	Flawed Business Logic	~$422K
2026/02/14	`SOF` Incident	Flawed Business Logic	~$225K

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 retrieves additional AFX tokens from address 0x146933. The amount of AFX pulled from 0x146933 is set to match the amount previously withdrawn from 0x671ce4. Next, the function calculates the required amount of AHT based on the current price ratio in the PancakeSwap V2 AFX–AHT liquidity pool. It then supplies the AFX obtained from 0x146933, along with the corresponding amount of AHT (also sourced from 0x146933), 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 for ~$225K due to incorrect whitelist mechanism in its _update() logic and fee exemption system. The vulnerability allowed an attacker to bypass buy restrictions using a fee-exempt address, subsequently triggering a burn-on-sell mechanism that manipulated the Uniswap V2 (PancakeSwap) pool reserves. By pushing forcing the pool to transfer its own tokens to a burn address and immediately calling sync(), the attacker artificially inflated the token price. This enabled the drain of USDT from the pool by swapping a small amount of SOF at the manipulated rate. The exploit was further facilitated by an inadequate flashloan guard that failed to track tx.origin, allowing the buy and sell phases of the attack to occur within the same transaction using multiple addresses.

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 stems from the flawed whitelist mechanism in the _update() function of the 0x1f3863 contract at line 438. If the address to is whitelisted, any from can process a buy operation.

 /// SOF.sol:433-480
433|      function _update(
434|          address from,
435|          address to,
436|          uint256 amount
437|      ) internal override {
438|          if (isExcludedFromFees[to] || isExcludedFromFees[from]) {
439|              super._update(from, to, amount);
440|              return;
441|          }
442|  
443|          require(!_blackList[from] && !_blackList[to], "refuse address");
444|  
445|          if (!inSwap && _isPairs[to]) {
446|              if (feeAmount1 >= swapTokensAtAmount) {
447|                  swapTokenForUsdt(feeAmount1, feeAddress);
448|                  feeAmount1 = 0;
449|              }
450|              if (feeAmount2 >= swapTokensAtAmount) {
451|                  swapTokenForUsdt(feeAmount2, feeAddress2);
452|                  feeAmount2 = 0;
453|              }
454|          }
455|  
456|          bool isSell;
457|          uint256 taxAmount;
458|  
459|          if (_isPairs[from]) {
460|              //buy
461|              revert("not alw buy");
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|          }
470|  
471|          emit TranserFeeLog(amount, taxAmount);
472|  
473|          if (isSell) {
474|              _antiFlashloanGuard(from, to, false, isSell);
475|          }
476|  
477|          amount = amount - taxAmount;
478|  
479|          super._update(from, to, amount);
480|      }

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 allows the attacker can burn almost all of the SOF token in the pool in the Step 3. 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).
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 vulnerability demonstrates that for tokens supporting a burn-before-sell mechanism, controlling who can buy the token is critical. Anyone capable of selling the token can profit; if an attacker can buy tokens from the pool, they can artificially inflate the price and then swap back to drain whole pool.

The investigation noted that the _antiFlashloanGuard() function is improperly implemented. It only restricts the same msg.sender from buying and selling, rather than tracking the tx.origin. This allows an attacker to bypass the guard by selecting a fee-exempted address as the to (receiver) address during the buy operation.

To prevent similar exploits, developers must ensure that only authorized roles can buy from the pool. Furthermore, the _antiFlashloanGuard() implementation should record both the tx.origin and the user address to prevent attackers from using multiple addresses to execute buy and sell operations within the same 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