Aztec alpha v5 proving system vulnerability

On 7 August 2026 Aztec published a disclosure stating that core contributors had identified a critical vulnerability in the Alpha V5 proving system on 27 July 2026, through "internal AI-assisted auditing" (Aztec disclosure). The post, written by Innokentii Sennovskii, says the finding "places V5 funds, applications, and contract state at risk."

This article sets out what Aztec has said, what the public record does not yet contain, and how this disclosure differs from two Barretenberg verifier advisories Aztec published in October.

Background: Alpha V5

Aztec activated Alpha V5 on 21 July 2026 after a token-holder governance vote executed onchain (Introducing Alpha V5). The launch post says V5 "resolves the critical issues found in V4," roughly halves protocol-circuit gate count, and that every private transaction is proven on the user's own device. Apps live at launch included Nyx, Shield, TRAIN, RavenHouse and Dark Forest Aztec (Introducing Alpha V5). The vulnerability was identified six days after activation.

What was exploitable

Aztec describes the flaw only at the level of its consequence: an attacker "may be able to exploit a flaw in the current V5 proving system by constructing a proof that passes verification for a transaction the network should reject" (Aztec disclosure). If such a transaction were accepted, it "could produce a state transition outside the rules V5 intends to enforce."

In proof-system terms this is a soundness failure: the verifier accepts a proof for a false statement. Aztec has not said which component is at fault — a circuit constraint, the prover/verifier implementation, the recursion/aggregation layer, or the L1 verifier — nor which transaction types are affected. The disclosure does not name a CVE, a GitHub advisory, a pull request, or affected version numbers.

Exploitation cannot be ruled out

Aztec states that contributors "cannot determine whether anyone exploited the flaw before this finding," because the system "lacks the information needed to distinguish ordinary accepted transactions from transactions accepted through the flawed proving path" (Aztec disclosure). Per the post, historical chain activity cannot establish whether exploitation occurred or quantify its impact. That is a property worth noting for any privacy rollup: when a forged proof is indistinguishable onchain from a valid one, a soundness bug has no forensic trail.

Who is affected and what Aztec asked them to do

The disclosure tells users to treat funds and applications on V5 as exposed to a protocol-level failure until incident response and the required operator actions are complete (Aztec disclosure). Its guidance, quoted in substance:

Teams planning a V5 deployment should pause until contributors publish further guidance.
Teams with live contracts should review their ability to limit user exposure, isolate affected functionality, and move users to fresh deployments if needed.
Applications with administrative or emergency controls should assess whether those controls can reduce user risk.
Application teams are expected to prepare safeguards — changes to application controls, deployment procedures, user flows and migration plans — in the coming weeks.

Core contributors said they were working with operators, application teams and bridge operators as applications add guards around affected flows (Aztec disclosure).

The fix

No fix has shipped on the V5 line according to the public record reviewed here. Aztec says the findings "will inform the V6 release, including circuit updates that prevent the network from accepting proofs tied to an affected proving system," with V6 planned for later in 2026, and that contributors will publish a security roadmap (Aztec disclosure).

The next aztec-packages release after the disclosure, v5.2.0 on 17 August 2026, is described as a maintenance release. Its notes state that protocol circuits and protocol contracts "ship as pinned, pre-built artifacts that are byte-identical to v5.1.0's," and that protocol constants (vk root and protocol-contracts root) are unchanged (v5.2.0 release). The circuits were therefore not changed in that release, which is consistent with the remediation being deferred to V6.

Aztec also states that reviewers had not identified other high-severity or critical V5 Alpha vulnerabilities at the time, and that internal and external human audits had completed (Aztec disclosure).

Not the same issue: the October Barretenberg advisories

On 8 October 2026 Aztec published two advisories against Barretenberg's native UltraHonk verifier, fixed in v5.2.1:

GHSA-2hc8-mq24-76v2 (high, CVSS 3.1 score 7.5): when exactly one point of a proof's public-input pairing accumulator (P0, P1) is the point at infinity, PairingPoints::aggregate treated the accumulator as uninitialized and replaced it, so the deferred recursive pairing check was never performed. The native verifier then accepted proofs of recursive circuits whose inner proofs are invalid. A malicious prover reaches this state by supplying an inner proof with a false opening and KZG quotient commitment [W] = ∞, which the in-circuit decoder accepts as (0, 0).
GHSA-73xc-j27q-wg75 (medium): in older versions the same path called throw_or_abort, so a crafted proof throws natively or aborts the WASM instance in @aztec/bb.js — a denial-of-service against services that verify untrusted proofs.

Both advisories cover off-chain verification via bb verify, @aztec/bb.js and barretenberg-rs. The high-severity advisory lists as not affected the generated Solidity verifiers, in-circuit recursive verification, non-recursive circuits, and "the Aztec network's state," because rollup proofs settle on L1 through the Solidity verifier (GHSA-2hc8). The v5.2.1 notes likewise say the release "does not affect the Aztec network" and that circuits and verification keys are identical to v5.2.0 (v5.2.1 release). Nothing in Aztec's publications links these advisories to the 27 July finding, and readers should not conflate them.

Teams using Barretenberg directly to verify recursive UltraHonk proofs off-chain are the audience v5.2.1 recommends upgrade for (v5.2.1 release).

What is unknown

As of 14 October 2026, the sources reviewed do not disclose: the vulnerable component or root cause; which transaction or proof types are forgeable; whether it was reported via the bug bounty or found only internally (the post says internal AI-assisted auditing); a CVE or GHSA identifier; and a V6 release date or the promised security roadmap.

What it means for teams shipping circuits

From Aztec's own account, two points are directly sourced. First, a soundness bug in a privacy system can leave no evidence of exploitation, so impact may be unquantifiable after the fact (Aztec disclosure). Second, Aztec's mitigation guidance leans on application-level controls — emergency powers, the ability to isolate functions and migrate users — which only help teams that built them in before an incident.

Timeline

2026-07-21 — Alpha V5 activated after onchain governance vote.
2026-07-27 — Critical V5 proving-system vulnerability identified via internal AI-assisted auditing.
2026-08-07 — Aztec publishes "Alpha V5 Proving System Vulnerability."
2026-08-17 — v5.2.0 released; protocol circuits byte-identical to v5.1.0.
2026-10-07/08 — v5.2.1 released with GHSA-2hc8-mq24-76v2 and GHSA-73xc-j27q-wg75 (Barretenberg native verifier; Aztec network stated unaffected).