Our auditors check for second preimage vulnerabilities in every Merkle-related review. The pattern repeats.
The contract accepts a raw 64-byte leaf. An attacker submits two concatenated child nodes as a single leaf. It hashes to the value of the internal node. The proof passes. The data was never authorized.
Libraries process whatever leaf you hand them. The vulnerability is in construction, not verification, and it survives code review more often than it should.
@ahmedaghadi breaks down the full mechanism and the two standard mitigations: https://t.co/k84G0qmiU5
@mdothassan@0xSimao In simple words, the fuzzing test suite will be executing functions in different order with different input arguments and will try to break the invariants.
@0xSlowbug@code4rena Honestly, there's no exact strategy. I think the simplest strategy which I aim for is: Learn, do contest, repeat. Try to push yourself out of the comfort zone. Remember, it's a marathon, not a sprint.