Skip to main content
• 6 min read

HermesVault Exploit: $29K Drained and
Protocol Retired After Withdrawal Verification Key-Reset Flaw

HermesVault, an Algorand privacy protocol, retired after an attacker exploited withdrawal-verification logic to drain about 261,000 ALGO. Public reporting attributed the incident to a key-reset defense flaw rather than a break in the zero-knowledge circuit itself.

AUTOSEC.DEVAUTOSEC.DEV
HermesVault Exploit: $29K Drained and Protocol Retired After Withdrawal Verification Key-Reset Flaw
  • Incident Date: May 19, 2026; public reporting followed on May 20, 2026
  • Target: HermesVault / Algorand privacy vault withdrawal verification path
  • Target Overview: HermesVault was a privacy protocol on Algorand that used zero-knowledge proof concepts to let users deposit and withdraw funds with reduced linkability. Its public repository described the project as an immutable, ownerless, permissionless public-good style protocol.
  • Total Loss: Approximately 261,000 ALGO, reported at about $29,000
  • Recovery Status: Public reporting said about 230,000 ALGO had already been returned or refunded, with roughly 30,000 ALGO still eligible for full refund through proof of address ownership and the relevant secret note
  • Attack Vector: Withdrawal Verification Logic Flaw / Key-Reset Defense Bypass / Unauthorized Private-Vault Withdrawal

Incident Review & Technical Details​

1. Attack Path​

  1. Withdrawal Logic Was Targeted: The attacker focused on HermesVault's withdrawal verification flow on Algorand rather than the protocol's core zero-knowledge proof construction.
  2. Key-Reset Defense Logic Became the Weak Point: Public reporting attributed the issue to a flaw in the withdrawal verification script's key-reset defense logic. That component was intended to protect the withdrawal path, but the vulnerable branch let the attacker satisfy conditions that should not have authorized a withdrawal.
  3. ZK Circuit Was Not Reported as Broken: Coverage of the incident emphasized that the exploit did not come from a failure in the zero-knowledge circuit or AlgoPlonks-style proof machinery itself. The failure sat in the surrounding verification and withdrawal control logic.
  4. Unauthorized ALGO Was Withdrawn: The attacker drained approximately 261,000 ALGO, with public USD estimates around $29,000.
  5. Founder Publicly Disclosed the Incident: Giulio Pizzini, the project's creator, publicly confirmed the exploit on May 19, 2026, and later reporting said he planned to personally cover affected users.
  6. Refund Path Was Announced: Reports said approximately 230,000 ALGO had already been returned or refunded, while about 30,000 ALGO remained refundable if affected users could prove address ownership and provide the corresponding secret note.
  7. Protocol Was Retired: HermesVault was permanently retired after the incident. Public coverage framed the shutdown as a response to the exploit and the operational burden of safely continuing a privacy vault after a withdrawal-verification failure.

2. Impact Scope​

  • Direct Losses: Approximately 261,000 ALGO, valued around $29,000 at the time of reporting.
  • Affected Component: The vulnerable area was the withdrawal verification script / key-reset defense path.
  • Unaffected Claim: Public reporting did not identify a break in the core zero-knowledge proof system; the bug was described as application logic around withdrawal authorization.
  • User Impact: Affected users were directed toward a refund process that required ownership proof and the relevant secret note.
  • Protocol Status: HermesVault retired after the incident, meaning future users should not treat the service as an active privacy venue even if some immutable on-chain code or historical interfaces remain visible.
  • Disclosure Gap: As of the reviewed public materials, no full code-level post-mortem with exact failing predicates, transaction IDs, patched diff, and regression tests had been published.

3. Root Cause Assessment​

The incident is a useful reminder that a privacy protocol can have sound cryptographic primitives while still failing in the logic that surrounds those primitives.

Key risk patterns to examine:

  • Cryptographic Proofs Are Only One Boundary: A valid ZK proof does not make the whole system safe unless the withdrawal script also enforces note uniqueness, nullifier use, key-ownership rules, amount limits, and recovery or reset constraints.
  • Reset and Recovery Paths Are High-Risk: Any key-reset defense creates an alternate route through the authorization state machine. If that route can be triggered or interpreted incorrectly, it can become equivalent to withdrawal permission.
  • Privacy Increases Incident Complexity: Refunds require proving ownership without unnecessarily exposing private activity. That makes post-incident remediation slower and more delicate than in ordinary token contracts.
  • Immutable Public-Good Deployments Need Extra Pre-Launch Assurance: If a protocol is ownerless or hard to upgrade, a single withdrawal-logic flaw can leave retirement or migration as the only responsible option.
  • Small Protocols Still Carry Real User Risk: Even when a project charges no fees and is operated as a public good, withdrawal verification must be treated as custody-critical code.

The core invariant should have been strict: no withdrawal path, including key reset, recovery, or defensive fallback logic, may release funds unless it proves the caller controls a valid unspent note and marks that note as consumed exactly once.

4. Mitigation and Response​

Recommended actions for privacy vaults, ZK payment systems, and Algorand smart-contract applications:

  • Treat withdrawal scripts, nullifier handling, reset paths, and recovery logic as the same severity as the ZK circuit itself.
  • Build negative tests for every withdrawal branch: normal withdrawal, reset, recovery, malformed note, reused note, wrong key, wrong amount, and stale proof.
  • Require independent review of smart-contract logic around proof verification, not only the cryptographic circuit.
  • Add explicit invariants for conservation of value: total withdrawals plus remaining deposits must never exceed proven deposits minus already-consumed notes.
  • Avoid broad fallback logic in reset defenses; make each emergency branch narrow, observable, and testable.
  • Design refund workflows that let users prove ownership of affected notes while minimizing additional privacy leakage.
  • For immutable deployments, use staged caps, limited beta pools, formalized launch checklists, and public bug bounty windows before holding meaningful user balances.
  • Publish a final post-mortem with the vulnerable predicate, affected rounds, exploit transaction set, patched reference code, and regression tests so similar privacy protocols can learn from the failure.

AUTOSEC.DEV Solution: Building a 360-Degree Defense​

HermesVault's retirement shows that privacy protocol security depends on both cryptography and the ordinary state-machine logic around it. A ZK circuit can remain intact while a withdrawal verifier, reset rule, or note-consumption check still exposes funds.

  1. ZK Protocol Logic Review: AUTOSEC.DEV reviews proof-verification integration, note commitment handling, nullifier enforcement, withdrawal authorization, and value-conservation invariants.
  2. Smart Contract Audit for Algorand Apps: We test TEAL / PyTeal / AVM logic, local and global state transitions, signature paths, application-call groups, and edge cases around reset or recovery behavior.
  3. Privacy-Safe Incident Response: We support exploit reconstruction, affected-note scoping, refund-flow design, fund tracing, and user communication while minimizing unnecessary privacy exposure.
  4. Invariant & Regression Testing: We build property tests for no double-spend, no unauthorized withdrawal, no reset bypass, no value inflation, and no stale-proof acceptance.

Service Content​

Reference​