Synthetics Implemented Right (SIR) Hack Analysis

Synthetics Implemented Right (SIR) Hack Analysis

Overview:

On March 30, 2025, SIR- (@leveragesir), a synthetic asset protocol, was exploited, resulting in a loss of approximately $355,000. The root cause was an improper use of transient storage (EIP-1153) in the uniswapV3SwapCallback() function within the Vault contract.

The attack exploited the fact that the contract used transient storage to store the Uniswap V3 pool address at slot 0x1, but later overwrote this slot with a user-controlled amount. This allowed the attacker to manipulate storage, bypass authentication checks, and execute unauthorized minting of synthetic assets. This vulnerability falls under OWAPS SC03: Logic Errors.

Smart Contract Hack Overview:

• Attack Transaction: 0xa05f0
• Attacker’s Address: 0x27dEf
• Victim’s Address: 0xb91ae
• OWASP SC Top 10: SC03 Logic Errors

Decoding the Smart Contract Vulnerability:

• The root cause of the exploit was in how the Uniswap V3 swap callback function (uniswapV3SwapCallback) verifies the sender using transient storage.

• The contract used transient storage (tload/tstore) to store and verify the Uniswap V3 pool address, assuming the stored value would remain correct. However, the function overwrote transient storage in the same transaction, allowing the attacker to poison the storage with a controlled value.

• The function starts by retrieving the expected Uniswap pool address from transient storage slot 0x1:

assembly {
    uniswapPool := tload(1)  
}

• The contract assumes that tload(1) contains the correct Uniswap V3 pool address (set in a previous transaction). However, transient storage does not persist across transactions and can be manipulated within the same execution flow. This makes it unsafe for authentication.
• Then, the contract checks if the caller (msg.sender) matches the stored Uniswap pool address. If the transient storage was not tampered with, only legitimate Uniswap V3 pools could pass this check. Next, the function decodes the calldata to retrieve details of the swap:

(address user, address asset, uint256 amount) = abi.decode(data, (address, address, uint256));

• Since the caller verification check is flawed, the attacker can manipulate transient storage to make the contract mint assets without proper authorization.
• Before execution completes, the function overwrites transient storage (tstore(1, amount)):

assembly {
    tstore(1, amount)
};

• This action replaces the Uniswap pool address with a user-controlled amount.
• So, next time uniswapV3SwapCallback() is called, tload(1) will return amount, which could be any arbitrary address; in this case it was controlled by the attacker. Thus, the attacker successfully drained $355,000 worth of assets.
• Here, the missing step was clearing the transient variable after authentication. If the contract had reset tstore(1) to 0 after checking msg.sender, the attack would not have been possible.
• The attacker funneled the stolen funds through multiple swaps, including ParaSwap and Odos Router V2. Ultimately, the stolen WETH was moved into Railgun (RAILGUN Project), a privacy-focused mixing protocol, making further tracking difficult.

• SIR Team has acknowledged the hack and have issued security advisories. They are also in process of investigating and trying to recover the stolen funds, if possible. Read more: https://x.com/leveragesir/status/1906265780057972854

Mitigation and Best Practices:

• Avoid Using Transient Storage for Authentication. Transient storage (tstore, tload) should only be used for temporary, non-critical data, such as reentrancy locks. Use state variables for authentication instead of transient storage.
• Also, before setting any new value, ensure that transient storage is reset.
• Implement signature-based authentication or off-chain message signing to validate that the caller is legitimate. This ensures that only authorized entities can trigger the callback, mitigating transient storage-based attacks.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord