OpenZeppelin Contracts base64 encoding may read from potentially dirty memoryGHSA-9vx6-7xxf-x967
MEDIUMFix: OpenZeppelin/openzeppelin-contracts-upgradeable@2d081f2GHSA-9vx6-7xxf-x967 is a medium-severity (CVSS 6.5) Out-of-bounds Read vulnerability in @openzeppelin/contracts. A fix is available for @openzeppelin/contracts — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-9vx6-7xxf-x967.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@openzeppelin/contractsnpm@openzeppelin/contracts-upgradeablenpmDescription
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 memorystruct 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)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @openzeppelin/contracts | ≥ 4.5.0&&< 4.9.6 | 4.9.6npm install @openzeppelin/contracts@4.9.6 |
| 📦npm | @openzeppelin/contracts-upgradeable | ≥ 5.0.0-rc.0&&< 5.0.2 | 5.0.2npm install @openzeppelin/contracts-upgradeable@5.0.2 |
| 📦npm | @openzeppelin/contracts | ≥ 5.0.0-rc.0&&< 5.0.2 | 5.0.2npm install @openzeppelin/contracts@5.0.2 |
| 📦npm | @openzeppelin/contracts-upgradeable | ≥ 4.5.0&&< 4.9.6 | 4.9.6npm install @openzeppelin/contracts-upgradeable@4.9.6 |
Affected Products
contractsopenzeppelincontracts upgradeableopenzeppelinDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @openzeppelin/contracts, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @openzeppelin/contracts to 4.9.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9vx6-7xxf-x967 is resolved across your whole dependency graph.
Workarounds
Constrain what reaches the vulnerable code: limit the size and shape of untrusted input, isolate the affected component in a sandboxed or least-privileged process, and enable the platform's memory-safety mitigations (ASLR, stack protector, hardened allocator) so an out-of-bounds access is more likely to fail closed than to be exploitable.
Frequently Asked Questions
Is GHSA-9vx6-7xxf-x967 in your dependencies?
Find it across npm, including transitive dependencies.