Lei Wu

Co-founder of BlockSec (@BlockSecTeam) | Views are my own

[BlockSec Phalcon @Phalcon_xyz]

🗓 Weekly Web3 Security Roundup | Jun 15 - Jun 21

🚨 Spotlight on 3 notable incidents | ~$18.3M lost this week

Featuring a vulnerability breakdown and in-depth analysis of selected key cases👇
https://t.co/p76YlrASyi

[BlockSec Phalcon @Phalcon_xyz]

🗓 Weekly Web3 Security Roundup | Jun 8 - Jun 14

🚨 Spotlight on 4 notable incidents | ~$5.98M lost this week

Featuring a vulnerability breakdown and in-depth analysis of selected key cases👇
https://t.co/t7yjQU0xhs

[BlockSec Phalcon @Phalcon_xyz]

Correct: after diving into the details, our analysis shows that the actual root cause of the @aztecnetwork incident was a mismatch between the verified rollup transaction set and the L1 settlement processing boundary (i.e., numRealTxs / _numTxs).

In Aztec Connect’s RollupProcessorV3.processRollup(), numRealTxs was not effectively bound to the transaction set enforced by the ZK proof, allowing the proof verification path and the L1 settlement logic to interpret the transaction list differently. The proof covered all transactions decoded from encodedInnerTxData and inserted their notes into the rollup Merkle tree, while the L1 settlement logic handled only the first numRealTxs decoded slots.

Because this assumption was not enforced, an attacker could place a non-actionable transaction in the scanned slot(s) and move a real deposit into a later decoded slot. In the observed exploit pattern, the attacker set numRealTxs to 1 while placing a real deposit transaction in the second decoded transaction slot. As a result, the rollup credited value internally while skipping the corresponding L1 signature validation and pending deposit balance deduction. More specifically, the second-slot deposit bypassed decreasePendingDepositBalance() and therefore did not consume the corresponding pending deposit balance. This created unbacked private balances that could later be withdrawn through normal settlement flows.

In the attack transaction, the attacker first credited seven unbacked asset balances across different assets into the rollup state and then extracted those assets through seven subsequent withdrawals. As shown in the figure, we use the first DAI deposit/withdraw pair as an example.

An especially notable detail is the timeline. According to Aztec’s official sunset notice, the Aztec Connect rollup would continue processing transactions and withdrawals only until March 31, 2024, after which the sequencer would stop running [1]. However, the linked materials indicate that RollupProcessorV3 was still upgraded on April 10, 2024 via PR #67 [2], and that upgrade appears not to have gone through an external audit before deployment [3].

[1] https://t.co/3jK9FbY5Si
[2] https://t.co/Qhc72LcThg
[3] https://t.co/6Kl9pVmBlR

[BlockSec Phalcon @Phalcon_xyz]

🗓️ Weekly Web3 Security Roundup | Jun 1 - Jun 7

🚨 This week’s focus: @Zcash Orchard Counterfeiting Vulnerability
No confirmed exploitation, but the underlying ZK soundness bug triggered an emergency upgrade and major market impact.

Breaking down the critical ZK soundness bug behind the counterfeiting risk 👇
https://t.co/obmW6BO6gK

[BlockSec Phalcon @Phalcon_xyz]

Alert! Token $TOP was attacked, resulting in a loss of around $1.59M. The attacker acquired more than 50% of TOP voting power, due to the token’s low market value, and used it to pass and execute a governance proposal that minted a large amount of TOP to themselves. The newly minted TOP was then swapped for WETH via the Balancer pool, draining the existing LP liquidity.

Projects using similar Lido/Aragon governance implementations should carefully review their voting power distribution, quorum/pass thresholds, mint permissions, and related governance safeguards.

Attack Tx: https://t.co/itXv0NCwGO

[BlockSec Phalcon @Phalcon_xyz]

Asterix @asterixlabs was reportedly attacked a few hours ago, with a loss of ~$40K. The root cause appears similar to yesterday’s Flooring incident, which had a total impact of $900K+, with ~$500K rescued by white hats.

Asterix appears to be forked from Flooring, and DN404/BT404 appear to share essentially the same 404-style ERC20/ERC721 hybrid contract design under different names/variants.

The shared root cause appears to be a high-bit NFT ID shift/overflow issue, leading to ID reuse and broken ownership/approval/accounting breakdowns (underflow).

Specifically, full uint256 NFT IDs enter external functions, while ownership/accounting is stored in packed lower-width slots. Crafted IDs with different high bits but colliding low bits can desync ownership, approvals, balances, and NFT backing. The attacker can then abuse exchange/transfer/unwrap flows to inflate the fungible token balance, sell into liquidity pools to drain WETH, and potentially extract additional value from backed NFTs.

[BlockSec Phalcon @Phalcon_xyz]

🗓 Weekly Web3 Security Roundup | May 25 - May 31

🚨 Spotlight on 5 notable incidents | ~$16M lost this week

Featuring a vulnerability breakdown and in-depth analysis of selected key cases👇
https://t.co/MtsuhQ8nkX

[BlockSec Phalcon @Phalcon_xyz]

🗓 Weekly Web3 Security Roundup | May 18 - May 24

🚨 Spotlight on 5 notable incidents | ~$104.6M lost this week

Featuring a vulnerability breakdown and in-depth analysis of selected key cases👇
https://t.co/BpujfpnZaa

[BlockSec Phalcon @Phalcon_xyz]

An unknown contract named 'SquidRouterModule' was reportedly exploited on #Ethereum due to improper input validation, resulting in ~$3M in losses. @squidrouter has clarified that this incident is unrelated to Squid’s core protocol/contracts.

The root cause appears to be misuse of the Axelar Bridge, similar to the previous @crosscurvefi attack pattern (https://t.co/dIoTEpFQJL). The attacker (0xe1d5...3265) forged malicious calldata and abused approval permissions granted via PermissionManager (0x03B8...4cB7) to force token approvals from victims to Uniswap.

Using these malicious approvals, the attacker swapped victims’ assets for fake tokens (0xe6Ff...3512) through Uniswap pools and profited.

[BlockSec Phalcon @Phalcon_xyz]

🗓 Weekly Web3 Security Roundup | May 11 - May 17

🚨 Spotlight on 3 notable incidents | ~$4.72M lost this week

Full analysis with vulnerability breakdown 👇
https://t.co/7Ttn4Bfn8D

#Web3Security

[BlockSec Phalcon @Phalcon_xyz]

The root cause of the @VerusCoin incident appears to be improper validation of economic backing in the import submission flow [1].

Specifically, the Verus-Ethereum Bridge contract verifies that:
1) the export/notarization proof is valid, and;
2) keccak256(serializedTransfers) matches the export's hashtransfers commitment (i.e., hashReserveTransfers[1][2]).

However, it does NOT sufficiently validate that the source-chain export actually carries enough locked/burned value to support the corresponding payouts on Ethereum.

As a result, the attacker was able to submit a Verus export [3] with essentially no meaningful economic backing, but with a matching serializedTransfers hash, and the bridge still released ~$11.7M in ETH / tBTC / USDC [4].

At a high level, the vulnerable flow is:
1) proveImports(...)
-> validates the proof and checks that hash(serializedTransfers) matches the committed transfer hash;
2) processTransactions(...)
-> proceeds to execute the payouts on Ethereum

What is missing is a robust check that the source-chain export's actual economic backing is sufficient to support the imported transfers before assets are released.

Please note: the deployed code is not open-sourced. Our investigation is based on the attack transactions and code currently available in the official repository, which may not reflect the full deployed implementation or the complete attack surface.

References:
[1] https://t.co/M7MDDTWXOM
[2] https://t.co/ip7atKIje1
[3] https://t.co/TmW5jOAG1G
[4] https://t.co/h6oNYeFWk5

[BlockSec Phalcon @Phalcon_xyz]

🗓 Weekly Web3 Security Roundup | Apr 20 - Apr 26

🚨Spotlight on 8 critical incidents | ~$7.04M lost this week

Full analysis with vulnerability breakdown 👇
https://t.co/uPxLbqGccq

#Web3Security

[DeepSeek @deepseek_ai]

🚀 DeepSeek-V4 Preview is officially live & open-sourced! Welcome to the era of cost-effective 1M context length.

🔹 DeepSeek-V4-Pro: 1.6T total / 49B active params. Performance rivaling the world's top closed-source models.
🔹 DeepSeek-V4-Flash: 284B total / 13B active params. Your fast, efficient, and economical choice.

Try it now at https://t.co/GCdiMzk1Dl via Expert Mode / Instant Mode. API is updated & available today!

📄 Tech Report: https://t.co/drlDrxkYtp
🤗 Open Weights: https://t.co/T13Y8i7SDM

1/n

[Lei Wu @realvisual]

DeepSeek-V4 just dropped, turning million-token context into a routinely deployable engineering capability. Another possible highlight: kernel performance was validated on Huawei Ascend NPUs.

https://t.co/suFm2qSRUc

[Lei Wu @realvisual]

Code audits matter. But infrastructure security deserves equal attention.

🧵 "...we believe the attack was the result of a private key compromise...This was not a smart contract vulnerability or a protocol-level exploit; the Sui blockchain and its infrastructure performed as intended throughout."

[Volo @volo_sui]

📋 Community Status Report - Volo Protocol

We want to provide our community with a full and honest account of where things stand following yesterday's security incident.

We owe you clarity, and we are committed to providing it every step of the way.

1. Cause of the Hack

Our investigation is ongoing, and we do not want to speculate on details before we have a complete picture.

What we can share at this stage: we believe the attack was the result of a private key compromise.

Despite our best efforts and security practices in place, the attacker was able to exploit this vector to access the affected Vaults.

This was not a smart contract vulnerability or a protocol-level exploit; the Sui blockchain and its infrastructure performed as intended throughout.

A full technical post-mortem will be published once the investigation is concluded. We are working with security partners to ensure this cannot happen again.

2. Fund Recovery - $2M Successfully Frozen

Of the ~$3.5M in assets taken, we have successfully frozen approximately $2M in close coordination with the Sui Foundation and ecosystem partners. This was the result of a rapid, round-the-clock effort from our team and the broader ecosystem.

We are continuing to work through the details of the recovery and return process with our partners during EST business hours on Wednesday. A further update will follow as soon as those discussions are concluded.

3. Making Users Whole - We Are Fully Prepared

For the remaining ~$1.5M, we are fully prepared to make every affected user whole. No user will be left out of pocket.

We know that a promise alone is not enough - we will be communicating every step of the process transparently before funds are returned, so you know exactly what is happening and when.

Details on the reimbursement process will be shared shortly.

We are deeply sorry this happened. The Volo Team is working without pause to resolve it and to rebuild the trust you have placed in us.

Thank you for your patience and continued support.

[BlockSec @BlockSecTeam]

https://t.co/Lx4aRAUbQQ

[BlockSec Phalcon @Phalcon_xyz]

.@arbitrum Security Council took emergency action to freeze 30,766 ETH held at the Arbitrum One address linked to the @KelpDAO exploit.

The key technical point is how this was executed: it was not a normal transfer signed by the exploiter's key.

Based on the on-chain trace, this appears to have been executed from Ethereum (L1) via governance-level emergency upgrade powers. The Upgrade Executor temporarily upgraded DelayedInbox, invoked a temporary entrypoint to enqueue a delayed L1→L2 message via Bridge.enqueueDelayedMessage(kind=3, ...), and then restored the original implementation.

The critical logic change was that the sender input shifted from the standard msg.sender path to a caller-controlled parameter (then transformed via L1→L2 aliasing), allowing the injected message to carry exploiter-linked sender context. Also, kind=3 maps in Nitro to L1MessageType_L2Message, which allows L2MessageKind_UnsignedUserTx execution on L2, i.e., this path does not require a user signature check.

So the L2 transaction view (“from exploiter to 0x…0DA0”) reflects a chain-level forced state transition, not a standard user-signed transfer.

TX on L1: https://t.co/Jlp5NbjWTV

TX on L2: https://t.co/FAzUkpGdQK

[BlockSec Phalcon @Phalcon_xyz]

.@KelpDAO was reported attacked hours ago, with total losses estimated around $290M. Based on community on-chain analysis (e.g., @banteg), the likely root cause is a compromise of the configured DVN/verifier on the Unichain→Ethereum rsETH bridge route: the route relied on a 1-of-1 check, which may have let a forged/unbacked bridge message pass verification and trigger a drain from the protocol's rsETH Adapter.

The exploiter then deposited rsETH into Aave/Compound/Euler and borrowed roughly $236M in assets (WETH, wstETH, WBTC), which is the attacker’s tracked profit so far. @aave has frozen rsETH markets (V3/V4).

The incident is still under investigation. The main risk now is contagion: thin rsETH liquidity could turn collateral exposure into bad debt.

[BlockSec Phalcon @Phalcon_xyz]

ALERT! Our system detected a suspicious exploit targeting an unknown contract, reportedly the LML/USDT staking protocol, on #BSC hours ago, resulting in an estimated loss of ~$950K.

While the victim contract is not open-source, our analysis suggests a likely pricing-design flaw: claimable rewards appear to have been calculated using a TWAP/snapshot-based price, while the attacker was able to sell the rewarded tokens at a manipulated spot price. This inconsistency may have enabled the attacker to extract profit through price manipulation and reverse swaps.

Specifically, the attacker first used swaps, including a path with receiver = address(0), to push up the LML price in the pool. They then invoked claim through attacker-controlled addresses that had deposited earlier, making them eligible to claim directly during the attack.

Example deposit TX: https://t.co/FlkcCdZNjR

Attack TX: https://t.co/KmMJOZQgV6

🟦 Found by #PhalconSecurity, 🟦 Analyzed via #PhalconExplorer.

[Yajin (Andy) Zhou @yajinzhou]

https://t.co/tSLj6YO8tj