Extropy Security Bytes: w14 2025

7 min readApr 6, 2025

Welcome to this week’s Extropy Security Bytes, where we break down the latest blockchain security incidents and vulnerabilities. This week, a zkLend hacker ironically falls victim to a phishing scam, Uniswap V4 hooks introduce new security considerations for developers, and SIR Trading suffers a complete TVL drain. Let’s dive into the details.

No April fools — zkLend hacker falls victim to phishing scam on 1st April

This event followed the initial exploit of the decentralised lending protocol zkLend on the Starknet network, which occurred around February 12, 2025, and resulted in the theft of approximately $9.5 million.

Background of the zkLend Exploit:

The initial exploit of zkLend was due to a rounding error, allowing the attacker to mint free tokens by manipulating the lending accumulator using flash loans.
Following the hack, zkLend offered the attacker a 10% bounty for the return of the remaining 90% of the funds (3,300 ETH).
The stolen funds were initially bridged to Ethereum, and an attempt was made to launder them via Railgun. However, due to protocol policies, the funds were returned to the original address by Railgun.

The Phishing Incident:

The hacker then attempted to launder a portion of these recovered funds, specifically 2,930 ETH (worth around $5.4 million), through the crypto mixer Tornado Cash.
However, instead of using the legitimate platform, the hacker mistakenly interacted with a malicious phishing site: tornadoeth.cash
As a result, another party successfully drained the 2,930 ETH from the hacker.
Blockchain analytics firm Lookonchain corroborated the loss of 2,930 ETH due to the phishing incident.
The hacker even sent an on-chain message admitting to the blunder, expressing devastation and regret for the havoc and losses caused, and stating that they no longer had the coins. The hacker urged zkLend to pursue the phishing site operators.

Reactions and Further Developments:

This unexpected turn of events led to speculation within the crypto community, with some suggesting a possible connection between the original hacker and the phishing scammers, although no concrete evidence has surfaced.
ZkLend stated that the phishing website appeared to have been active for over five years and that there was no solid evidence linking the phishing operators to the original hacker, but they added the associated wallet addresses to their tracking efforts.

Uniswap v4 hooks — security considerations for developers

Uniswap V4 represents a significant evolution in the decentralised finance (DeFi) space, introducing several new features that offer increased flexibility and customisation for liquidity pools. However, this enhanced functionality also brings forth new security considerations that developers must be aware of.

Key New Features of Uniswap V4:

Customisable Hooks: This is a major highlight of V4, allowing developers to attach custom logic (hooks) that execute before and after key pool operations such as initialising a pool, modifying liquidity, swapping, and donating liquidity. For example, a `beforeSwap` hook can implement logic that checks if a specific token can be swapped.
Singleton Design: Unlike Uniswap V3, where each pool was a separate contract, V4 houses all pools within a single contract called the PoolManager.
Flash Accounting: Transactions in V4 track balance changes in transient storage, only settling at the end of the transaction. This optimises gas usage.
Dynamic Fees: Swap fees in V4 can be adjusted dynamically, offering more flexibility to pool creators.
Native ETH Support: Uniswap V4 supports native Ether (ETH), eliminating the need for wrapping to WETH in certain scenarios.

Security Considerations for Developers Building with Uniswap V4 Hooks:

The introduction of hooks provides powerful customisation but also increases the attack surface. Developers need to be particularly mindful of the following security considerations when building custom hooks:

Reentrancy Risks: Hooks execute before and after critical pool operations, making them potential targets for reentrancy attacks. If a hook calls an external contract before a transaction is complete, an attacker could potentially manipulate balances and drain liquidity. It is crucial to implement proper reentrancy guards and follow secure coding practices to mitigate this risk.
Denial-of-Service (DoS) Attacks: Malicious hooks could be designed to cause transactions to revert or consume excessive gas, leading to DoS attacks on the pool. Thorough validation of hook logic and potential gas costs is necessary.
Malicious Hooks: Since anyone can potentially deploy a hook, and a pool can be initialised with any hook, there’s a risk of a pool being created with a malicious hook that could harm users or steal funds. Careful consideration of pool initialisation parameters and potential access control mechanisms might be needed, although the sources indicate that anyone can currently initialise a pool and set a hook.
State Inconsistencies: Custom hook logic could potentially lead to inconsistencies in the pool’s state if not implemented correctly. Rigorous testing and formal verification techniques can help identify such issues.
Permission Mismatches: When building hooks, developers should inherit from BaseHook to avoid potential permission mismatches. .•Return Value Validation: Hooks should validate return values to prevent unexpected transaction failures.
Access Control in Hooks: It’s important to restrict access to certain functionalities within hooks to prevent unauthorised calls.
Auditing Upgradeable Contracts: If hooks or related contracts are upgradeable, they should be audited thoroughly to mitigate risks associated with centralised control over upgrades.
Input Parameter Validation: Hooks must validate input parameters to prevent malicious manipulation of pool operations.
Careful Modification of hookDelta: Developers need to be extremely cautious when modifying the hookDelta to avoid potential theft of funds.
Proper Pool Management: As a hook can interact with multiple pools, developers must implement proper pool management within their hooks and avoid making assumptions about the state of other pools.

General Recommendations:

Beyond the specific risks associated with hooks, general secure development practices remain crucial for any smart contract development on Uniswap V4 or other platforms.

Implement secure coding practices from the outset.
Conduct thorough audits by reputable security firms. Multiple audits and cross-auditing are recommended.
Perform proactive monitoring of deployed contracts.
Ensure swift action in response to identified vulnerabilities.
Utilise static analysis tools to identify potential bugs. Examples include SmartCheck and Slither.
Implement comprehensive testing, including unit tests, fuzz testing, and integration tests.
Stay informed about the latest threats and best practices in DeFi security.

Uniswap V4’s new features, particularly hooks, offer significant potential for innovation in DeFi. However, developers should approach their implementation with a strong focus on security, being acutely aware of the new attack vectors and adhering to robust security practices to protect users and their funds.

SIR Trading total TVL of $355,000 drained

Date of Attack: The SIR Trading exploit was detected on March 30, 2025.

Assets Lost: The attacker successfully drained the entire Total Value Locked (TVL) of $355,000 from the SIR Trading protocol.

Vulnerability Exploited: The primary vulnerability exploited was a transient storage collision within the protocol’s uniswapV3SwapCallback function. Specifically, slot 1 of the transient storage was used for two distinct purposes: storing the address of the Uniswap pool and the amount of the token being minted.

Attack Mechanism:

The attacker crafted a vanity address.
They calculated the precise mint amount required to bypass security checks within the vulnerable uniswapV3SwapCallback function.
The attack targeted the Vault contract’s callback function, which was intended to act as a security guard by verifying that the transient storage slot 0x1 matched the caller’s address.
However, due to the dual use of transient storage slot 1, the attacker was able to substitute the authorised Uniswap pool address with an address under their control during the callback process.
This allowed the attacker to repeatedly call the hacked callback function, effectively tricking the system into sending the funds held in the vault to their own address.
The attacker systematically drained the entire $355,000 TVL by exploiting this vulnerability.

Smart Contracts Involved:

Attacker’s Address: 0x27defcfa6498f957918f407ed8a58eba2884768c

Vulnerable Contract Address (Vault): 0xb91ae2c8365fd45030aba84a4666c4db074e53e7

Attack Transaction: 0xa05f047ddfdad9126624c4496b5d4a59f961ee7c091e7b4e38cee86f1335736f

Security Firms Involved:

Ten ArmorAlert and Decurity were the blockchain security companies that first detected the hack and issued warnings.

SlowMist is also credited with providing information about the attack.

Egis Security had previously conducted a single audit of SIR Trading in February and identified some high-severity issues.

Post-Attack Actions:

SIR Trading acknowledged the hack and advised users not to deposit further funds.
The stolen funds were traced to an address funded by the Ethereum privacy solution Railgun.
SIR Trading’s founder, Xatarrer, attempted to contact Railgun for assistance in recovering the lost assets.
Negotiations were attempted with the attacker, offering a $100,000 bounty (approximately 28% of the stolen TVL) for the return of the remaining funds, with a promise of no legal action.

That’s a wrap for this week’s Extropy Security Bytes. From ironic twists in hacking incidents to evolving DeFi security risks, the space continues to be a battleground for both attackers and defenders. Stay sharp, stay secure, and we’ll catch you next week for more blockchain security insights.

About Extropy

Since 2017, Extropy has been at the forefront of blockchain security, auditing smart contracts across Ethereum and Zero-Knowledge (ZK) protocols. We have collaborated with leading ecosystems, including Base, Starknet, and MINA, ensuring their smart contracts are resilient, efficient, and secure.

We specialize in DeFi, on-chain games, and ZK applications, leveraging formal verification, static analysis, and deep manual reviews to uncover vulnerabilities before they become exploits. Whether you’re working with Solidity, Rust, Cairo, or zkVMs, our collaborative approach ensures your project meets the highest security standards.

- Website: https://security.extropy.io

- Email: info@extropy.io

Get in touch today — let’s build safer smart contracts together!