Frangio

**Name of the Vulnerable Software and Affected Versions** OpenZeppelin Contracts versions prior to 4.8.3 **Description** The proposal creation entrypoint (`propose`) in `GovernorCompatibilityBravo` allows the creation of proposals with a `signatures` array shorter than the `calldatas` array. This causes the additional elements of the latter to be ignored, and if the proposal succeeds the corresponding actions would eventually execute without any calldata. The `ProposalCreated` event correctly represents what will eventually execute, but the proposal parameters as queried through `getActions` appear to respect the original intended calldata. **Recommendations** For versions prior to 4.8.3, update to version 4.8.3 to resolve the issue. As a temporary workaround, ensure that all proposals that pass through governance have equal length `signatures` and `calldatas` parameters.

**Name of the Vulnerable Software and Affected Versions** OpenZeppelin Contracts versions prior to 4.8.2 **Description** The ERC721Consecutive contract, designed for minting NFTs in batches, does not update balances when a batch has size 1 and consists of a single token. Subsequent transfers from the receiver of that token may overflow the balance as reported by `balanceOf`. The issue exclusively presents with batches of size 1. **Recommendations** For versions prior to 4.8.2, update to version 4.8.2 to resolve the issue. As a temporary workaround, consider restricting the use of the ERC721Consecutive contract for batches of size 1 until the update is applied.

**Name of the Vulnerable Software and Affected Versions** OpenZeppelin Contracts versions prior to 4.7.3 **Description** The functions `ECDSA.recover` and `ECDSA.tryRecover` are vulnerable to signature malleability due to accepting EIP-2098 compact signatures in addition to the traditional 65 byte signature format. This issue affects contracts that implement signature reuse or replay protection by marking the signature itself as used, rather than the signed message or a nonce included in it. A user may submit a previously used signature in a different form, bypassing this protection. **Recommendations** For versions prior to 4.7.3, update to version 4.7.3 to resolve the issue. As a temporary workaround, consider modifying the contracts to implement signature reuse or replay protection by marking the signed message or a nonce included in it as used, rather than the signature itself. Restrict access to the `ECDSA.recover` and `ECDSA.tryRecover` functions to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** OpenZeppelin Contracts versions prior to 4.7.2 **Description** The target contract of an EIP-165 `supportsInterface` query can cause unbounded gas consumption by returning a lot of data, while it is generally assumed that this operation has a bounded cost. **Recommendations** For versions prior to 4.7.2, upgrade to version 4.7.2 to resolve the issue. As a temporary workaround, consider restricting the amount of data returned by the target contract of an EIP-165 `supportsInterface` query to prevent unbounded gas consumption.

**Name of the Vulnerable Software and Affected Versions** OpenZeppelin Contracts versions 4.1.0 through 4.7.1 **Description** The issue concerns the SignatureChecker reverting in certain cases, which is not expected. This occurs due to an incorrect assumption about Solidity 0.8's `abi.decode`, specifically when a target contract does not implement EIP-1271 as expected. The contracts that may be affected are those using `SignatureChecker` to check signature validity and handle invalid signatures in a way other than reverting. **Recommendations** For versions 4.1.0 through 4.7.1, update to version 4.7.1 to resolve the issue. As a temporary workaround, consider modifying the handling of invalid signatures in contracts that use `SignatureChecker` to prevent reverting. Restrict the use of `SignatureChecker.isValidSignatureNow` until the update is applied.

**Name of the Vulnerable Software and Affected Versions** OpenZeppelin Contracts versions 4.0.0 through 4.7.1 **Description** The issue concerns the ERC165Checker in OpenZeppelin Contracts, which may revert instead of returning `false` under certain conditions. Specifically, this occurs when a target contract does not implement EIP-165 as expected and returns a value other than 0 or 1. The contracts that may be affected are those that use `ERC165Checker` to check for support for an interface and then handle the lack of support in a way other than reverting. **Recommendations** For versions 4.0.0 through 4.7.1, update to version 4.7.1 to resolve the issue. As a temporary workaround, consider modifying the contract to handle the lack of support in a way that does not rely on the return value of `ERC165Checker.supportsInterface`. Restrict access to the `ERC165Checker` function to minimize the risk of exploitation until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** @openzeppelin/contracts versions prior to 4.3.2 @openzeppelin/contracts-upgradeable versions prior to 4.3.2 **Description** The issue affects upgradeable contracts using `UUPSUpgradeable` in OpenZeppelin Contracts, a library for smart contract development. These contracts may be vulnerable to an attack affecting uninitialized implementation contracts. **Recommendations** For versions prior to 4.3.2, update to version 4.3.2 of `@openzeppelin/contracts` and `@openzeppelin/contracts-upgradeable`. As a temporary workaround for users unable to upgrade, initialize implementation contracts using `UUPSUpgradeable` by invoking the initializer function, usually called `initialize`.