Vana Foundation — 11 August 2026

Security Incident Analysis: Full Report

Summary

On 31 July 2026 an unauthorised party holding a legacy administrative key upgraded Vana's L1 validator deposit contract and transferred its balance of 1,120,000 VANA in a single transaction¹. Every access control on the contract functioned exactly as written. The transaction succeeded because the caller satisfied onlyOwner.

The key had been exposed on 2 June 2026 when an autonomous coding agent committed it to a public repository. Remediation began the same day. The contracts migrated at that point were identified by an ownership-pattern query, and the deposit contract, which stores its controlling address under a non-standard state variable, fell outside that query’s resolution and remained controlled by the exposed key until 31 July.

The malicious transaction was detected on 31 July and contained the same day. Every privileged role on Vana mainnet now sits behind a 3-of-7 multisig, verifiable on-chain against the addresses published below. Two independent security assessments, covering the chain and the operational environment, have confirmed the completeness of that work.

Independent verification

The Foundation commissioned two independent security assessments, covering the two domains in which this incident could have had further reach: the chain itself, and the operational environment in which the credential was exposed.

On-chain contract and authority security assessment

An independent security specialist with prior head-of-security experience at a major web3 platform and a large international technology company was engaged to assess the Vana chain for any contracts with privileged roles accessible by the exposed private key.

The security assessment enumerated every contract deployed on Vana mainnet and resolved each contract’s actual authority holder from on-chain state, rather than matching an expected ownership pattern. This establishes, by exhaustive enumeration, not internal attestation, the complete set of contracts and privileged roles on the network and who controls each. The scope also covered the completeness of the remediation and the adequacy of the controls now in place.

Scope was not limited to contracts reachable by the exposed key. The Foundation had a standing programme, in progress before this incident, to migrate all privileged authority away from externally-owned account control. The security assessment enumerated every contract still under EOA control regardless of any connection to this incident, and all have since been migrated.

Twenty four (24) contracts on Vana mainnet were found to reference 0x2AC93684679a5bdA03C6160def908CdB8D46792f in their storage slots. These contracts were discovered via four scans of Vana blockchain data. These scans were progressively broadened to support fast triage and then exhaustive enumeration.

1. 5 unique contracts were found enumerating all transactions between 0x2AC93684679a5bdA03C6160def908CdB8D46792f and smart contracts as well as EOAs and the contracts they transacted with from blocks 0 - 9,535,184. The storage slots were then scanned between blocks 9,544,790 – 9,545,518.
2. 15 unique contracts were found searching for 12 event topic hashes from blocks 0 - 9,535,184 then filtering for the address 0x2AC93684679a5bdA03C6160def908CdB8D46792f in topic 1, 2 or 3. The storage slots were then scanned between blocks 9,544,952 – 9,545,518.
3. 3 unique contracts were found from a corpus of 2,214 contracts that Vana provided. These storage slots were scanned between blocks 9,549,607 – 9,549,933.
4. 1 unique contract was found from an exhaustive search of all smart contracts (131,883 in total) deployed to the Vana blockchain using CREATE or CREATE2 between block 0 and block 9,552,772. These storage slots were then scanned between blocks 9,561,370–9,562,656.

When searching target contracts for storage slots containing 0x2AC93684679a5bdA03C6160def908CdB8D46792f the scanner first requests all populated slots using debug_storageRangeAt then each slot is requested and searched for the wallet address.

All 24 contracts were reported to the team as they were found. The team then proceeded to remediate them to contain the incident.

Operational and endpoint security assessment

Jones IT, the third-party firm responsible for the Foundation’s managed device estate, conducted a full-fleet operational security assessment. The estate operates under centralised mobile device management with endpoint detection and centralised logging, permitting review of device and console activity across the period between the credential exposure on 2 June and remediation, rather than a point-in-time check. The device identified as elevated risk was removed from service and placed under direct physical and forensic examination.

The assessment covered the Foundation’s managed macOS inventory and combined two independent methods. First, full-disk endpoint scanning through the estate’s endpoint detection and response platform, initiated fleet-wide on 4 August 2026, with agent presence, connectivity, encryption status and update status verified on every device, and scan completion events and threat activity history reviewed individually. Second, a read-only hunt script deployed through the mobile device management platform, targeting host indicators associated with known intrusion tradecraft used against organisations in this sector, including characteristic filesystem paths, persistence mechanisms installed as launch agents, malicious package lifecycle and downloader patterns, and associated process-path artefacts. Every endpoint in the inventory completed both methods with the exception of the elevated-risk device, which was offline for direct examination.

Completed checks identified no host indicators of this tradecraft. A small number of devices returned automated flags on package lifecycle patterns; analyst review confirmed each as a legitimate internal engineering script within the Foundation’s own codebase, and none were escalated. All remaining endpoints returned no indicators. Disk encryption was enabled and endpoint detection agents were current across every device in the inventory.

Jones IT’s assessment is that no indicators of this intrusion tradecraft are present on the fleet, and no evidence of broader unauthorised access to Foundation systems beyond the single compromised credential. Monitoring continues through the estate’s automated device check-in and endpoint detection cadence, and the elevated-risk endpoint remains out of production use pending final disposition.

Remediation

Two of these changes address the failure mechanism rather than its symptom, and they determine whether this class of incident can recur.

• Enumeration replaces pattern matching. Privileged access is now established by enumerating every contract deployed to Vana mainnet and resolving its actual authority holder from on-chain state. A contract storing its controlling address under a non-standard variable is captured, because the method no longer depends on a contract conforming to an expected shape. Applied across the network, this produced the complete inventory against which the remaining migrations were carried out.

• Privileged access is tracked continuously. Authority across the network is maintained as a live record under scheduled review rather than reconstructed during an incident, providing an independent reference against which any future change is reconciled.

Identification is now exhaustive rather than heuristic, and externally verifiable rather than self-reported. No contract on Vana mainnet retains single-key upgrade authority, and the mechanism used on 31 July no longer exists on the network.

Incident details

System background

The L1 validator deposit contract held 1,120,000 VANA behind an ERC-1967 UUPS proxy. Under UUPS, upgrade authorisation does not sit with the proxy; it resides in the implementation's _authorizeUpgrade hook, which in this contract was gated onlyOwner. The owner was a single externally-owned account rather than a multisig, with no timelock between authorisation and execution. A single valid signature was therefore sufficient to replace contract logic and execute against the new logic atomically.

The contract held validator security deposits recorded at the execution layer. Deposits entering the contract are permanently locked; validator enforcement operates through slashing conditions applied at exit rather than through withdrawal from the contract. These conditions remain intact.

Credential exposure

On 2 June 2026, an autonomous coding agent operating in a developer environment copied a private key from a local environment file into a test fixture and committed that file to a public repository. Public repository exposure means a credential must be treated as compromised from the moment of commit; automated scanners operating against public repository event streams routinely retrieve committed secrets within seconds.

Exposure was detected the same day and remediation commenced immediately. Roles held by the key were revoked and the contracts identified at that point were migrated to multisig control, reproducible on-chain from June 2026 transaction history.

Scope of the June remediation

Affected contracts were identified by querying for the exposed address in the standard owner storage slot exposed by Ownable, the pattern used across the large majority of the contract set. The L1 validator deposit contract holds its controlling address under a differently-named state variable and fell outside that query's resolution, so it was not included in the June migration.

Two conditions determined that scope. Identification resolved contracts matching a known ownership pattern rather than enumerating every deployed contract and resolving its actual authority holder. And privileged access was compiled from source during remediation rather than tracked continuously, so there was no independent reference to reconcile the query’s output against. Both are addressed above.

Execution

The actor deployed a minimal replacement implementation exposing only withdraw() and proxiableUUID(). proxiableUUID() returns the ERC-1967 implementation slot identifier, the check UUPS performs to confirm a target is a valid upgradeable implementation and prevent bricking the proxy; the replacement satisfies it. The actor then called upgradeToAndCall, which writes the new implementation address to the ERC-1967 implementation slot and executes supplied calldata against it in the same transaction, installing the drain logic and invoking it atomically with no intervening block.

The replacement implementation exposes no upgradeTo or _authorizeUpgrade path. The proxy is permanently immutable at that implementation and holds no balance.

Detection and containment

The transaction was detected on 31 July, the day it occurred. Containment was completed the same day: the key was retired, its roles revoked, and privileged access across the network locked down. Independent security assessments, hardening, and the remaining authority migrations followed in the period since.

Control assessment

Impact

The loss is confined to the balance held in the L1 validator deposit contract: 1,120,000 VANA, taken in the transaction referenced below. The transaction moved existing tokens held in a single contract, which bounds what it could reach.

• No user funds were affected. No user, data contributor, or member of the public lost funds, and no user action is or was required at any point.

• Total supply is unchanged. The transaction moved existing tokens and did not touch issuance.

• Foundation treasury assets were not accessed. Treasury is held with a qualified custodian under separate controls and was not reachable from this contract.

Network operation was unaffected throughout. Consensus, block production, and finality continued without interruption across the incident window, and the remainder of the protocol’s contract infrastructure operated normally. The exploit path was administrative authority over a single staking system contract, not a defect in the protocol.

Validator operations

The validators concerned continue to operate, with no interruption to their participation in consensus. Slashing conditions are unaffected by this incident and remain fully enforceable.

Validators with questions relating to this incident should contact the Foundation directly.

Recovery

Destination wallets have been identified and the movement of funds is being traced. Reports have been filed with law enforcement in several jurisdictions, and the Foundation is coordinating with the relevant authorities and with exchange and infrastructure partners.

Because that investigation is active and involves law enforcement, the Foundation is not able to comment on the movement, liquidation, or current disposition of the funds, or on the parties assisting with tracing.

Reference

Origin transaction: 0x95e9c26e01a35ab939b3442a89048b356f887d132b7afa13550e41a61cb86eb5 (Vana mainnet, block 9,475,269)

Contracts under multisig control

Each migration is verifiable on-chain.

All figures are reproducible against https://rpc.vana.org and https://vanascan.io/api/v2.

Security disclosures: security@vanafoundation.org

Acknowledgements

We are grateful to the exchange and infrastructure partners who responded quickly to help trace and flag the movement of funds, and whose assistance has been material to the ongoing investigation.