Project

Summary: Transaction reordering vulnerability arises in Membership Factory contract where multiple functions depend on shared or interdependent state but lack appropriate safeguards against changes made by other transactions, especially in highly concurrent environments.

Vulnerability Details:

In the provided MembershipFactory contract, the baseURI state variable is shared by the setBaseURI and createNewDAOMembership functions:

• setBaseURI allows the admin to update baseURI, which is a URI that points to metadata resources for the ERC1155 membership tokens.

• createNewDAOMembership uses baseURI as part of the initialization of a new TransparentUpgradeableProxy for a DAO membership NFT, so this function depends on the baseURI to be in its intended state at the time of creation.

If setBaseURI and createNewDAOMembership are called simultaneously (or in quick succession), there's a chance that:

1. Race Condition: The baseURI could change during the execution of createNewDAOMembership, depending on how Ethereum transactions are ordered and mined. For instance:

   • A transaction calling createNewDAOMembership might read an old baseURI in one execution step.

   • Before createNewDAOMembership completes, setBaseURI might be executed in a separate transaction, updating baseURI.

   • This results in the new DAO membership proxy being created with an outdated or unintended baseURI.

2. Impact of Reordering: If the transactions are reordered (e.g., setBaseURI executes before or after createNewDAOMembership in a different sequence than expected by the caller), then the newly created DAO membership could be initialized with a different baseURI than intended.

Tools Used: Manual review

Recommendations:

Lock Mechanism: Introduce a reentrancy guard (like OpenZeppelin’s ReentrancyGuard) or a specific lock mechanism to prevent setBaseURI from being executed concurrently with createNewDAOMembership.