Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
19 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 5.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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)
Recommended action: Upgrade to 5.0.2 or 4.9.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 4.9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/
Recommended action: Upgrade to 4.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches This issue has been patched in v4.8.3. Workarounds Ensure that all proposals that pass through governance have equal length signatures and calldatas parameters.
Recommended action: Upgrade to 4.8.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 4.8.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches The issue has been patched in 4.8.2. <!-- References --
Recommended action: Upgrade to 4.8.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches The issue has been patched in 4.7.3. 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.
Recommended action: Upgrade to 4.7.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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 requirement, 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. Patches This issue has been patched in v4.7.2. Workarounds Avoid lowering quorum requirements if a past proposal was defeated for lack of quorum. References https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3561 For more information If you have any questions or comments about this advisory, or need assistance deploying the fix, email us at security@openzeppelin.com.
Recommended action: Upgrade to 4.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Contracts using the cross chain utilies 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 is assessed as low severity because any action taken by an EOA on the contract could also be taken by the EOA through the bridge if the issue was not present. Patches This issue has been patched in v4.7.2. References https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3578 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.
Recommended action: Upgrade to 4.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. We believe this to be unlikely. Patches The issue was patched in 4.7.1. References https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3552 For more information If you have any questions or comments about this advisory, or need assistance deploying the fix, email us at security@openzeppelin.com.
Recommended action: Upgrade to 4.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches The issue was patched in 4.7.1. References https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3552 For more information If you have any questions or comments about this advisory, or need assistance deploying the fix, email us at security@openzeppelin.com.
Recommended action: Upgrade to 4.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches A fix is included in the version v4.4.1 of `@openzeppelin/contracts` and `@openzeppelin/contracts-upgradeable`. Workarounds Avoid untrusted external calls during initialization. References https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3006 Credits This issue was identified and reported by @chaitinblockchain through our bug…
Recommended action: Upgrade to 4.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The GovernorCompatibilityBravo module may lead to the creation of governance proposals that execute function calls with incorrect arguments due to bad ABI encoding. This happens if the proposal is created using explicit function signatures, e.g. a proposal to invoke the function foo(uint256) is created as propose([target], [0], ["foo(uint256)"], ["0x00..01"]). If the function selector is provided as part of the encoded proposal data the issue is not present, e.g. the same proposal is created as propose([target], [0], ["0x2fbebd3800..01"]), where 2fbebd38 is the function selector. We've assessed the instances of this contract found on chain, and did not find any occurrence of this bug in the past. Proposal creation through Tally or OpenZeppelin Defender is not affected. The core Governor contract on its own is not affected. Patches A fix is included in version v4.4.2 of @openzeppelin/contracts and @openzeppelin/contracts-upgradeable. Workarounds Do not create proposals using…
Recommended action: Upgrade to 4.4.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When ERC1155 tokens are minted, a callback is invoked on the receiver of those tokens, as required by the spec. When including the ERC1155Supply extension, total supply is not updated until after the callback, thus during the callback the reported total supply is lower than the real number of tokens in circulation. Impact If a system relies on accurately reported supply, an attacker may be able to mint tokens and invoke that system after receiving the token balance but before the supply is updated. Patches A fix is included in version 4.3.3 of @openzeppelin/contracts and @openzeppelin/contracts-upgradeable. Workarounds If accurate supply is relevant, do not mint tokens to untrusted receivers. Credits The issue was identified and reported by @ChainSecurityAudits. For more information Read TotalSupply Inconsistency in ERC1155 NFT Tokens by @ChainSecurityAudits for a more detailed breakdown. If you have any questions or comments about this advisory, email us at security@openzeppelin.com.
Recommended action: Upgrade to 4.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Upgradeable contracts using UUPSUpgradeable may be vulnerable to an attack affecting uninitialized implementation contracts. We will update this advisory with more information soon. Patches A fix is included in version 4.3.2 of @openzeppelin/contracts and @openzeppelin/contracts-upgradeable. Workarounds Initialize implementation contracts using UUPSUpgradeable by invoking the initializer function (usually called initialize). An example is provided in the forum. References Post-mortem. For more information If you have any questions or comments about this advisory, or need assistance executing the mitigation, email us at security@openzeppelin.com.
Recommended action: Upgrade to 4.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerability in TimelockController allowed an actor with the executor role to take immediate control of the timelock, by resetting the delay to 0 and escalating privileges, thus gaining unrestricted access to assets held in the contract. Instances with the executor role set to "open" allow anyone to use the executor role, thus leaving the timelock at risk of being taken over by an attacker. Patches A fix is included in the following releases of @openzeppelin/contracts and @openzeppelin/contracts-upgradeable: - 4.3.1 - 3.4.2 - 3.4.2-solc-0.7 Deployed instances of TimelockController should be replaced with a fixed version by migrating all assets, ownership, and roles. Workarounds 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. References Post-mortem. Credits The issue was identified by an…
Recommended action: Upgrade to 4.3.1 or 3.4.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.