The $320M Liquid Network Hack and the Attack Path Nobody Validated

On September 6, 2026, roughly 4,000 BTC left the wallet backing Blockstream's Liquid Network. That is about 95% of every bitcoin ever pegged into the sidechain, gone in roughly 23 minutes.

No private key was stolen. No signer was phished. No hardware security module was tricked.

The 11-of-15 multisig produced eleven valid signatures, because from where it sat, the withdrawal looked ordinary.

This article covers the attack path, not the news cycle. Specifically, why every control in Liquid's design held while the money still walked out, and what it would have taken to catch a chain like this before an attacker did.

What CodeAnt AI solves here: security programs count findings. The Liquid incident produced almost no findings worth counting and one complete path from a caching bug in consensus code to $320 million in a stranger's wallet. CodeAnt AI builds a threat model across code, dependencies, cloud, infrastructure, and external attack surface, then runs agents that chain weaknesses the way an adversary does, to prove which attack paths actually reach critical data.

Key Facts About the Liquid Network Security Incident

Everything below is as of September 8, 2026. Blockstream has not published a full technical post-mortem.

Root-cause details therefore come from independent analysis of the Elements source and the disputed Liquid blocks.

What Was the Elements Bug Behind the Liquid Network Hack

Liquid uses confidential transactions, which hide amounts while still letting nodes verify that a transaction balances. Range proofs are the cryptography that makes that possible.

Verifying range proofs is expensive, so Elements caches the results. Independent analysis of the Elements source attributes the incident to that cache. The cache key omitted asset and script context. A proof already verified in one context could therefore be reused to validate a different, fresh issuance. The practical effect was inflation. Unbacked L-BTC could be created out of nothing, and a subset of nodes accepted it as valid under consensus rules.

Technical analysis posted to Stacker News notes the caching code dates to the Elements 0.x era, and that every released version at the time of the attack was vulnerable. That analysis also places the bug in shared consensus code rather than Liquid-specific configuration. Other Elements-based sidechains with confidential assets enabled were exposed the same way.

Why No Key Was Compromised and the Money Still Left

This is the part worth slowing down on, because it is the whole lesson. The attacker minted counterfeit L-BTC using the consensus bug. They then sent 4,000 L-BTC to SideSwap's peg-out service, the normal front door for converting L-BTC back to native bitcoin.

SideSwap had no way to distinguish exploit-created coins from real ones, so it treated them identically. The tokens were burned using a valid peg-out authorization, and the federation paid out roughly 3,996 BTC.

Every layer did its job. The multisig verified signatures that were genuine, and the peg-out authorization key was used correctly and was never stolen. The federation's signing infrastructure approved a withdrawal that was valid under the consensus rules as they existed at that moment.

The path went underneath all of it. Counterfeit issuance in consensus code, laundered into legitimacy by the peg-out rail. It was then cashed out through infrastructure that had no reason to object.

There was also no amount or velocity circuit breaker on a single peg-out request sized at 95% of network reserves. That control gap did not create the bug. It converted one exploit into a near-total drain.

The Liquid Attack Path, Step by Step

Before mapping anything to tooling, the path has to be written out as an adversary would have planned it. Five steps, one precondition.

Step 0. The precondition. A fix for the range-proof cache defect was merged to Elements branches around September 1 to 3, 2026. No tagged release contained it.

Every production build in the federation was therefore exploitable, and the fix itself was public on a branch anyone could read.

Step 1. Counterfeit issuance. The cache key omitted asset and script context, so a proof already verified in one context validated a fresh issuance. Unbacked L-BTC came into existence and a subset of nodes accepted it under consensus rules.

Step 2. Laundering through the rail. Roughly 4,000 counterfeit L-BTC went to SideSwap's peg-out service. SideSwap had no mechanism to distinguish exploit-created coins from genuine ones.

Step 3. Authorization. The tokens were burned using a valid peg-out authorization. The peg-out authorization key was used correctly and was never stolen.

Step 4. Signing. The 11-of-15 multisig produced eleven genuine signatures for a withdrawal that was valid under the consensus rules in force at that moment.

Step 5. Exfiltration. Roughly 3,996 BTC moved to an attacker-controlled address, confirmed at 14:28:56 UTC. No amount or velocity ceiling existed on a single peg-out sized at 95% of reserves.

Each step is individually defensible. The chain is not, and no single owner had visibility across all five.

What Is an Attack Path, and Why It Is Not a Vulnerability

A vulnerability is a weakness in a single component. An attack path is the ordered chain of steps that carries an adversary from an entry point to critical data or assets.

Attack path analysis maps those chains across code, identity, cloud, and infrastructure, then determines which are actually traversable in the environment as configured. Liquid is a clean textbook case. Counting vulnerabilities would have produced roughly one item, a caching defect in a validation routine that reads as low severity in isolation.

Mapping the path produces something else entirely. Cache key omits context, so a proof is reusable. Reusable proof permits unbacked issuance. Unbacked issuance is indistinguishable downstream. Downstream is an automated peg-out with no size limit. That peg-out reaches the reserve wallet.

Severity was never a property of the bug. It was a property of the path.

The Patch Existed Five Days Before the Exploit

Here is the detail that should unsettle every engineering leader reading this.

A fix for the cache bug had been merged into the Elements repository, on branches including master, elements-23.x, and elements-23.3.x.

The commits are dated around September 1 to 3, 2026.

The incident happened on September 6.

The fix had not shipped in a tagged release. Verification against the repository showed no release tags containing the relevant commits, and the most recent releases predated them.

So the vulnerability was known. The code fix was written, reviewed, and merged. Every node running a released build was still exploitable, because the last mile of delivery had not happened.

Reporting has also noted that Liquid's functionary codebase, the software federation members run to process peg-ins and peg-outs, had reportedly not been updated in more than two years.

One more wrinkle is worth flagging as unresolved. Bitcoin developer Adam Simecka argued publicly that Blockstream had been patching an older Elements vulnerability in phases.

His claim is that this disclosed where the bug sat before every node applied the fix. He offered no evidence of intent, and Blockstream has not confirmed how the bug was found. Treat it as an open question.

Why Vulnerability Counts Are the Wrong Metric

If your security program reports open findings and mean time to remediate, Liquid would have looked fine on both. The finding was fixed. The remediation clock was running. The reserves still left.

The gap is between fixed in a repository and unreachable in production. Those are different claims, and a closed ticket only ever evidences the first.

Closing a ticket is a statement about a repository. Only a retest is a statement about production.

Are the Liquid Network Hackers Actually White Hat Hackers

A white hat hacker is a security researcher who finds and reports vulnerabilities with authorization, under a responsible disclosure process, without taking assets.

The Liquid actors labelled themselves white hats in an on-chain message reading "we are whitehats. contact us on chain."

Blockstream and Liquid have consistently described them only as purported white-hat hackers. The behaviour genuinely does cut both ways. They opened a channel with Blockstream using PGP-signed Bitcoin OP_RETURN messages and sent encrypted vulnerability details under Blockstream's public key.

They also refused to return funds until every node was patched. Their message read "please fix the bug first. The chain is under risk at latest commit right now."

Ledger CTO Charles Guillemet initially rejected the white-hat framing, arguing that conventional white hats do not drain hundreds of millions from a bridge, and comparing it to Ronin and Euler. He softened after the communication began, on the reasoning that criminal groups rarely try to talk to their victims.

Then they kept roughly $47 million. The distinction that matters legally is authorization, and there was none. Responsible disclosure means telling the maintainer before you touch the asset. Everything after the asset moves is negotiation, however politely it is signed.

Why Periodic Pentests and Code Audits Miss Bugs Like This

Liquid was not an unaudited weekend project. It has run since 2018, the Elements codebase is open source and reviewed, and the federated design was built specifically to survive a compromised member.

Point-in-time assessment fails here for three structural reasons.

Scope boundaries. A penetration test of the peg-out service and an audit of the consensus code are usually separate engagements with separate scopes. The attack path crossed that boundary, and nobody owned the seam.

Severity in isolation. A cache-key defect reviewed on its own reads as a correctness issue. Its real severity only appears when you trace it forward into issuance and then into the peg-out rail.

Time. An annual or quarterly assessment is a photograph. The fix merged on September 1 and the exploit landed on September 6, inside a window no scheduled engagement would have covered.

Continuous penetration testing and automated penetration testing close that third gap. Attack path validation closes the first two, by testing the chain end to end rather than each component against its own checklist.

Attacks Now Run at Machine Speed

Weeks before the incident, Liquid partner Boltz Exchange disabled its swap service and warned that AI-assisted vulnerability probing was outpacing patching.

That warning aged about as well as a warning can.

The asymmetry is structural. An adversary reading a public repository with model assistance can go from merged commit to working exploit in days.

A federated network shipping tagged releases to fifteen independent operators cannot move at that speed.

This is the condition security programs now operate in. Discovery is automated, chaining is automated, and the window between a public fix and a deployed fix is an exploitation window by default.

Defense that runs on a schedule cannot cover a window measured in days.

How Continuous Threat Exposure Management Applies Here

Continuous threat exposure management, or CTEM, is Gartner's five-stage program for prioritizing exposures by business impact rather than raw severity.

The five stages are scoping, discovery, prioritization, validation, and mobilization.

Validation is the stage Liquid needed, and the one that requires actually attempting the chain.

Adversarial exposure validation, sometimes delivered as breach and attack simulation, answers a narrower question than a scanner does.

Map the stages against what happened and the gap is obvious.

Every one of those questions has an answer a human security team could have reached.

The problem is that answering them across an entire system, every day, is not work humans can do at the required cadence.

How CodeAnt AI Would Have Caught This: Modeling and Validating the Liquid Attack Path

One honest caveat first, because the alternative is a claim that falls apart on contact with an engineer. CodeAnt's exploitation playbooks cover web and infrastructure classes: SQL injection, authorization bypass, insecure direct object reference, server-side request forgery, path traversal, OAuth abuse.

Consensus-layer cryptography in a Bitcoin fork is outside that set. What transfers is the method, and the method is where Liquid actually failed. Here is how each stage of CodeAnt's autonomous pentesting pipeline maps onto the five steps above, and what it would have surfaced along the way.

Proximity scoring would have moved the cache defect to the top of the queue

CodeAnt scores every candidate finding before any expensive analysis runs, using deterministic code rather than a model. The score composes four factors: vulnerability weight (the intrinsic severity of the class), target weight (what the affected endpoint is worth, with customer and transaction routes weighted above generic ones), proximity weight (how many hops a finding sits from real data), and reachability multipliers (which boost findings behind authentication and discount hosts that did not respond).

Apply that composition to Liquid. A cache-key omission in a validation routine carries modest vulnerability weight on its own. That is exactly why it read as a correctness issue and shipped as an untagged commit. Its target weight is the issuance path. Its proximity weight is zero hops from the reserve wallet. Scored as a component, it is a low-severity defect. Scored by proximity, it outranks everything else in the queue. That inversion is the entire argument.

Severity was a property of the path, and the scoring model is where a program either sees it or does not.

A live CodeAnt engagement queue, ranked by proximity to data rather than raw CVSS. The same scoring logic is what would have pulled a "low-severity" caching bug in Elements to the top of the list.

Chain-first extraction is how a five-step path gets found

CodeAnt's deep-dive extraction phase runs a finding-agnostic agent against every finding above the deep-dive threshold, and its priority order is explicit: chain first. If a prior step produced credentials, internal URLs, identifiers, or session tokens, use them to reach data through other findings.

The documented reason is that the highest-impact leaks are almost always multi-step chains. Liquid is that sentence rendered in Bitcoin. Counterfeit issuance was worthless in isolation. It became $320 million only when carried through the peg-out rail into the federation wallet.

That is three findings' worth of surface, owned by three different parties: the consensus code, the peg-out service, and the federation signing path. A phase that only confirms findings one at a time never assembles that. A phase whose first instruction is to chain does.

The deep-dive threshold also sits deliberately lower than the exploitation threshold, so findings the primary queue skipped get a second pass. A low-scored cache defect is precisely the kind of item that survives on the second pass and dies on the first.

This is the same chaining pattern that carried counterfeit L-BTC through SideSwap's peg-out rail: one weak link, laundered through a system that had no reason to distrust it, into full impact.

The always-on layer is where merged-versus-shipped gets caught

The five days between merge and exploit are the cleanest failure in the whole incident, and they are a monitoring problem rather than a code problem.

CodeAnt's attack surface management layer runs continuously across more than thirty data sources, including the National Vulnerability Database, the CISA Known Exploited Vulnerabilities catalog, and EPSS exploit-prediction scoring. The relevant property is the cadence rather than the source count. The layer runs every day rather than on a scan schedule.

So the question "what version is production running against what fixes now exist" has a fresh answer each morning. CVSS answers how bad a flaw is in theory. EPSS answers how likely it is to be exploited in the wild.

A publicly merged, publicly readable, unreleased consensus fix is about as high as that second number goes. Liquid's functionary codebase had reportedly not been updated in more than two years. That is a fact a continuous layer surfaces on day one and a quarterly assessment surfaces never.

CVSS and EPSS side by side on a live target. A fix merged but not tagged for release is exactly the kind of gap this view is built to surface before an attacker finds it first.

Proof of impact is what separates a closed ticket from a safe system

The distinction CodeAnt is built around is that a detected vulnerability is not a confirmed leak, and the deliverable is the extracted evidence rather than the finding list.

Liquid had the first half. The bug was found, a fix was written, reviewed, and merged, and by any dashboard the item was closed.

Nobody produced the second half. Nobody demonstrated that counterfeit L-BTC could be minted and redeemed end to end while released builds were still vulnerable. Had someone run that chain in a test environment, the output would have been a reproduction script and a working exploit. Nobody ships an untagged fix once that artifact exists on disk.

That is the difference between a repository claim and a production claim, and it is the only version of "done" worth reporting to a board.

A "closed" finding and a "proven unreachable" finding look identical on most dashboards. This view is built to keep them from being treated the same.

The cadence argument

A full CodeAnt AI penetration testing engagement runs in roughly thirty to ninety minutes of wall-clock time, which makes per-release testing viable rather than aspirational. Set that against the timeline. Fix merged September 1 to 3. Exploit executed September 6. Reserves gone in 23 minutes.

Liquid partner Boltz Exchange had already warned that AI-assisted vulnerability probing was outpacing patching. A quarterly engagement does not intersect a five-day window. An annual one is not in the same conversation.

What CodeAnt tracks that maps to attack paths

The pipeline grades itself after every engagement, and three of those axes are attack-path metrics rather than finding metrics.

A program measuring open findings and mean time to remediate would have rated Liquid healthy on September 5. A program measuring chain depth and time-to-first-critical would have had an unanswered question sitting in the queue.

For the full phase-by-phase breakdown of how an engagement runs, from reconnaissance through scoring, exploitation, and the two-PDF deliverable, see how CodeAnt's autonomous pentesting pipeline works, step by step.

The track record on finding what gets missed

CodeAnt processes roughly 15 billion security events every month across code, cloud, infrastructure, and external attack surfaces. A new attack path discovered in one customer strengthens every customer's defense, which is what keeps the model improving rather than drifting.

The discovery record is public. CodeAnt has found 150+ CVEs, including a CVSS 10.0 vulnerability in pac4j that went undetected for six years, across projects representing 2B+ monthly downloads protected.

A six-year-old critical flaw in a widely used security library is the same shape of problem as an Elements-0.x-era cache bug. Both sat in reviewed, open-source, heavily depended-on code. Neither was going to be found by looking harder at the component.

The Attack Path Validation Checklist

Run this against your own stack this week. It is written to be answerable, not aspirational.

Delivery and patch integrity

• Merged versus shipped: for every security fix merged in the last 90 days, confirm which tagged release contains it and which environments run that release.

• Unreleased fixes: list security commits currently on a branch with no release tag. Every one is a public exploitation window.

• Dependency staleness: identify any service whose codebase has not been updated in over 12 months and that sits on a path to critical assets.

Path mapping

• Seam ownership: name the owner for each boundary between two separately scoped systems. Unowned seams are where paths hide.

• Downstream trust: for each automated rail accepting input from another internal system, document what it validates independently versus what it trusts.

• Reachability: for your top ten open findings, state whether each has a traversable path to critical data. If you cannot answer, that is the finding.

Blast-radius controls

• Velocity limits: confirm that no single automated operation can move more than a defined percentage of a critical asset pool without a second control.

• Anomaly halt: verify you can pause the affected component within minutes, the way Liquid disabled bridge nodes.

• Divergence monitoring: where multiple nodes or services must agree, alert on disagreement. A Liquid explorer node on an older build rejected the malicious transaction and diverged, which was a live signal.

Validation cadence

• Retest after fix: require a proven-unreachable retest before any path-carrying finding is closed.

• Continuous coverage: measure the longest gap between assessments on any critical path, then compare it to how fast a public commit becomes an exploit.

Where This Leaves You

The Liquid Network hack will get filed as a crypto story. It should be filed as an attack path story. A caching defect in shared consensus code, a fix written but not shipped, an automated rail that could not tell counterfeit from genuine, and no ceiling on a single withdrawal.

Individually, four unremarkable items. Chained, 95% of a network's reserves in 23 minutes. The question worth asking is not how many findings are open. It is which chains in your environment currently reach the data you cannot afford to lose, and when you last proved they do not.

For more on validating exploitability rather than counting findings, see our guide to AI penetration testing, or explore CodeAnt AI's pentesting platform directly.

Sources

• Amartya Jha, Co-founder: CodeAnt AI, Someone just stole $320 million to file a bug report.

• The Cyber Express, Liquid Network Hackers Demand Bug Fix Before Returning $320M BTC, September 7, 2026

• The Block, Liquid Network attacker says they will return most of 4,000 BTC after bug fix, September 7, 2026

• CoinDesk, $320 million bitcoin exploit hits Liquid Network, September 7, 2026

• Blockhead, Liquid Network Attacker Returns 85% of Stolen $320 Million in Bitcoin, September 8, 2026

• Stacker News, technical analysis of the Elements rangeproof cache bug and affected release tags

• The Crypto Times, Liquid Network Lost 4,000 BTC From Its Federation Wallet, September 7, 2026

• ETHNews, Liquid Network Exploit Drains $320M, Blockstream Halts Sidechain, September 7, 2026