Notifications
Clear all
Topic starter
01/08/2026 8:56 pm
TL;DR: A critical snarkVM flaw in Aleo enabled arbitrary proof forgery and could have let an attacker submit transactions from any known wallet address, according to VERIA LABS, with the team reporting a $65,000 bounty and no evidence of exploitation. The case shows that autonomous code review now needs governance for machine-discovered attack paths, not just human audit coverage.
NHIMG editorial — based on content published by VERIA LABS: Forging Transactions on Aleo, a $65,000 proof forgery
Questions worth separating out
Q: What breaks when a zk proof verifier fails to bind the full transcript?
A: The verifier can accept proofs that were never legitimately constructed, because the challenge values are no longer tied to the exact witness and commitment data they are meant to constrain.
Q: Why do proof systems need the same governance discipline as identity controls?
A: Because a valid proof is effectively a credential for state change.
Q: How do teams know whether batch verification is actually safe?
A: They need evidence that aggregation logic still preserves the protocol’s binding properties under malformed, reordered, and partially missing inputs.
Practitioner guidance
- Audit transcript absorption points in batch verification Trace every Fiat-Shamir challenge back to the exact prover messages it is supposed to bind.
- Treat proof verification as consensus-critical authorisation Classify verifier paths the same way you classify signing or privileged access controls.
- Use adversarial fuzzing against cryptographic edge cases Build tests that mutate witness order, batch composition, and challenge derivation to look for acceptance of malformed proofs.
What's in the full analysis
VERIA LABS' full blog post covers the technical detail this post intentionally leaves for the source:
- Line-by-line explanation of the Fiat-Shamir and KZG10 failure path inside snarkVM
- Full proof-of-concept construction showing how the forged transaction was assembled
- Validator-side fix discussion and the mainnet and testnet transaction scan that ruled out exploitation
- The responsible disclosure context behind the maximum $65,000 bug bounty
👉 Read VERIA LABS' analysis of the Aleo proof forgery and snarkVM flaw →
Aleo proof forgery and AI agents: what governance gap did it expose?
Explore further
01/08/2026 9:04 pm
AI-assisted cryptographic review is becoming a serious control surface, not a novelty. The article shows an agent finding a flaw in a codebase large enough that manual review would be slow and incomplete. That does not make the agent authoritative by default, but it does mean organisations should treat AI-discovered findings as part of the assurance pipeline, especially where protocol soundness is consensus-critical. The practitioner conclusion is that machine-assisted review needs provenance, reproducibility, and human validation before a fix is accepted.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Should security teams rely on AI agents to find cryptographic flaws?
A: They should use them as an additional discovery layer, not as the final authority. AI agents can traverse large codebases and surface weak points faster than manual review, but every finding still needs protocol-level confirmation, reproducible tests, and human sign-off. The right model is augmentation with assurance, not replacement of expert cryptographic review.
👉 Read our full editorial: Aleo proof forgery shows how AI agents can find hidden zkVM flaws
