HACK ANALYSIS 4 min read

SuperRare Hack Analysis


SuperRare Hack Analysis

Overview:

On July 28, 2025, SuperRare’s (@SuperRare) RareStakingV1 contract was exploited for approximately $730,000 USD (~11.9M RARE tokens). The vulnerability stemmed from a broken access control check in the updateMerkleRoot() function, allowing any unauthorized users to submit malicious Merkle roots. This enabled an attacker to calculate a malicious Merkle root, submit it via a frontrunner transaction, and fraudulently claim the tokens. This vulnerability falls under OWASP SC01: Access Control Vulnerabilities.

The stolen funds, valued at ~$730,000, remain in the attacker’s contract and have not yet been swapped yet. Notably, the $RARE token itself was unaffected, with the exploit limited to the staking contract’s reward pool.

Smart Contract Hack Overview:

Fig: Attack Transaction

Decoding the Smart Contract Vulnerability:

  • The root cause of the vulnerability in the SuperRare RareStakingV1 contract lies in a critical logic flaw in access control within the updateMerkleRoot function.
  • The updateMerkleRoot function was designed to allow the contract owner or a predefined authorized address to update the currentClaimRoot — a critical state variable that defines the Merkle root used for verifying token claims in the staking system. This update is intended to facilitate legitimate changes to the Merkle tree structure while ensuring that only trusted parties can modify it and thereby protecting the integrity of the staking rewards pool.
  • However, the wrong implementation of this function led to a significant loss of funds!
Fig: Vulnerable updateMerkleRoot() Function
  • The function, intended to restrict Merkle root updates to the contract owner or a specific authorized address, contained a misconfigured require statement:

require((msg.sender != owner() || msg.sender != address(0xc2F394a45e994bc81EfF678bDE9172e10f7c8ddc)), "Not authorized to update merkle root");

  • This logic uses != (not equal) with an || (OR) operator, which incorrectly allows any address to pass the check. Specifically, the condition evaluates to true for any msg.sender that is not the owner or not the authorized address—conditions that are always met by any address, since an address cannot simultaneously be both the owner and the authorized address.
  • This effectively removes all access control, enabling unauthorized users to update the Merkle root. This logic is inverted and flawed!
  • The attacker abused this logic flaw by calculating a malicious Merkle root, such as0x93f3c, and utilized claim() function to withdraw approximately ~11.9M $RARE Tokens worth ~$730,000 USD.

Attack Sequence:

Fig: Attack Sequence Visualized

Detection by SolidityScan:

  • SolidityScan was able to detect the exact vulnerable line in SuperRare’s RareStakingV1 (Ethereum) contract that led to a ~$730K USD exploit .
  • Scanning the contract early on with SolidityScan would have flagged this critical vulnerability. This single scan could have saved SuperRare over 730K USD!
Fig: Solidityscan was able to catch the vulnerability!
  • Try it yourself at: https://solidityscan.com ! Sign up and scan the Victim Contract (RareStakingV1) on Ethereum (Mainnet). A detailed vulnerability report will be ready in just few seconds!
Fig: Simple steps to scan any contract on SolidityScan!
  • Don’t wait for a hack postmortem to learn from — catch critical bugs before they go live.
  • Integrate SolidityScan into your development CI/CD pipeline and secure every deploy!

Mitigation and Best Practices:

  • Ensure that only authorized parties (e.g., the contract owner or a predefined trusted address) can update the currentClaimRoot by implementing a strict require check.
  • Use a robust access control mechanism, such as OpenZeppelin’s AccessControl, to manage permissions for sensitive functions like updateMerkleRoot.
  • Avoid relying solely on msg.sender for access control; incorporate multi-factor validation or role-based checks to prevent unintended access.
  • 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.
Fig: SolidityScan — Smart Contract Vulnerability Scanner

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