GHSA-9c22-pwxw-p6hx CVE-2021-46320 CVE-2022-39384 GHSA-88g8-f5mf-f5rj
OpenZeppelin Contracts initializer reentrancy may lead to double initialization
- Severity
- 5.6 / 10
- Medium · CVSS 3.1
- Exploit chance (EPSS)
- 1.22%
- Chance of exploitation in the next 30 days. Higher than 68.61% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-665 Improper Initialization
- Fix
- Available
- 2 packages have a fixed version
Description
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 bounty on Immunefi.
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.
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| @openzeppelin/contracts | < 4.4.1 |
4.4.1 |
| @openzeppelin/contracts | >= 3.2.0, < 4.4.1 |
4.4.1 |
| @openzeppelin/contracts-upgradeable | >= 3.2.0, < 4.4.1 |
4.4.1 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
@openzeppelin/contracts npm → 4.4.1
- npm
npm install @openzeppelin/contracts@4.4.1- yarn
yarn add @openzeppelin/contracts@4.4.1- pnpm
pnpm add @openzeppelin/contracts@4.4.1
@openzeppelin/contracts-upgradeable npm → 4.4.1
- npm
npm install @openzeppelin/contracts-upgradeable@4.4.1- yarn
yarn add @openzeppelin/contracts-upgradeable@4.4.1- pnpm
pnpm add @openzeppelin/contracts-upgradeable@4.4.1
Severity breakdown
CVSS 3.1 5.6
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- Low
- Integrity
- Low
- Availability
- Low
Weakness
CWE-665: Improper Initialization
The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
How to prevent it
- Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, in Java, if the programmer does not explicitly initialize a variable, then the code could produce a compile-time error (if the variable is local) or automatically initialize the variable to the default value for the variable's type. In Perl, if explicit initialization is not performed, then a default value of undef is assigned, which is interpreted as 0, false, or an equivalent value depending on the context in which the variable is accessed.
- Architecture and Design: Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values.
- Implementation: Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage.
- Implementation: Pay close attention to complex conditionals that affect initialization, since some conditions might not perform the initialization.
- Implementation: Avoid race conditions (CWE-362) during initialization routines.
- Build and Compilation: Run or compile your product with settings that generate warnings about uninitialized variables or data.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-9rcw-c2f9-2j55 OpenZeppelin Contracts Bytes's lastIndexOf function with position argument performs out-of-bound memory access on empty buffers | Medium | Also affects @openzeppelin/contracts |
| GHSA-9vx6-7xxf-x967 OpenZeppelin Contracts base64 encoding may read from potentially dirty memory | High | Also affects @openzeppelin/contracts |
| GHSA-699g-q6qh-q4v8 OpenZeppelin Contracts and Contracts Upgradeable duplicated execution of subcalls in v4.9.4 | High | Also affects @openzeppelin/contracts |
| GHSA-g4vp-m682-qqmp OpenZeppelin Contracts vulnerable to Improper Escaping of Output | Medium | Also affects @openzeppelin/contracts |
| GHSA-wprv-93r4-jj2p OpenZeppelin Contracts using MerkleProof multiproofs may allow proving arbitrary leaves for specific trees | Medium | Also affects @openzeppelin/contracts |
| GHSA-5h3x-9wvq-w4m2 OpenZeppelin Contracts's governor proposal creation may be blocked by frontrunning | Medium | Also affects @openzeppelin/contracts |
| GHSA-mx2q-35m2-x2rh OpenZeppelin Contracts TransparentUpgradeableProxy clashing selector calls may not be delegated | Medium | Also affects @openzeppelin/contracts |
| GHSA-93hq-5wgc-jc82 GovernorCompatibilityBravo may trim proposal calldata | High | Also affects @openzeppelin/contracts |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor