Skip to content

← Public intelligence

crates.io package

triton-vm

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 6.9crates.ioAmendedPublished

    Triton VM Soundness Vulnerability due to Missing Constraint

    GHSA-vjf8-9fx6-mv6x

    Affected
    • crates.io triton-vm >= 0.42.0-alpha.4, < 4.0.0
    Fixed in
    4.0.0· Vendor fix available
    Issue
    The instruction spongeabsorbmem 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 spongeabsorbmem 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.

    Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  2. Low, CVSS 1.7crates.ioPublished

    Triton VM has a Soundness Vulnerability due to Improper Sampling of Randomness

    GHSA-rjr4-v43m-pxq6

    Affected
    • crates.io triton-vm >= 0.41.0, < 2.0.0
    Fixed in
    2.0.0· Vendor fix available
    Issue
    In affected versions of Triton VM, the verifier failed to correctly sample randomness in the FRI sub-protocol. Malicious provers can exploit this to craft proofs for arbitrary statements that this verifier accepts as valid, undermining soundness. Protocols that rely on proofs and the supplied verifier of the affected versions of Triton VM are completely broken. Protocols implementing their own verifier might be unaffected. The flaw was corrected in commit 3a045d63, where the relevant randomness is sampled correctly.

    Recommended action: Upgrade to 2.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →