Summary
OpenZeppelin Contracts Wizard: Line terminators in info.securityContact / info.license can inject lines into generated source
The Contracts Wizard generators printed info.securityContact and info.license verbatim into a single-line comment of the generated Solidity, Cairo, Stellar/Soroban, and Stylus source without rejecting line terminators. A newline (\n or \r\n) in either field ends the comment, so the text after it is emitted as source rather than remaining inside the comment, allowing arbitrary declarations to be injected into the generated contract.
Impact
This only matters when these fields are filled from input other than the user who will use the generated contract. Normal self-service use does not meet that condition:
- Web app, AI assistant, and CLI: the user supplies these fields and uses their own output, so a line break only affects their own contract. (These fields are not URL-derived, so shared links cannot set them.)
- Self-hosted API: same, the end user supplies the options and consumes the result.
The case that matters is an integration that fills these fields from untrusted input, for example, an MCP agent whose tool arguments are derived from content it processed. There, a newline in the value can add lines to output that otherwise looks like normal Wizard source. Impact is integrity-only; there is no execution on any Wizard service.
Untrusted input is evaluated as executable code within the application's runtime environment. Typical impact: arbitrary code execution within the application's privilege context.
GHSA-9WXG-VF3R-56HC has a CVSS score of 3.3 (Low). The vector is requires local access, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.10.11, 3.0.1, 0.6.2, 0.3.1); upgrading removes the vulnerable code path.
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
Fixed by rejecting line terminators in setInfo, the single code path all surfaces use, so the value can no longer break out of the comment. Upgrade to the patched versions. @openzeppelin/wizard-confidential and @openzeppelin/wizard-uniswap-hooks reuse this setInfo through their @openzeppelin/wizard dependency and receive the fix once that dependency is updated to a patched version.
Frequently Asked Questions
- What is GHSA-9WXG-VF3R-56HC? GHSA-9WXG-VF3R-56HC is a low-severity code injection vulnerability in @openzeppelin/wizard (npm), affecting versions <= 0.10.10. It is fixed in 0.10.11, 3.0.1, 0.6.2, 0.3.1. Untrusted input is evaluated as executable code within the application's runtime environment.
- How severe is GHSA-9WXG-VF3R-56HC? GHSA-9WXG-VF3R-56HC has a CVSS score of 3.3 (Low). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which packages are affected by GHSA-9WXG-VF3R-56HC?
@openzeppelin/wizard(npm) (versions <= 0.10.10)@openzeppelin/wizard-cairo(npm) (versions <= 3.0.0)@openzeppelin/wizard-stellar(npm) (versions <= 0.6.1)@openzeppelin/wizard-stylus(npm) (versions <= 0.3.0)
- Is there a fix for GHSA-9WXG-VF3R-56HC? Yes. GHSA-9WXG-VF3R-56HC is fixed in 0.10.11, 3.0.1, 0.6.2, 0.3.1. Upgrade to this version or later.
- Is GHSA-9WXG-VF3R-56HC exploitable, and should I be worried? Whether GHSA-9WXG-VF3R-56HC 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-9WXG-VF3R-56HC 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-9WXG-VF3R-56HC?
- Upgrade
@openzeppelin/wizardto 0.10.11 or later - Upgrade
@openzeppelin/wizard-cairoto 3.0.1 or later - Upgrade
@openzeppelin/wizard-stellarto 0.6.2 or later - Upgrade
@openzeppelin/wizard-stylusto 0.3.1 or later
- Upgrade