Aleo proof forgery shows how AI agents can find hidden zkVM flaws

At a glance

What this is: Veria Labs analysed a critical Aleo snarkVM proof forgery that could have allowed any known wallet address to submit arbitrary transactions.

Why it matters: It matters because transaction integrity, proof soundness, and validator trust all depend on controls that can detect deep cryptographic implementation flaws before they become chain-wide identity and authorisation failures.

👉 Read VERIA LABS' analysis of the Aleo proof forgery and snarkVM flaw

Context

Aleo proof soundness is not just a cryptography problem, it is an authorisation problem for a blockchain. If a verifier accepts forged proofs, the network can no longer distinguish legitimate state transitions from attacker-authored ones, which turns a mathematical bug into a control failure.

The article is primarily about how an AI agent found a missing Fiat-Shamir absorb in snarkVM and how that gap affected transaction verification across the chain. For identity and access practitioners, the intersection is clear: proof systems, wallet authorisation, and validator trust all behave like machine identity controls when the chain depends on them for legitimacy.

Key questions

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. In practice, that turns soundness into an attacker-controlled degree of freedom and can let invalid state transitions pass as valid. The result is not just a bug, but a broken authorisation decision for the whole protocol.

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. If the proof can be forged, the system cannot reliably tell whether a transaction, message, or update was authorised by the legitimate actor. That means proof verification needs ownership, testing, review, and monitoring discipline similar to signing keys, privileged accounts, and other high-trust identities.

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. The right signals are negative tests that fail on forged transcripts, independent reimplementation checks, and code review that traces challenge derivation end to end. If any of those can be bypassed, batch verification is not yet trustworthy.

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.

Technical breakdown

Fiat-Shamir binding in zkSNARK verification

Fiat-Shamir turns an interactive proof into a non-interactive one by deriving verifier challenges from a transcript sponge. The security requirement is simple but strict: every prover message that a challenge is supposed to bind must be absorbed before the challenge is sampled. If a message is omitted, the prover can shape later values after seeing the challenge, which breaks soundness even when the rest of the protocol is implemented correctly. In this case, the missing absorb meant the verifier’s random weights were not actually tied to the witness values they should have constrained.

Practical implication: verify that every challenge derives from a complete transcript, not just from the parts that are easiest to instrument.

Why batch verification changes the risk surface

Batch verification compresses many opening checks into a single pairing equation so validators do not pay the cost of verifying each proof separately. That efficiency comes with a stronger dependency on the aggregation logic, because a flaw in the combined equation can invalidate every proof in the batch. The article’s bug sits in that boundary: the verifier sampled random weights, but the values that should have been bound into the batch were not fully absorbed into the sponge. When batching is wrong, the failure is not local, it becomes systemic.

Practical implication: treat batch-verification code as consensus-critical and subject it to dedicated review, differential testing, and replayable proofs.

From proof forgery to transaction authorisation failure

In a zkVM, a valid proof is the equivalent of a transaction authorisation token. If the proof can be forged, an attacker can present arbitrary state transitions as legitimate without needing the original wallet owner’s secrets. The article shows how the bug propagated from a vulnerable polynomial commitment check into a full end-to-end forged execution proof, which is exactly why cryptographic integrity and access control cannot be separated in blockchain systems. Proof validity is the access decision.

Practical implication: map proof verification to authorisation control and require threat modelling at the same level as key management and signing logic.

Threat narrative

Attacker objective: Forge valid-looking transactions that move funds without the true wallet holder’s authorisation.

1. Entry occurred through a flaw in the snarkVM verification path, specifically a missing Fiat-Shamir absorb in the batch polynomial commitment check.
2. Credential or authorisation abuse followed when the forged proof no longer depended on a legitimate wallet owner’s secret, allowing arbitrary transaction creation from any known address.
3. Impact would have been chain-wide transaction forgery, with attackers able to submit false transfers and drain value while appearing valid to validators.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Transcript-binding failure is the right named concept for this class of bug. The issue was not a generic coding mistake, it was a failure to bind the verifier’s random challenge to the full prover transcript. That is a precise governance failure mode because it converts a soundness guarantee into an attacker-controlled degree of freedom. For teams working on zk systems, the control gap is not just code quality, it is whether every challenge-sampling step is cryptographically anchored to the correct inputs.

Proof soundness is effectively an identity control for blockchain state. In systems like Aleo, the proof is the credential that authorises a state transition. When that credential can be forged, the network loses the ability to distinguish legitimate from illegitimate action. That is why cryptography teams, wallet infrastructure teams, and protocol engineers should frame verifier logic as access control, not just maths. The practitioner conclusion is to govern proof verification with the same seriousness as privileged signing paths.

This kind of flaw validates continuous adversarial testing, not periodic assurance alone. The article explicitly contrasts deep, autonomous code traversal with the limits of ordinary audits and pentests. For the field, the lesson is not that audits fail, but that they are insufficient for highly specialised protocol implementations unless paired with fuzzing, symbolic checks, and independent adversarial search. The practitioner conclusion is to assume a single review layer will miss edge-case soundness failures.

Consensus systems need a named control concept: verifier integrity drift. Once a batch-verification path diverges from the transcript assumptions the protocol depends on, the whole trust model starts to drift away from the specification. That drift can sit undetected even in well-reviewed code, because the output still looks mathematically plausible. The practitioner conclusion is to monitor for specification divergence as a first-class risk, not just implementation defects.

From our research:

• 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.
• For a deeper identity view, see Top 10 NHI Issues for the control gaps that emerge when machine credentials spread across environments.

What this signals

Transcript-binding failure is the kind of control gap that will matter more as AI agents are used to review specialised security code. The practical shift for programmes is to combine AI-assisted discovery with formal verification, regression tests, and specialist review, because one missed absorb point can collapse an entire trust model.

For identity and access programmes, the lesson is that proof verification, signing logic, and wallet authorisation all sit in the same trust chain. That makes cryptographic review part of governance, not a niche engineering concern, and it aligns closely with the control themes in Top 10 NHI Issues when machine identities are relied on to make security decisions.

The broader signal is that autonomous analysis can uncover failures in places where ordinary testing has diminishing returns, but it also creates a new assurance requirement: prove the prover. If your verification path is consensus-critical, you need independent evidence that the implementation still matches the protocol specification under adversarial input.

For practitioners

• Audit transcript absorption points in batch verification Trace every Fiat-Shamir challenge back to the exact prover messages it is supposed to bind. Require reviewers to confirm that no challenge is sampled before all relevant witness values and commitments are absorbed into the sponge state.
• Treat proof verification as consensus-critical authorisation Classify verifier paths the same way you classify signing or privileged access controls. That means explicit ownership, code review by protocol specialists, regression tests on forged transcripts, and release gating for any change to the verification pipeline.
• 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. Pair fuzzing with property-based checks so the harness can prove when the verifier accepts inputs that should be rejected.
• Separate independent validation from implementation review Run a second verification path, ideally with different assumptions or tooling, to confirm that the main implementation matches the protocol specification. This is especially important when a single function can influence all validator decisions.

Key takeaways

• This disclosure shows that a single transcript-binding error can turn zk proof verification into a transaction-authorisation bypass.
• The article’s own evidence shows how quickly an AI agent moved from a 400,000-line codebase to a full proof-forgery path, which is exactly the kind of coverage gap periodic review can miss.
• Teams working on zkVMs should govern verifier logic as critical access control, with adversarial testing and independent validation as mandatory safeguards.

Key terms

• Fiat-Shamir Transform: A method that replaces interactive verifier challenges with challenge values derived from a transcript sponge or hash. Its soundness depends on every message that should influence the challenge being absorbed first, otherwise the prover can manipulate later steps after seeing the challenge.
• Batch Verification: A verification technique that combines many proof checks into a smaller number of aggregated equations. It improves performance, but it also concentrates risk, because a flaw in the aggregation logic can undermine all of the proofs that were supposed to be checked together.
• Proof Soundness: The property that a verifier accepts only proofs for statements that are actually true. In blockchain and zkVM systems, soundness is the control that prevents attacker-generated proofs from being treated as legitimate authorisation for a transaction or state transition.
• Transcript Binding: The guarantee that a challenge or response is mathematically tied to the complete set of prover messages that preceded it. If binding fails, later proof values can be influenced after the challenge is known, which breaks the security assumptions of the protocol.

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

👉 VERIA LABS' full post covers the cryptographic root cause, proof construction, and validator response in detail.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security practitioners a structured way to apply identity controls to high-trust systems and operational workflows.