OpenZeppelin Contracts Wizard is a web application to interactively build a contract out of components from OpenZeppelin Contracts. Prior to @openzeppelin/wizard 0.10.11, @openzeppelin/wizard-cairo 3.0.1, @openzeppelin/wizard-stellar 0.6.2, and @openzeppelin/wizard-stylus 0.3.1, the setInfo code path prints info.securityContact and info.license verbatim into single-line comments in generated Solidity, Cairo, Stellar/Soroban, and Stylus source. A line terminator ends the comment and causes following input to be emitted as source declarations. Exploitation requires an integration to populate these fields from untrusted input and a user to consume the generated source; normal self-service web, AI assistant, CLI, and self-hosted API use does not cross that trust boundary, shared links cannot set the fields, and no code executes on a Wizard service. This issue affects generated-source integrity only and is fixed in versions 0.10.11, 3.0.1, 0.6.2, and 0.3.1 of the respective packages.

OpenZeppelin Confidential Contracts is an experimental library for developing applications on the Zama fhEVM. Prior to 0.3.1, the ERC7984 contract tracked confidential total supply with an euint64 value, and an overflowing internal mint operation could fail silently. The wrap and onTransferReceived functions in contracts/token/ERC7984/extensions/ERC7984ERC20Wrapper.sol did not handle that failure, so a user could transfer the underlying token without receiving the corresponding confidential wrapped token. With the default rate(), the wrapper fills after approximately 18.4 trillion tokens, and subsequent wrapping requests can cause loss of funds. This issue is fixed in version 0.3.1.

Impact

The lastIndexOf(bytes,byte,uint256) function of the Bytes.sol library may access uninitialized memory when the following two conditions hold: 1) the provided buffer length is empty (i.e. buffer.length == 0) and position is not 2256 - 1 (i.e. pos != type(uint256).max).

The pos argument could be used to access arbitrary data outside of the buffer bounds. This could lead to the operation running out of gas, or returning an invalid index (outside of the empty buffer). Processing this invalid result for accessing the buffer would cause a revert under normal conditions.

When triggered, the function reads memory at offset buffer + 0x20 + pos. If memory at that location (outside the buffer) matches the search pattern, the function would return an out of bound index instead of the expected type(uint256).max. This creates unexpected behavior where callers receive a valid-looking index pointing outside buffer bounds.

Subsequent memory accesses that don't check bounds and use the returned index must carefully review the potential impact depending on their setup. Code relying on this function returning type(uint256).max for empty buffers or using the returned index without bounds checking could exhibit undefined behavior.

Patches

Upgrade to 5.4.0

Cairo-Contracts are OpenZeppelin Contracts written in Cairo for Starknet, a decentralized ZK Rollup. This vulnerability can lead to unauthorized ownership transfer, contrary to the original owner's intention of leaving the contract without an owner. It introduces a security risk where an unintended party (pending owner) can gain control of the contract after the original owner has renounced ownership. This could also be used by a malicious owner to simulate leaving a contract without an owner, to later regain ownership by previously having proposed himself as a pending owner. This issue has been addressed in release version 0.16.0. All users are advised to upgrade. There are no known workarounds for this vulnerability.

Impact

The Base64.encode function encodes a bytes input by iterating over it in chunks of 3 bytes. When this input is not a multiple of 3, the last iteration may read parts of the memory that are beyond the input buffer.

Although the encode function pads the output for these cases, up to 4 bits of data are kept between the encoding and padding, corrupting the output if these bits were dirty (i.e. memory after the input is not 0). These conditions are more frequent in the following scenarios:

- A bytes memory struct is allocated just after the input and the first bytes of it are non-zero. - The memory pointer is set to a non-empty memory location before allocating the input.

Developers should evaluate whether the extra bits can be maliciously manipulated by an attacker.

Patches

Upgrade to 5.0.2 or 4.9.6.

References

This issue was reported by the Independent Security Researcher Riley Holterhus through Immunefi (@rileyholterhus on X)

Context Merge conflict resolution issue when porting the v5.0.1 Multicall update to the v4.9 branch caused a duplicated line.

Impact Versions using Multicall from @openzeppelin/contracts@4.9.4 and @openzeppelin/contracts-upgradeable@4.9.4 will execute each subcall twice. Concretely, this exposes a user to unintentionally duplicate operations like asset transfers.

Patches The duplicated delegatecall was removed in 4.9.5. The 4.9.4 version is marked as deprecated.

Impact

OpenZeppelin Contracts is a library for secure smart contract development. Starting in version 4.0.0 and prior to version 4.9.3, contracts using ERC2771Context along with a custom trusted forwarder may see msgSender return address(0) in calls that originate from the forwarder with calldata shorter than 20 bytes. This combination of circumstances does not appear to be common, in particular it is not the case for MinimalForwarder from OpenZeppelin Contracts, or any deployed forwarder the team is aware of, given that the signer address is appended to all calls that originate from these forwarders.

Patches

The problem has been patched in v4.9.3.

Impact

When the verifyMultiProof, verifyMultiProofCalldata, processMultiProof, or processMultiProofCalldata functions are in use, it is possible to construct merkle trees that allow forging a valid multiproof for an arbitrary set of leaves.

A contract may be vulnerable if it uses multiproofs for verification and the merkle tree that is processed includes a node with value 0 at depth 1 (just under the root). This could happen inadvertently for balanced trees with 3 leaves or less, if the leaves are not hashed. This could happen deliberately if a malicious tree builder includes such a node in the tree.

A contract is not vulnerable if it uses single-leaf proving (verify, verifyCalldata, processProof, or processProofCalldata), or if it uses multiproofs with a known tree that has hashed leaves. Standard merkle trees produced or validated with the @openzeppelin/merkle-tree library are safe.

Patches

The problem has been patched in 4.9.2.

Workarounds

If you are using multiproofs: When constructing merkle trees hash the leaves and do not insert empty nodes in your trees. Using the @openzeppelin/merkle-tree package eliminates this issue. Do not accept user-provided merkle roots without reconstructing at least the first level of the tree. Verify the merkle tree structure by reconstructing it from the leaves.

Impact

By frontrunning the creation of a proposal, an attacker can become the proposer and gain the ability to cancel it. The attacker can do this repeatedly to try to prevent a proposal from being proposed at all.

This impacts the Governor contract in v4.9.0 only, and the GovernorCompatibilityBravo contract since v4.3.0.

Patches

The problem has been patched in 4.9.1 by introducing opt-in frontrunning protection.

Workarounds

Submit the proposal creation transaction to an endpoint with frontrunning protection.

Credit

Reported by Lior Abadi and Joaquin Pereyra from Coinspect.

References

https://www.coinspect.com/openzeppelin-governor-dos/

Impact

A function in the implementation contract may be inaccessible if its selector clashes with one of the proxy's own selectors. Specifically, if the clashing function has a different signature with incompatible ABI encoding, the proxy could revert while attempting to decode the arguments from calldata.

The probability of an accidental clash is negligible, but one could be caused deliberately.

Patches

The issue has been fixed in v4.8.3.

Workarounds

If a function appears to be inaccessible for this reason, it may be possible to craft the calldata such that ABI decoding does not fail at the proxy and the function is properly proxied through.

References

https://github.com/OpenZeppelin/openzeppelin-contracts/pull/4154

OpenZeppelin Contracts is a library for secure smart contract development. 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. This issue has been patched in 4.8.3. As a workaround, ensure that all proposals that pass through governance have equal length signatures and calldatas parameters.

OpenZeppelin Contracts is a library for secure smart contract development. 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. The issue has been patched in 4.8.2.

Cause isvalidethsignature is missing a call to finalizekeccak after calling verifyethsignature.

Impact As a result, any contract using isvalidethsignature from the account library (such as the EthAccount preset) is vulnerable to a malicious sequencer. Specifically, the malicious sequencer would be able to bypass signature validation to impersonate an instance of these accounts.

Risk In order to exploit this vulnerability, it is required to control a sequencer or prover since they're the ones executing the hints, being able to inject incorrect keccak results.

Today StarkWare is the only party running both a prover or a sequencer, greatly reducing the risk of exploit.

Patches The issue has been patched in 0.6.1.

For more information If you have any questions or comments about this advisory: Open an issue in the Contracts for Cairo repository Email us at security@openzeppelin.com

OpenZeppelin Contracts is a library for secure smart contract development. Before version 4.4.1 but after 3.2.0, initializer functions that are invoked separate from contract creation (the most prominent example being minimal proxies) may be reentered if they make an untrusted non-view external call. Once an initializer has finished running it can never be re-executed. However, an exception put in place to support multiple inheritance made reentrancy possible in the scenario described above, breaking the expectation that there is a single execution. Note that upgradeable proxies are commonly initialized together with contract creation, where reentrancy is not feasible, so the impact of this issue is believed to be minor. This issue has been patched, please upgrade to version 4.4.1. As a workaround, avoid untrusted external calls during initialization.

OpenZeppelin Contracts is a library for secure smart contract development. The functions ECDSA.recover and ECDSA.tryRecover are vulnerable to a kind of signature malleability due to accepting EIP-2098 compact signatures in addition to the traditional 65 byte signature format. This is only an issue for the functions that take a single bytes argument, and not the functions that take r, v, s or r, vs as separate arguments. The potentially affected contracts are those 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 take a signature that has already been submitted, submit it again in a different form, and bypass this protection. The issue has been patched in 4.7.3.

Impact

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.

Patches

The issue has been fixed in v4.7.2.

References

https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3587

For more information

If you have any questions or comments about this advisory, or need assistance deploying a fix, email us at security@openzeppelin.com.

OpenZeppelin Contracts is a library for secure smart contract development. Contracts using the cross chain utilities for Arbitrum L2, CrossChainEnabledArbitrumL2 or LibArbitrumL2, will classify direct interactions of externally owned accounts (EOAs) as cross chain calls, even though they are not started on L1. This issue has been patched in v4.7.2. Users are advised to upgrade. There are no known workarounds for this issue.

OpenZeppelin Contracts is a library for secure smart contract development. This issue concerns instances of Governor that use the module GovernorVotesQuorumFraction, a mechanism that determines quorum requirements as a percentage of the voting token's total supply. In affected instances, when a proposal is passed to lower the quorum requirements, past proposals may become executable if they had been defeated only due to lack of quorum, and the number of votes it received meets the new quorum requirement. Analysis of instances on chain found only one proposal that met this condition, and we are actively monitoring for new occurrences of this particular issue. This issue has been patched in v4.7.2. Users are advised to upgrade. Users unable to upgrade should consider avoiding lowering quorum requirements if a past proposal was defeated for lack of quorum.

OpenZeppelin Contracts is a library for smart contract development. Versions 4.0.0 until 4.7.1 are vulnerable to ERC165Checker reverting instead of returning false. ERC165Checker.supportsInterface is designed to always successfully return a boolean, and under no circumstance revert. However, an incorrect assumption about Solidity 0.8's abi.decode allows some cases to revert, given a target contract that doesn't implement EIP-165 as expected, specifically if it 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. The issue was patched in version 4.7.1.

OpenZeppelin Contracts is a library for smart contract development. Versions 4.1.0 until 4.7.1 are vulnerable to the SignatureChecker reverting. SignatureChecker.isValidSignatureNow is not expected to revert. However, an incorrect assumption about Solidity 0.8's abi.decode allows some cases to revert, given a target contract that doesn't implement EIP-1271 as expected. The contracts that may be affected are those that use SignatureChecker to check the validity of a signature and handle invalid signatures in a way other than reverting. The issue was patched in version 4.7.1.

Impact This vulnerability affects all accounts (vanilla and ethereum flavors) in the v0.2.0 release of OpenZeppelin Contracts for Cairo, which are not whitelisted on StarkNet mainnet, so only goerli deployments of v0.2.0 accounts are affected.

This faulty behavior is not observed in StarkNet's testing framework, so don't rely on it passing to detect this issue on custom accounts.

Patches This bug has been patched in v0.2.1.

References The issue is detailed in https://github.com/OpenZeppelin/cairo-contracts/issues/386.

For more information If you have any questions or comments about this advisory: Open an issue in the Contracts for Cairo repo Email us at security@openzeppelin.com

In OpenZeppelin <=v4.4.0, initializer functions that are invoked separate from contract creation (the most prominent example being minimal proxies) may be reentered if they make an untrusted non-view external call. Once an initializer has finished running it can never be re-executed. However, an exception put in place to support multiple inheritance made reentrancy possible, breaking the expectation that there is a single execution.

OpenZeppelin Contracts is a library for smart contract development. In affected versions upgradeable contracts using UUPSUpgradeable may be vulnerable to an attack affecting uninitialized implementation contracts. A fix is included in version 4.3.2 of @openzeppelin/contracts and @openzeppelin/contracts-upgradeable. For users unable to upgrade; initialize implementation contracts using UUPSUpgradeable by invoking the initializer function (usually called initialize). An example is provided in the forum.

OpenZepplin is a library for smart contract development. In affected versions a vulnerability in TimelockController allowed an actor with the executor role to escalate privileges. Further details about the vulnerability will be disclosed at a later date. As a workaround revoke the executor role from accounts not strictly under the team's control. We recommend revoking all executors that are not also proposers. When applying this mitigation, ensure there is at least one proposer and executor remaining.

OpenZepplin is a library for smart contract development. In affected versions a vulnerability in TimelockController allowed an actor with the executor role to escalate privileges. Further details about the vulnerability will be disclosed at a later date. As a workaround revoke the executor role from accounts not strictly under the team's control. We recommend revoking all executors that are not also proposers. When applying this mitigation, ensure there is at least one proposer and executor remaining.