OpenVM is a performant and modular zkVM framework built for customization and extensibility

Why it is Yellow

• CVSS 6.9 medium

References

• https://github.com/openvm-org/openvm/blob/v2.0.0-alpha/crates/sdk/contracts/template/OpenVmHalo2Verifier.sol
• https://github.com/openvm-org/openvm/blob/v2.0.0-beta.2/crates/sdk/contracts/template/OpenVmHalo2Verifier.sol
• https://github.com/openvm-org/openvm/blob/v2.1.0-dev.0/crates/sdk/contracts/template/OpenVmHalo2Verifier.sol
• https://github.com/openvm-org/openvm/commit/1962276254aabc5420de266a8cb672433ce955ff
• https://github.com/openvm-org/openvm/pull/152
• https://github.com/openvm-org/openvm/releases/tag/v1.7.0
• https://github.com/openvm-org/openvm/releases/tag/v2.0.0-rc.3
• https://github.com/openvm-org/openvm/releases/tag/v2.1.0-preview
• https://github.com/openvm-org/openvm/security/advisories/GHSA-w82q-w67c-67wv

Original description

OpenVM is a performant and modular zkVM framework built for customization and extensibility. Before 1.7.0 in the 1.x line and in affected 2.0 and 2.1 prereleases, `OpenVmHalo2Verifier.verify` accepts `appExeCommit` and `appVmCommit` as `bytes32` values without checking that either is less than the `BN254` scalar field modulus. Although public-value and proof-data lengths are checked, callers can provide non-canonical 256-bit encodings greater than or equal to that modulus at the Solidity wrapper boundary. Applications relying on the wrapper can therefore accept non-canonical app executable and app VM commitments, creating ambiguity between the supplied byte-level values and the field elements used by the verifier. This issue is fixed in versions 1.7.0, 2.0.0-rc.3 and 2.1.0-preview.