HackenProof

Security is a public good — and now the community can help fund it. We’re proud that HackenProof is part of the Ethereum Security QF Round by @thedaofund, hosted on @Giveth — a 500 ETH matching pool supporting people and projects working to make Ethereum and its L2 ecosystem safer. Quadratic funding means it’s not only about how much is donated, but also how many people support a project. So even a $1 donation can help strengthen the signal behind HackenProof. By supporting HackenProof, you support bug bounty research, whitehat hackers, and continuous security work across Ethereum and L2s. Donate by May 14: qf.giveth.io/project/open-s… Repost to help more people support Ethereum security. #HackenProof #EthereumSecurity #BugBounty #QuadraticFunding #Web3Security

Do you specialize in one vuln class or hunt everything?

@LoganOpSec At some point the tab has to close and the hunt has to start 😄

@HackenProof Studying is useful, but at some point you have to turn the writeup into a checklist and go break something. Reading how people found criticals ≠ building the instincts to find one yourself.

@sswarring1313 Hello. We’ll look into this as soon as possible.

@HackenProof I deposited 11.15 USDC on Base network 24+ hours ago for a paid submission and still haven't received my coupon code. Transaction is confirmed on-chain. Support ticket-9080 has been open with zero response. This is unacceptable — please resolve immediately.

@Web3__Youth Not quite - look closer at updateRoot and the transfer recipient

@HackenProof two potential issues here, one with the balance check and another with the vesting period not being properly validated during the reward claiming process

Spot the Bug 🧠 Merkle reward claiming Two bugs in this one. Can you find both?👇

@AtreyRachit The comments are your hints 👀

@HackenProof I'm in, what are the hints for the bugs?

@0xCanvie Fair point on the hints, but finding them yourself hits different

@HackenProof 1. We should transfer to account not msg.sender. 2. anyone can update root without access control. However, I think the biggest bug is that the bugs have already been marked in the diagram above.

@rajafaaiz127 2300 gas limit point is underrated - good catch

@HackenProof Bug 1: only 2300 gas is forwarded when ee use transfer so if the caller contract requires more than 2300 gas, the transfer will revert, so funds will be stuck. Bug 2: Anyone can call updateRoot, invalidating leaf and will cause DOS

@0xOligarch_ Exactly

@HackenProof 3 bugs actually -> The leaf is not double hashed it should be `byte32 leaf = keccak256(bytes.concat(keccak256(abi.encodePacked(proof, root, leaf))));` to prevent a pre image attack. -> should use `token.safeTransfar()` instead. -> no access control on the `updateRoot()` function.

@u_feature Correct on both 👌

@HackenProof Bug 2 is that transfer happens to the msg.sender instead of the account. The same sender can get proofs from valid trie and send as many as not claimed yet to get themselves the token. And the first one is as everyone said no access control/crypto verification to updateRoot.

@BABS96711 Both bugs spotted 👌

@HackenProof 1. Send the "amount" to "msg.sender" instead of "account". 2. Missing access control in upstateRoot function, anyone can call it and replace with malicious Root. That's all I can see.

@Pauljindu19 Correct. Came prepared 😄

@HackenProof CRITICAL: updateRoot has no access control function updateRoot(bytes32 newRoot) external { // ← anyone can call this root = newRoot; } Recommendation; Inherit from Ownable and add onlyOwner, or remove the function entirely if the root is supposed to be immutable.

@Testimony_kid Close - but hash confusion isn't the main issue here

@HackenProof bytes32 hash confusion second bug

@Demelew_W Both spotted. Well done 👀

@HackenProof Bug 1- Anyone can steal others fund by just giving a valid account and amount the fund will be transferred to msg.sender not account Bug 2 the market root can be updated by anyone making the markelproof useless

@SyedGhufranHas1 Correct

@HackenProof There is no access control and the token transferred to msg sender instead of account address

@shubhamtwtt @ziko29504803 Not quite - oracle won't help here 😄

@HackenProof @ziko29504803 Less randomness and access control in the updateroot some modifier will fox this one and using oracle for randomness will fix leaf calculation randomness

@nooz0x Сlean explanation 👌

Looks like a fun one 😄 First bug: updateRoot() is completely unrestricted — anyone can change the Merkle root and basically rewrite who’s eligible to claim. Second bug: the contract sends tokens to msg.sender instead of the account that was proven in the Merkle tree. So even if you prove someone else’s allocation, you can redirect the funds to yourself. Nice combo 🔥

@raykov_krasimir Correct

@HackenProof missing authorization on root update you can drain the claim of any account that hasn’t claimed yet

@0xSmartContract Nothing missed 💪

1️⃣ updateRoot() is public Anyone can change the Merkle root and upload a fake claim list. 2️⃣ Tokens go to msg.sender, not account An attacker can use someone else’s proof and receive the tokens themselves. 3️⃣ claimed[account] = true burns the real user’s claim The attacker steals the tokens and the legitimate user can no longer claim. 4️⃣ transfer() return value is not checked A failed transfer may still mark the user as claimed. 5️⃣ No SafeERC20 Non-standard ERC20 tokens can break the claim flow. 6️⃣ No round/epoch-based claim tracking Updating the root can break future distributions. 7️⃣ No events Claims and root updates are harder to monitor. 8️⃣ No zero-address checks in the constructor _token should not be address(0), and _root should not be bytes32(0).

@ziko29504803 That's one of them 👀

@HackenProof Access control