Burn Notice #4
A Laptop That Cleared Two Multisigs, Opus 4.8’s Four-Year Zcash Bug, and a One-Vote DAO Takeover
Three incidents this week, and the through line runs through everything an audit tends to leave out. A compromised employee laptop cleared multisig thresholds on two chains. An AI auditor surfaced a four-year-old soundness gap in a shielded circuit, while a single wallet bought its way to controlling a DAO and minted itself a payout.
In today’s issue.
How one employee laptop held enough keys to take Humanity Protocol’s bridges on both Ethereum and BSC.
Why Opus 4.8 surfaced a Zcash Orchard forgery bug that survived four years of expert human review.
A one-transaction DAO takeover that drained a Balancer pool, plus the fake Sentry alerts aimed at your coding agent.
Need to Know
Two of this week's three headline events were losses, one through compromised keys and one through a governance takeover. Humanity's signers were nominally spread across a multisig, yet they sat close enough together that one compromised device could act for all of them, and a thinly held DAO changed hands the moment an attacker bought a majority of its own vote. The third event was the opposite of a loss, an AI auditor catching a forgery bug that years of human review had missed, the same week attackers were aiming forged alerts at AI coding agents. If your threshold is above one but your keys ride on the same laptop, what is that threshold actually protecting you from? — Adrian
The Big One. Humanity Protocol’s $36M Laptop
The news. On 8 June, an attacker took ownership of the ProxyAdmin behind Humanity Protocol’s Hyperlane bridge on Ethereum, upgraded the bridge to a malicious implementation, and moved roughly 141.2 million H in a single transaction. The same operator repeated the takeover on BSC and deployed a contract with an unlimited mint function, pushing the combined impact past $36M across both chains. Every action used legitimately authorised keys.
What broke and how. On Ethereum, three of the six Gnosis Safe owner keys controlling the bridge’s ProxyAdmin were compromised. That was enough to transfer ProxyAdmin ownership to a wallet the attacker controlled, swap in a malicious bridge implementation, and drain the bridge in one move. On BSC, three of five Safe owner keys went the same way, and the attacker minted just over 200 million fresh H in two tranches straight to their own address. A third, smaller leg took around 6 million H from an admin hot wallet, for a total impact the team puts near 447 million H.
The single point underneath all of it was an employee laptop. Founder Terence Kwok said the device was compromisedand held enough active private keys to cross the signing threshold on both chains at the same time. The attacker later left an on-chain note saying they had braced to social-engineer several developers across time zones, only to find the keys sitting together on one machine. The multisig existed on paper, but in practice it behaved like a single signer.
Why it kept happening. This is the same failure that ran through 2026’s headline losses. Kelp DAO, Resolv, and the Gravity Bridge drain elsewhere in this issue were written off in the press as bridge bugs, when the keys and the signers were the real failure each time. A threshold scheme only buys you safety when the signers are genuinely independent. Once the keys share a laptop, a cloud sync, or one human’s browser session, the n-of-m is theatre. ZachXBT first read Humanity as a possibly staged exit for an active market maker ahead of the 25 June unlock, then walked that back after tracing the laundering, concluding the suspicious market-making and the key compromise were unrelated.
What to check now.
Map every signer on your highest-value multisig to a physical device and a named human, and confirm no single laptop or browser profile can produce more than one signature.
Treat any ProxyAdmin or upgrade-authority key as a higher tier than ordinary signers, and put a timelock in front of upgrades so a quiet implementation swap cannot settle in one block.
Pull the full list of addresses that can mint, upgrade, or migrate, and ask who would notice within minutes if one of them fired tonight.
Rehearse the key-rotation runbook against the case where the threshold is already crossed, not the case where one key leaks.
The operator move.
Go count how many of your signing keys could be sitting on the same machine right now. If that number is higher than your threshold minus one, your multisig collapses to one device under a single compromise, and the rest is decoration. Fix signer independence before you add another signer.
— Adrian
Chain Reaction. Zcash’s Four-Year Orchard Forgery Bug
The news. On 29 May, independent researcher Taylor Hornby surfaced a soundness bug in Zcash’s Orchard shielded pool during an audit Shielded Labs had engaged him for back in April, working with a custom auditing framework built on Claude Opus 4.8. The flaw lived in the elliptic-curve multiplication gadget in the halo2 circuit, an under-constrained check that let a prover feed false values the network would still accept as a valid proof. In a local test the exploit minted unlimited counterfeit ZEC. No funds were lost on mainnet.
What broke and how. Orchard has been live since May 2022, which means the gap sat in production for roughly four years and through multiple rounds of expert human review. The bug allowed forging or double-spending value inside the shielded pool, and because Orchard hides amounts and participants, an exploit would have left no on-chain fingerprint. Shielded Labs has said it cannot prove cryptographically that nobody used it, only that turnstile accounting shows no unauthorised supply while the flaw was live.
The response was quick. A soft fork through Zebra 4.5.3 disabled Orchard at block 3,363,426 on 2 June, and the NU6.2 hard fork re-enabled it with a corrected circuit a day later. ZEC still fell around 30% on the disclosure, and Shielded Labs is now floating a turnstile upgrade so anyone can verify the ZEC supply independently.
Why it kept happening. Under-constrained circuits are the most common finding class in zero-knowledge audits by a wide margin. Four years and several paid audits looked at this circuit and missed a single missing constraint, and what changed since was the cost of a thorough pass over a cryptographic component once a capable model could be aimed at exactly that layer. The same capability is already being turned the other way, with attackers crafting forged alerts to push coding agents into running malicious commands. AI now sits on both sides of the audit, and most teams have a plan for neither.
What to check now.
If you run ZK circuits, prioritise constraint completeness in your arithmetic gadgets, and treat an under-constrained element as the default suspicion rather than the edge case.
Ask whether your supply or value invariants are externally verifiable, or whether your own privacy guarantees would hide an inflation bug from you as well.
Add a frontier-model audit pass to your pre-deployment process for the highest-risk components, and assume an attacker is running the same pass against your deployed code.
The operator move.
Take the component you have audited the most, the one you trust, and run a fresh model over it this week with a single instruction to forge or inflate value. The code that has survived the most review is the code most worth pointing new tools at. Budget a day for it before someone else budgets a day for you.
— Adrian
Around the Forums
Zcash ships its second-ever security-driven upgrade. The Orchard fix went out as a coordinated two-phase response from the Zcash Foundation and Electric Coin Company, a soft fork to freeze Orchard followed within a day by the NU6.2 hard fork to re-enable it on a corrected circuit. The technical detail is in Chain Reaction above. What matters at the governance layer is that a fully shielded network managed an emergency upgrade fast enough to patch before any provable exploitation. It is now proposing a standing turnstile mechanism so that supply verification stops depending on trusting the core team’s word.
A legacy Aragon config hands over a DAO in one transaction. The Token of Power takeover, covered below, ran on an older Aragon setup that allowed proposal creation, voting, and execution in a single transaction with no timelock. Any DAO still on a legacy MiniMeToken framework with a small float should read this as the precedent it is. The configuration permitted a single wallet to propose, pass, and execute a mint in one transaction, and the attacker did exactly that.
What Else Happened
Source-destination value binding gap on Gravity Bridge. The Cosmos-to-Ethereum bridge lost $5.4M on 30 May after an attacker minted worthless tokens on Osmosis, poisoned the denom-to-ERC20 registry with a fabricated denom string mapping fake balances to real custody contracts, and withdrew the real assets. The official post-mortem is still pending, and early press framed it as a suspected key compromise.
Governance takeover on Token of Power. An attacker bought 8,192 of TOP’s 16,384 total supply, crossed the 50% voting threshold, and pushed a single proposal that minted billions of new TOP with no timelock and no mint cap, swapping them against the TOP/WETH Balancer V1 pool for 944.2 WETH worth about $1.58M. The Balancer pool was only the exit route.
Indirect prompt injection via forged Sentry alerts. Attackers abused public Sentry DSNs to plant fake error events designed to push a human or AI coding agent into running a typosquatted
npxpackage that exfiltrates environment secrets to advisory-tracker[.]com. Sentry has published a security advisory and IOCs are public.Autonomous L2 bug discovery on Spark. The V12 agent found and built a working PoC for a cross-tree root overwrite in deposit-tree creation on Lightspark’s Bitcoin L2, where four non-unique fields let two deposits collide on the same root node. The bug was responsibly disclosed and fixed.
On the Clock
One item with a clock on it this week. If your team runs coding agents or auto-remediation against alert and log streams, treat the forged-Sentry campaign above as live. Assume any machine that may have run the fake diagnostic has leaked its environment, rotate every credential reachable from it, and stop letting agents execute commands lifted from alert bodies without an out-of-band check. The rest of this week’s incidents are post-mortem reading, not emergencies.
Long Reads
Humanity Protocol’s incident breakdown on the three breach vectors, worth reading alongside ZachXBT’s threadwalking from a staged-exit hypothesis to a key-compromise conclusion, for a clean example of how laundering analysis separates the two.
Rekt on the Gravity Bridge drain for how a bridge gets emptied by feeding it a registry entry it never validated.
The Zcash disclosure from Zooko Wilcox and Shielded Labs for the clearest account of the constraint gap, the emergency forks, and the turnstile-upgrade proposal.
V12 on the Spark L2 bug for a concrete look at an agent finding a non-obvious tree-integrity flaw end to end, and Noema Labs’ AutoCertora release if you want to point the same class of tooling at your own Solidity.
Rekt’s supply-chain trilogy, stack-nobody-checked, paranoid-by-default, and poisoned-pipeline, if the forged-Sentry item has you reviewing how much your pipeline trusts by default.
The Operator’s Read
Point the Agents at Your Oldest Code
Two bugs got found the same way this week, and the way they were found is the actual story. An AI auditor went back through Zcash’s Orchard circuit and surfaced a missing constraint that had been sitting in a shielded pool since 2022. Days earlier, a separate autonomous tool pulled CVE-2026-23479 out of Redis, an authenticated route to running OS commands that shipped in 7.2.0 and survived more than two years across every stable branch. Both were old, both lived in reviewed and trusted code, and both stayed hidden until a machine read the right layer with enough patience.
I said last week that the contract layer is getting harder to break, and I meant it. Audits got sharper, and the obvious bug classes mostly get caught before they ship now. These two finds are what the next turn of that screw looks like. The bugs that remain are the non-obvious ones, the constraint that reads correct until you model what it forgets to forbid, the use-after-free that only fires when a blocked client gets evicted mid-command. A tireless reader with a strong model in front of it is built for exactly that shape of bug.
The Orchard one sits differently from a normal disclosure, for the reason I gave earlier in this issue. The Redis flaw is the familiar shape instead, a CVE with a patch and a version table.
Both sides of this are producing results. From where I sit, the offensive half is the part the celebration keeps skipping. The same capability that read Orchard and Redis is available to anyone who wants to read your code with intent, and the distance between how quickly a defender finds one of these and how quickly an attacker does has not closed. The tool is neutral. The outcome turns on who reaches for it first and what they aim it at.
That changes the economics of old code in a way most teams have not priced. For years the safe assumption was that the more eyes a component had passed, the less likely it was hiding something. That assumption is now backwards at the margin. The most-audited contract in your system is the most attractive place for a surviving bug, because everyone downstream treats it as settled and stops looking. A model does not care that the code is famous or that three firms signed off, it just reads what is in front of it.
The point I keep being surprised I have to repeat is that none of this means trusting the output blindly. These finds landed because professionals built scoped agents, aimed them at a specific layer, and then did the work of confirming a real exploit. The model proposes, and a human who knows the domain still has to prove it and avoid getting played by a confident wrong answer. Used that way, in skilled hands, it is the sharpest reviewer you can put on code you have already paid to have checked.
The single audit pass is the tactical version, and it is sitting in the operator move above. The strategic version is treating your legacy surface as a backlog with a clock on it. Rank your oldest, highest-value, most-trusted components by what an attacker gains if one of them turns out to hold a surviving flaw, and start working down that list with the new tooling before the list gets worked from the other side. The code you wrote in 2022 and stopped thinking about is the code most worth rereading in 2026.
My bet for the back half of this year is a nine-figure loss traced to a years-old bug that an attacker found with an agent before the defender did. The capability is here, the incentive is plain, and trusted-and-forgotten code is everywhere. The teams that get ahead of it will be the ones who put their oldest code back on the audit table instead of leaving it filed under solved.
— Adrian
P.S. The worst outcome here is the box-ticking one, where “we run an AI audit” becomes the new “we got audited” and carries just as little weight. The value lives in a competent person deciding what to point the model at and refusing to trust the first green tick.
Closing Tab.
Watch whether Humanity’s recovery plan actually re-secures the BSC ProxyAdmin the attacker still controls, or whether next week opens with a fresh mint from the same address.
Adrian Hetman Burn Notice Operational intelligence for Web3, every week.