Summary
Inconsistent storage layout for ERC2771ContextUpgradeable
Workarounds
Potentially breaking upgrades would be caught by the OpenZeppelin Upgrades Plugins for Hardhat and Truffle. It is recommended to use this tooling for all your upgrades.
If you need to upgrade to a newer version of the Upgradeable Contracts library, we recommend copying the previous implementation ERC2771ContextUpgradeable (available in the release-4.2 branch) and packaging it with your code.
Reference
https://github.com/OpenZeppelin/openzeppelin-transpiler/pull/86
For more information
If you have any questions, comments, or need assistance regarding this advisory, email us at [email protected].
To submit security reports please use our bug bounty on Immunefi.
Impact
The storage layout of the ERC2771ContextUpgradeable is not constant between versions.
- versions
4.0.0,4.1.0and4.2.0, the contract has a length of 51 slots. - since
4.3.0, the contract has a length of 50 slots - future versions will continue using 50 slots.
This difference in layout could result in breaking upgrades if someone upgrades from an affected version to a non-affected version. It is thus recommended to be extremely careful when upgrading from a contract that uses ERC2771ContextUpgradeable <4.3.0 to a newer version that uses >=4.3.0.
We've assessed the instances of this contract found on chain (with publicly verified source code) and notified the corresponding teams of the risk that an upgrade could cause.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-7J52-6FJP-58GR? GHSA-7J52-6FJP-58GR is a low-severity security vulnerability in @openzeppelin/contracts-upgradeable (npm), affecting versions >= 4.0.0, < 4.3.0. It is fixed in 4.3.0.
- Which versions of @openzeppelin/contracts-upgradeable are affected by GHSA-7J52-6FJP-58GR? @openzeppelin/contracts-upgradeable (npm) versions >= 4.0.0, < 4.3.0 is affected.
- Is there a fix for GHSA-7J52-6FJP-58GR? Yes. GHSA-7J52-6FJP-58GR is fixed in 4.3.0. Upgrade to this version or later.
- Is GHSA-7J52-6FJP-58GR exploitable, and should I be worried? Whether GHSA-7J52-6FJP-58GR is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-7J52-6FJP-58GR is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-7J52-6FJP-58GR? Upgrade
@openzeppelin/contracts-upgradeableto 4.3.0 or later.