Listen to this Post
How the Vulnerability Works
Triton VM is a zero‑knowledge virtual machine that uses Algebraic Execution Tables (AET) and Arithmetic Intermediate Representations (AIR) together with a STARK proof system to attest correct program execution. One of its core instructions is sponge_absorb_mem, which reads a memory location and absorbs its content into the global Sponge state (based on the Tip5 permutation) to produce a cryptographic hash. This instruction is essential for building memory‑based commitments – the prover claims that a certain hash corresponds to the actual data stored at a given memory address.
The vulnerability arises because the VM’s constraint system does not enforce that the values fed into the sponge actually originate from the claimed memory cell. In other words, the arithmetization lacks a constraint that ties the absorbed words to the RAM read operation. A malicious prover can therefore skip the genuine memory read and instead inject arbitrary, attacker‑chosen data directly into the sponge absorption phase. The resulting proof will contain a hash that does not match the real memory contents, yet the verifier will accept it as valid because the missing constraint is never checked.
This breaks the soundness of any higher‑level protocol that relies on `sponge_absorb_mem` to commit to memory – for example, Merkle‑tree based storage proofs, state commitments, or any application that hashes RAM data as part of its integrity logic. An attacker can forge proofs for arbitrary memory states, effectively lying about what data was actually present during execution.
The flaw existed in all Triton VM versions from `0.42.0‑alpha.4` up to (but not including) 4.0.0. The maintainers addressed it by adding the missing constraints in commits `17c7ba0a` and ef9d9e72, which ensure that the sponge absorbs exactly the words that were read from the specified memory address. The fixed version `4.0.0` and later are fully patched.
DailyCVE Form:
Platform: Triton VM
Version: >=0.42.0‑alpha.4, <4.0.0
Vulnerability: Missing constraint in sponge_absorb_mem allows arbitrary data substitution
Severity: Moderate
date: 2026‑08‑18
Prediction: Already patched in 4.0.0 (commits 17c7ba0a, ef9d9e72)
What Undercode Say (Analytics)
Check current Triton VM version cargo tree | grep triton-vm Verify if the installed version is vulnerable (between 0.42.0-alpha.4 and 4.0.0) cargo pkgid triton-vm | grep -E "0.42.[0-9]|0.[4-9][3-9].[0-9]|[1-3].[0-9]+.[0-9]" List all commits that touch sponge_absorb_mem constraints git log --oneline --grep="sponge_absorb_mem" --grep="constraint" --all Diff of the fix (example) git show 17c7ba0a -- src/arithmetization/constraints.rs git show ef9d9e72 -- src/vm/instruction_sponge.rs
// Conceptual code snippet showing the missing constraint (pre‑fix) // In the old version, the sponge absorption did not link the absorbed words to RAM reads. // The fix adds a constraint like: // sponge_absorb_mem(addr) => absorbed[0..n] == ram[addr..addr+n] // This ensures the hash is computed over the actual memory contents.
Exploit (Educational Purposes!)
A malicious prover can craft a proof as follows:
1. Execute a program that calls `sponge_absorb_mem` on a legitimate memory address.
2. During proof generation, replace the actual RAM read with attacker‑supplied values.
3. Because the constraint system does not verify that the absorbed words equal the memory content, the STARK proof remains valid.
4. Submit the proof to a verifier – it will accept the forged hash as if it came from the real memory.
This effectively allows the prover to lie about any memory‑based commitment, undermining the integrity of applications that rely on `sponge_absorb_mem` (e.g., state roots, Merkle proofs, or data availability checks).
Protection
- Upgrade to Triton VM version `4.0.0` or later immediately.
- If upgrading is not possible, avoid using the `sponge_absorb_mem` instruction in any security‑sensitive context until the patch can be applied.
- Verify that your dependencies do not pull in an affected version by running `cargo update` and checking the output of
cargo tree. - Monitor the official Triton VM repository for future security advisories.
Impact
- Soundness loss – malicious provers can forge proofs for arbitrary memory states, breaking the zero‑knowledge soundness guarantee.
- Compromised commitments – any application that uses `sponge_absorb_mem` to hash memory data (e.g., state commitments, Merkle trees) becomes untrustworthy.
- Widespread exposure – all versions from `0.42.0‑alpha.4` through `3.x` are affected, impacting a large number of projects that depend on
triton‑vm. - No known active exploits – as of the advisory date, no public exploit has been observed, but the risk is elevated due to the ease of forging proofs.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
