~$4.72M Lost: TAC, Transit Finance & More | BlockSec Weekly

During the past week (2026/05/11 - 2026/05/17), BlockSec identified multiple attack incidents across several blockchain ecosystems. The table below lists 3 notable incidents with total estimated losses of approximately $4.72M.

Date	Incident	Type	Estimated Loss
2026/05/12	Transit Finance Incident	Arbitrary Call	~$1.88M
2026/05/12	TAC Incident	Improper Validation	~$2.8M
2026/05/13	Boost Hook Incident	Flawed Business Logic	~$46.75K

Three incidents are selected for in-depth analysis:

Transit Finance: a legacy swap bridge contract, reportedly deprecated since 2022, was exploited through arbitrary calldata forwarding to drain users who had never revoked their USDT approvals.
TAC: the largest loss this week (~$2.8M), where missing canonical wallet verification in the TON-side jetton deposit flow allowed fake deposit notifications to trigger cross-chain minting on TAC EVM.
Boost Hook: a Uniswap V4 hook-based perpetual protocol exploited through spot price manipulation, demonstrating the risks of using slot0 prices as entry prices for leveraged positions.

Weekly Highlight: Transit Finance

This incident is highlighted because it demonstrates a persistent risk pattern: deprecated smart contracts with lingering token approvals. Even when a protocol considers a contract obsolete, users who never revoked their approvals remain exposed indefinitely, making legacy infrastructure a latent attack surface.

On May 12, 2026, Transit Finance, a cross-chain swap and bridge aggregation protocol, was exploited on TRON for approximately $1.88M [1]. The attacker abused an arbitrary calldata execution path in a legacy TransitMixSwapBridge contract to invoke USDT.transferFrom() against users who had previously granted unlimited USDT approvals to Transit's approval contract. Although the affected contract had reportedly been deprecated since 2022, the approval relationships remained active and exploitable.

Background

Transit Finance is a cross-chain swap and bridge aggregation protocol that enables users to swap and transfer assets across multiple blockchains, including TRON. The protocol's TRON deployment historically included a TransitMixSwapBridge contract that routed swap and bridge executions through an internal proxy and approval pipeline.

Vulnerability Analysis

The buggy TransitMixSwapBridge contract (TUfPjK...Ukbc4) exposed arbitrary calldata forwarding functionality: attacker-controlled calldata could be propagated through Transit's internal execution chain without sufficient validation. This allowed the attacker to craft payloads that ultimately triggered USDT.transferFrom() calls through Transit's approval contract (TransitApproveGovernanceTron), which still held unlimited allowances granted by users.

The core defect is that the execution path performed no restriction on the target or calldata of the forwarded call, enabling arbitrary external calls to be executed under the approval contract's authority.

Attack Analysis

The following analysis is based on the transaction 3a981b83...ce918ac2.

Step 1: The attacker invoked the TransitMixSwapBridge contract with crafted calldata. The calldata was forwarded through Transit's proxy and bridge execution pipeline to the approval contract.
Step 2: Transit's approval contract (TransitApproveGovernanceTron) executed attacker-controlled USDT.transferFrom() calls. Because users had previously granted unlimited USDT allowances to this approval contract, the calls succeeded.
Step 3: USDT was transferred directly from victim wallets to the attacker-controlled address, totaling approximately $1.88M.

Conclusion

The incident was caused by an arbitrary calldata execution vulnerability in a legacy TransitMixSwapBridge contract combined with persistent unlimited token approvals. Although the contract had reportedly been deprecated since 2022, the approval relationships remained active and exploitable. The key lessons are: (1) deprecated contracts should be fully decommissioned, including revoking any approval authority they hold, (2) arbitrary calldata forwarding paths must validate both the target address and the function selector, and (3) users should regularly audit and revoke unnecessary token approvals, especially for deprecated protocols.

References

[1] BlockSec Phalcon Alert

More Incidents This Week

TAC

On May 12, 2026, TAC, a bridge protocol that extends TON with EVM-compatible execution, was exploited for approximately $2.8M [1]. The root cause was missing canonical wallet verification in the TON-side jetton deposit flow: the TAC JettonProxy accepted a JettonNotify from a non-canonical jetton wallet without verifying that the sender matched the canonical wallet derived by the official jetton master. This allowed the attacker to submit fake deposit notifications that triggered valid cross-chain messages and minted mapped assets on TAC EVM.

Background

TON is not natively EVM-compatible, which limits direct access to Ethereum-style DeFi applications. TAC extends TON by providing a bridge that allows assets and messages originating on TON to be processed on an EVM-compatible environment. In this design, TON-side token deposits are converted into cross-chain messages and minted as mapped assets on TAC EVM.

Vulnerability Analysis

The buggy TAC JettonProxy contract is deployed at EQAChA...xMdw.

The vulnerability is missing canonical wallet verification in the TON-side token ingress path. TAC JettonProxy accepted JettonNotify messages without verifying that msg.sender was the canonical jetton wallet derived by the official jetton master for the claimed owner. Because of this, a non-canonical wallet could send a fake JettonNotify, have it treated as a legitimate deposit, and trigger a valid TVM-to-EVM cross-chain message.

Attack Analysis

The following analysis is based on the transactions 549807fd...3757e1 and 0x0942a5...0dad224d.

Step 1: The attacker deployed a wallet-like contract and used it to send a JettonNotify to TAC JettonProxy. The payload claimed a token transfer and included a forward_payload containing cross-chain execution data.

Step 2: TAC JettonProxy accepted the notify and emitted a downstream cross-chain message to TAC CCL. The sender wallet was not the canonical wallet derived by the official USD₮ (USDT on TON) master for the relevant owner, yet the notify was processed as a valid deposit flow.

Step 3: TAC EVM processed the bridge message and minted mapped assets, including approximately 2.17M mapped USD₮, completing the exploit path.

Conclusion

The incident was caused by missing canonical wallet verification in TAC's TON-side jetton deposit flow. A wallet not derived from the official jetton master successfully submitted a fake JettonNotify, which the bridge treated as a legitimate deposit and converted into a valid cross-chain mint on TAC EVM. A robust fix should ensure that the TON-side bridge verifies the sender address against the canonical wallet derived from the official jetton master for the claimed owner and asset.

References

[1] TAC Build Post-Incident Statement

Boost Hook

On May 13, 2026, Boost, a perpetual protocol built on a Uniswap V4 pool and hook, was exploited on Ethereum for approximately $46.75K. The root cause was spot price manipulation: BoostHook used the V4 pool's slot0 sqrtPriceX96 directly as the entry price when opening leveraged positions, allowing the attacker to inflate the price within a single transaction and force the protocol to buy PERP tokens at the manipulated price using its own ETH reserves.

Background

Boost is a perpetual protocol built on a single Uniswap V4 ETH/PERP pool with a custom hook (BoostHook). PERP is a fixed-supply ERC-20 token (1M total supply), and Boost serves as the pool's sole liquidity provider, seeding all PERP as concentrated-liquidity bands above the initial price.

Leverage is implemented as a market swap against this same pool. When a user calls openLong(), BoostHook supplements the user's collateral by withdrawing additional ETH from its own upper bands as the borrowed amount, then swaps the full position size into PERP. The PERP stays in BoostHook's balance, and the user receives an internal Position record. Closing or liquidation reverses the swap, repays debt, and returns any surplus.

Vulnerability Analysis

The buggy BoostHook contract is deployed at 0x3db1...d7eacc.

The root cause is that BoostHook reads the pool's slot0 sqrtPriceX96, the spot price, directly as the entry price when opening a position. Since slot0 reflects the instantaneous pool state, it is manipulable within a single transaction through large swaps. No check enforces that the entry price is within a manipulation-resistant bound such as a TWAP.

Attack Analysis

The following analysis is based on the transaction 0xb45cc4...cebd3811.

Step 1: The attacker took a WETH flash loan from Morpho Blue and unwrapped it to ETH, providing the upfront capital for the manipulation roundtrip.
Step 2: The attacker swapped a large amount of ETH for PERP via Sat1SwapRouter, pumping the pool's spot price upward. The attacker now held a large PERP position bought at the pre-pump price.

Step 3: The attacker called openLong() with 5x leverage multiple times. Per call, the attacker posted a small collateral (e.g., 2 ETH), and BoostHook borrowed 4x that amount from its own bands, then market-bought PERP with the full position size at the manipulated spot price. Each successive open pushed the spot price even higher, and most of the buying pressure came from the protocol's own ETH.

Step 4: The attacker swapped the PERP acquired in Step 2 back into ETH. Because the spot price had been raised both by the original pump and by the protocol-funded opens in Step 3, the exit price was significantly higher than the entry price. The spread between the cheap buy and expensive sell constituted the profit.

Step 5: Inside the dump's afterSwap callback, _scanAndLiquidate triggered and began liquidating the positions from Step 3 as bad debt against the protocol. This had no effect on the attacker's profit since Step 4's payout had already settled.
Step 6: The attacker wrapped the accumulated ETH back to WETH, repaid the flash loan, and kept the remaining ETH as profit.

Conclusion

The incident was caused by spot price manipulation: BoostHook used the V4 pool's spot price directly as the entry price for leveraged opens, which allowed the attacker to inflate the price within a single transaction and force the protocol to buy PERP at the top with its own ETH reserves. A fix should constrain _swapEthForToken against a manipulation-resistant reference price such as a TWAP, rather than trusting the instantaneous slot0 value.

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