Q3 2026 crypto losses: $1.27 billion, two incidents, and a security product as the way in.

What is confirmed

CertiK, a blockchain security firm, keeps a running tally of crypto-asset security incidents on its Security Dashboard. On 3 October 2026, it showed these figures for July to September 2026 (Q3). CertiK Security Dashboard.

Summary card: the headline $1.27B lost in Q3, two incidents: 56%, beside bars for CertiK's Q3 2026 gross losses: Bitget $387.5M (30.5%), Liquid Network $318.7M (25.1%) and 246 other incidents about $564M (44.4%), with adjusted losses of $869.6M

At a glance. Original graphic for this article.

Gross losses: $1.27 billion, up 54.4% from $819.4 million in Q2. At ¥157.4 to the dollar, the rate NADA NEWS used, that is about ¥200 billion.
Adjusted losses: $869.6 million, up 10.0% from $790.7 million. The adjusted figure deducts funds that were returned or recovered.
Incidents: 248, up 13.2% from 219. NADA NEWS reported 249 from the dashboard's 2 October update. NADA NEWS (Japanese).
September: $772.4 million, about 61% of the quarter. Exploits made up $739.5 million of that, or 95.7%.
Largest incident: Bitget, $387.5 million, about 30% of the quarter. The second largest was Liquid Network, at $318.7 million.

Together, Bitget and Liquid account for about 56% of the quarter's gross losses and about 91% of September's.

Bar chart. Q2 2026: gross losses $819.4M, adjusted $790.7M. Q3 2026: gross $1.27B, adjusted $869.6M. Gross rose 54.4% and adjusted 10.0%. A bracket marks the Q3 gap of about $400M, which includes about $272M of bitcoin returned to Liquid, according to TRM Labs. A side panel shows incidents rising from 219 to 248, up 13.2%, with a note that the 2 October update cited by NADA NEWS showed 249.

Figure 1. Gross losses rose 54%; after returned funds, 10%. Original graphic for this article.

Bitget: an intrusion through two security products

Bitget is a centralised cryptocurrency exchange. It says its security system detected unauthorised transfers from some hot and warm wallets at 18:31 UTC on 24 September 2026. Bitget incident page. Its incident page, last updated on 30 September, states:

Scope. About $388 million left 12 wallet addresses, all hot or warm wallets. Private keys were not compromised, and the cold wallets that hold most assets were not affected.
Method. The attacker exploited a vulnerability in a third-party security product to steal internal network credentials. It then wrote forged withdrawal commands into the wallet system, which processed them as normal withdrawals and bypassed risk checks.
No common malware. Bitget says the attacker used legitimate identities and routine operational procedures rather than common viruses or malware, and deleted traces afterwards.
Remediation. The vulnerability is fixed. All internal credentials were reset and access to highly sensitive permissions tightened. The vendor was notified and the relevant features disabled. Independent withdrawal verification was strengthened.
Customers. The loss is covered by Bitget's Protection Fund, which it says holds 5,500 BTC, worth over $464 million. Withdrawals resumed in phases from 28 September, with the remaining assets scheduled for 2 October.

SlowMist, which is investigating with Mandiant, published a progress report on 29 September. SlowMist report (PDF). It calls the two products Product A and Product B and gives times in UTC+8. In UTC:

From 31 August (UTC+8). A zero-day affected a service on one of Product A's nodes. The attacker ran a hidden script under the service process, read the environment variable that held a database password, and connected to the database. The same activity appeared on two more nodes on 23 and 25 September.
From 16:07 UTC on 24 September. The attacker accessed Product B's management platform using an internal employee's identity. It made three attempts to inject system commands through task parameters. It then submitted code through the platform's web execution endpoint to change server configuration, write a communication relay file and upload malicious program files. GIGAZINE, citing Mandiant's findings, reports a web shell and a channel to an external command server. GIGAZINE (Japanese).
17:49 UTC. A withdrawal tool built around the wallet system's own withdrawal logic started on a wallet application host. It forged risk-control parameters in its code, built withdrawal requests and called the withdrawal process.
18:31 to 21:23 UTC. Transfers to the attacker across several chains, over about 2 hours 52 minutes.
After 21:22 UTC. The attacker tried to edit withdrawal records directly in the wallet database. Two fabricated BTC withdrawals entered processing and failed. SlowMist recovered the withdrawal tool from files the attacker had deleted.

SlowMist says it is still investigating how the attacker moved between the systems.

Figure 2. From a security product to the hot wallets. Stages from SlowMist and Bitget; the controls are this article's analysis. Original graphic.

Liquid Network: a validation bug, and 85% returned

Liquid is a Bitcoin sidechain developed by Blockstream. Bitcoin locked in its reserve backs a token, L-BTC, that circulates on the sidechain. On 6 September 2026, attackers used a bug in Liquid's transaction-validation software to create L-BTC with nothing behind it, then exchanged it for real bitcoin. Roughly 4,000 of the 4,200 or so BTC in the reserve was withdrawn, worth about $319 million. TRM Labs.

Chainalysis describes the flaw as a problem with how cached checks were identified: new data could be mistaken for data that had already been approved. Chainalysis. The attackers called themselves white hats. On 7 September they returned about 3,400 BTC, about 85% or $272 million. Roughly 600 BTC, about $47 million, was still with them at Chainalysis's update of 9 September. Blockstream deployed updated software.

What changes in the security review

Read the quarter by incident, not by its total

Editorial assessment. Crypto losses are dominated by a few very large incidents, and this quarter shows it. Two incidents set the headline. Liquid's returned bitcoin alone accounts for about $272 million of the roughly $400 million gap between gross and adjusted losses. On the adjusted figure, Q3 was 10% worse than Q2, not 54%. The 246 other incidents add up to about $564 million.

If you report these figures to a board or risk committee:

Show the largest incidents separately, then the rest. One incident can move a quarter by tens of percent.
Say which figure you use, gross or adjusted, and keep to it across quarters.
Date the number. The dashboard is live: 249 incidents on 2 October, 248 on 3 October.
Do not let category labels set your threat model. CertiK files both Bitget and Liquid under "Exploit". One was a network intrusion into an exchange, the other a software bug in a sidechain. They call for different defences.

The long tail matters too. By count, September also had 13 phishing incidents, 11 private key compromises and 7 wallet compromises. For an organisation that holds crypto in its own wallets, those are more likely than a protocol bug.

Figure 3. September was 61% of the quarter, and two incidents were 91% of September. Figures from CertiK's dashboard on 3 October 2026. Original graphic.

A security product was the first foothold

Editorial assessment. Both systems the attacker used before reaching the wallets were security products. That should not surprise anyone. Security products run with broad privileges and see much of the network. They are often appliances or vendor-managed nodes where you cannot install your own EDR. And their management consoles are built to send tasks to other machines, which makes them remote execution by design.

Check four things:

Tier them. List the nodes and management platforms of every security product you run. Protect them like domain controllers: administration only from dedicated admin workstations, separate admin accounts, phishing-resistant MFA.
Know what each console can run. Find every script, command and task feature. Disable the ones you do not use, require approval for the rest, and alert on every use.
Get the logs out. Console sign-ins, task runs and configuration changes should reach your SIEM and be kept long enough. SlowMist dates the earliest activity it found in the available logs to 31 August. The real start may be earlier.
Plan for a zero-day you cannot patch yourself. Ask each vendor how it would warn you and what you could switch off in the meantime. Segment the product's nodes so that a compromise cannot reach databases it does not need.

An environment variable is not a vault

Editorial assessment. The step from Product A to the database needed one command: read an environment variable. On Linux, a process's environment can be read by the same user and by root through /proc/<pid>/environ. Every child process inherits it, including a script that an exploit starts under the service.

Fetch secrets at run time from a secret manager, scoped to the service. Prefer short-lived database credentials, or workload identity where the platform supports it. Code running as the service can still fetch the secret, but the stolen credential expires and every fetch is logged.
Restrict the database by network and by account. A service account should connect only from its own service's hosts. Alert on any other source.
Find out where secrets sit today. The shell check below lists the names, not the values, of secret-like environment variables on a host.

Risk checks the attacker could forge

Editorial assessment. Bitget's withdrawal tool forged the risk-control parameters in its own code. In other words, the record that a withdrawal had passed its risk checks came from the caller, and the wallet process accepted it. Any control that runs on, or trusts input from, the host that builds the request can be bypassed by code on that host.

The fix Bitget names, independent withdrawal verification, applies to any system that moves money: ERP payment runs, bank payment files, treasury platforms. Payments and treasury teams should check three things:

Approval is verified where the requester cannot reach. The signer or payment gateway checks each request against the approval system of record, not against flags inside the request.
Only a small balance is exposed. Bitget's cold wallets were untouched, so the loss was limited to what the hot and warm wallets held.
Outflows are reconciled continuously. Each outflow is matched to an approved request, and an unmatched one pages someone within minutes. On SlowMist's records, transfers ran for almost three hours after the first one.

"No malware" is not "no tooling"

Editorial assessment. Bitget says the attacker used no common viruses or malware. Its investigators still describe hidden scripts, a relay file, uploaded program files and a withdrawal tool built for Bitget's systems. For EDR teams, that is not reassuring: none of it would match a known signature. Detection has to come from behaviour, such as a service process starting a shell, a console account running its first command task, or a database account connecting from a new host. It also has to come from business logic, such as a withdrawal with no matching approval.

Liquid: a reserve in one place, and a cached approval

Editorial assessment. Liquid's reserve held almost all of the bitcoin behind L-BTC, so one validation bug exposed nearly all of it. TRM Labs makes the same point. If your organisation holds or accepts bridged or wrapped assets, know which ones are claims on a reserve, who operates that reserve, and how it could fail.

For engineers, the caching flaw is a general lesson. A cached "already approved" decision must be tied to exactly the data that was approved. Otherwise new data can pass as old.

After the incident: recovery scams

Bitget warns that it will never ask users to transfer funds, or to disclose passwords, private keys, seed phrases or verification codes, in the name of asset recovery or resuming withdrawals. Expect lures built on both incidents, aimed at customers and at anyone whose staff trade crypto.

Which teams should act

Team	Practical next step
EDR	List the nodes of every security product you run. Where an agent can run, alert on shells, downloaders and environment reads started by their service processes. Where it cannot, require log export.
SIEM / SOC	Collect console sign-ins, task runs and configuration changes from security products. Alert on any command or script task, on new user and IP pairs, and on database service accounts connecting from new hosts.
IT operations	Move service secrets out of environment variables into a secret manager with short-lived credentials. Restrict databases to the hosts that need them. Disable unused remote-execution features on management consoles.
Third-party risk	Ask security vendors how their management plane is protected, what it can run on your hosts, and which logs you can export. Ask exchanges and custodians you use about hot-wallet limits and independent withdrawal checks.
Email security	Expect "asset recovery" and "withdrawal resumption" lures naming Bitget or Liquid. Bitget says it never asks for passwords, private keys, seed phrases or codes.

IOCs and hunting

Bitget has published four attacker-controlled addresses. They are on-chain indicators: useful to exchanges, payment processors and compliance teams screening deposits and withdrawals, not for endpoint hunting. Bitget also runs a live tracking dashboard and offers a bounty of 5% of any frozen or recovered amount.

Chain	Attacker-controlled address (published by Bitget)
EVM	`0x770b10b273fc44fe9197d6bf20f145c2e98463ee`
XRP Ledger	`rwNhefsz1UQEusxhCvHip3RANinWi4CTck`
Zcash	`t1WgMdtND8NF7NDUuYmq8MpMj1NTCXkMDVG`
TRON	`TBWNguTTgezw9dVorX441C6nDrZpRxYwKD`

Neither Bitget nor its investigators has named Product A or Product B, the vulnerability, or any host indicators. None should be inferred.

The useful hunts are for the techniques. All are illustrative and were not run against live data. Replace the YOUR_ placeholders with your own names, and adjust field names to your data sources.

Shells, environment reads and downloaders started by service processes on security product nodes that run Microsoft Defender for Endpoint:

// Illustrative. Microsoft Defender XDR advanced hunting, DeviceProcessEvents (Linux devices with Defender for Endpoint).
// Shells, environment reads and downloaders started by long-running service processes on the hosts you list.
let ServiceHosts = dynamic(["YOUR_SECURITY_PRODUCT_NODE_1", "YOUR_SECURITY_PRODUCT_NODE_2"]);
DeviceProcessEvents
| where Timestamp > ago(30d)
| where DeviceName in~ (ServiceHosts)
| where InitiatingProcessFileName in~ ("java", "node", "python", "python3", "php-fpm", "nginx", "httpd")
| where FileName in~ ("sh", "bash", "dash", "env", "printenv", "curl", "wget", "base64")
    or ProcessCommandLine has "/environ"
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName,
    InitiatingProcessCommandLine, FileName, ProcessCommandLine
| order by Timestamp asc

Sign-ins to a security product console from a user and IP address pair not seen before, where the console signs in through Microsoft Entra ID:

// Illustrative. Microsoft Sentinel, SigninLogs, for a security product console that signs in through Entra ID.
// Successful sign-ins in the last 7 days from a user and IP address pair not seen in the 30 days before.
let Console = "YOUR_SECURITY_CONSOLE_APP";
let Known = SigninLogs
    | where TimeGenerated between (ago(37d) .. ago(7d))
    | where AppDisplayName == Console and ResultType == "0"
    | distinct UserPrincipalName, IPAddress;
SigninLogs
| where TimeGenerated > ago(7d)
| where AppDisplayName == Console and ResultType == "0"
| join kind=leftanti Known on UserPrincipalName, IPAddress
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AuthenticationRequirement
| order by TimeGenerated asc

A database service account connecting from a host outside its expected list, from database audit logs in Splunk. The lookup holds the expected source addresses:

index=YOUR_DB_AUDIT_INDEX user="YOUR_SERVICE_DB_USER" action=connect earliest=-30d latest=now
| stats count min(_time) AS first_seen max(_time) AS last_seen BY src
| lookup YOUR_EXPECTED_DB_SOURCES src OUTPUT expected
| where isnull(expected)
| convert ctime(first_seen) ctime(last_seen)
| sort first_seen

Withdrawals broadcast without a matching approval. This only works if the approval log comes from a system the wallet host cannot write to:

(index=YOUR_WALLET_INDEX sourcetype=YOUR_WALLET_BROADCAST) OR (index=YOUR_APPROVAL_INDEX sourcetype=YOUR_APPROVAL_LOG status=approved) earliest=-24h latest=now
| eval kind=if(sourcetype=="YOUR_WALLET_BROADCAST", "broadcast", "approved")
| stats values(kind) AS kinds min(_time) AS first_seen values(host) AS host values(asset) AS asset BY withdrawal_id
| where isnotnull(mvfind(kinds, "^broadcast$")) AND isnull(mvfind(kinds, "^approved$"))
| convert ctime(first_seen)
| sort first_seen

On a Linux host you own, find which processes hold secret-like environment variables. It prints names only, never values:

# Illustrative. Run as root on a Linux service host you own.
# Prints each process ID and name with the NAMES (not values) of environment variables that look like secrets.
for f in /proc/[0-9]*/environ; do
  d=${f%/environ}
  names=$(tr '\0' '\n' < "$f" 2>/dev/null | cut -d= -f1 | grep -E 'PASS|SECRET|TOKEN|KEY' | sort -u | tr '\n' ' ')
  [ -n "$names" ] && echo "${d#/proc/} $(cat "$d/comm" 2>/dev/null): $names"
done

Read the results with these limits in mind:

Some products start shells as part of normal work, for health checks or updates. Build a baseline before alerting.
A new user and IP pair is a lead, not proof. Bitget's attacker used a real employee's identity, so check with the person.
Also compare on-chain outflows from your hot wallets with the wallet's own broadcast log. An outflow that appears in neither log is the worst case.
None of these sees inside a vendor-managed appliance that does not export logs.

What remains unknown

Product A, Product B and the vulnerability. Not named. Bitget says a formal security report with more technical detail will follow.
How the attacker moved between systems, including how it obtained the employee identity used on Product B. SlowMist is still investigating.
Detection and containment. SlowMist's transfer records span about 2 hours 52 minutes. Bitget has not explained how that window relates to its response.
Who did it. Neither Bitget nor its investigators has attributed the attack. Bitget lists Bybit's LazarusBounty programme as a recovery channel; that is not an attribution.
How much has been frozen or recovered from the Bitget theft. Bitget points to its live tracking dashboard rather than publishing a figure.
Liquid. Who the attackers were, and whether the remaining 600 or so BTC will come back.
CertiK's adjustments. The dashboard does not itemise what is deducted to reach the adjusted figure.

Reporting note

Reviewed for public information up to 3 October 2026, 12:55 UTC / 21:55 JST. Quarterly figures come from CertiK's Security Dashboard as shown on 3 October 2026; they will change as the dashboard is revised. NADA NEWS's report of 3 October was the prompt for this article; it used the 2 October update and a rate of ¥157.4 to the dollar. Bitget facts come from its incident page and from SlowMist's progress report of 29 September; GIGAZINE's article was used for Mandiant's findings. Liquid facts come from TRM Labs and Chainalysis.

This is independent editorial analysis of public statements, not an investigation by SecOpsNomad, and nothing here is investment advice.