Triton VM Soundness Vulnerability due to Missing Constraint

published 2021-06-11 5y ago modified 2026-08-24 2mo ago also RUSTSEC-2021-0156

cvss: —; not scored
cisa kev: Not listed; not in CISA's catalog
epss: —; no score, EPSS covers CVEs only
public exploits: 0; none known

The instruction `sponge_absorb_mem` Triton VM fails to verify that hashed values come from the claimed memory location. Malicious provers can substitute arbitrary data instead of actual memory contents.

Any application using instruction `sponge_absorb_mem` to hash memory data can be given a proof for a forged hash that doesn't correspond to the actual memory. This breaks the security of memory-based commitments.

The flaw was corrected in commits `17c7ba0a` and `ef9d9e72` by including the appropriate constraints.

Patch / fix

fixed in 1 links 1

crates.io triton-vm 4.0.0

github.com/TritonVM/triton-vm@17c7ba0 commit

Is GHSA-vjf8-9fx6-mv6x in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Affected packages

ecosystem	package	affected	fixed in
crates.io	triton-vm	>=0.42.0-alpha.4, <4.0.0	4.0.0

Classification

Weakness

CWE-345 Insufficient Verification of Data Authenticity

References

github.com /TritonVM/triton-vm/commit/17c7ba0a19f31793f1c807a58afaf9504342aac5
web
github.com /TritonVM/triton-vm
package
rustsec.org /advisories/RUSTSEC-2021-0156.html
web, advisory
crates.io /crates/triton-vm
package

Sources

GitHub Advisory GHSA-vjf8-9fx6-mv6x
OSV RUSTSEC-2021-0156

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.