First Flight #1: PasswordStore

Summary

As setPassword is setting new value, multiple transactions from different users performing this action may be reordered on validator side.

This only relates to precondition that owner is contract that can be interacted by multiple persons in a same time (e.g. list of authorized users).

Vulnerability Details

If this contract is expected to be owned by some other contract, and multiple users will be changing the password, e.g. as agents, transactions order is not guaranteed, meaning that e.g. for this case:

ordering may be messed up, possibly causing - depending on MEV, gas price and other details - the contract to have passwordA as final state.

Multiple real-world cases are applicable here, e.g. arent registry-based ACLs, permits with signatures and others

Impact

If owner is expected to be EOA or specifically designed contract, then informational
If owner is expected to be generic contract, then medium

Tools Used

Forge

Recommendations

Use nonce as a second argument to avoid reordering