Haruko Breach: What Its Crypto Clients Should Check in 24 Hours

The short answer

Haruko, a crypto trading and portfolio-infrastructure provider connecting institutional clients to more than 100 centralized exchanges and 250+ on-chain protocols, disclosed a breach to clients around September 18, 2026. An attacker exploited a vulnerability in one of Haruko's own processes to pull a user-access token and read data sitting in that process's memory — fifteen clients were affected, and Haruko told clients some funds were lost, without disclosing how much. If your firm routes exchange API keys or trading credentials through Haruko, or through any similar shared trading-infrastructure vendor, the response isn't containment — it's rotation and verification, because the compromise happened somewhere you don't control.

Who this is for

This is for a Head of Security, compliance officer, or trading-operations lead at an institutional crypto firm — a hedge fund, market maker, OTC desk, or asset manager — that connects to exchanges or protocols through a shared third-party trading-infrastructure or portfolio-aggregation vendor, whether that vendor is Haruko or a competitor offering the same kind of multi-venue connectivity. It is not the playbook for an exchange whose own hot-wallet or signing key was compromised directly — see crypto exchange breach response: the first hours for that scenario, which runs on containment and chain tracing you control end to end. It's also not about building ongoing detection for this class of risk — see building a SOC for a crypto exchange from scratch for the subprocessor/supply-chain monitoring layer that would catch anomalous vendor activity before a vendor itself discloses a breach.

What happened

Two independent reports — CoinDesk and CryptoBriefing — agree on the core facts. Haruko runs on bare-metal servers rather than a cloud provider, and an attacker exploited a vulnerability in one of its processes to extract a user-access token, then used that token to read data held in the process's memory — read-only exchange API details and trading data, per CoinDesk's reporting. Fifteen clients were affected. Haruko told clients some funds were lost, without a disclosed amount; CryptoBriefing's framing is that this detail is what turns the incident from "a data exposure" into "a theft." Haruko says it has since fixed the vulnerability, rotated its own server-side secrets, and is recommending clients configure inbound IP whitelisting on their accounts for additional protection. Disclosure so far has been direct client messaging rather than a public advisory.

Several institutional names surfaced in press coverage — Bitcoin Suisse, GSR, Flowdesk, 3iQ Digital Assets, M2, Ampersan, MNNC Group, and Trovio Asset Management — but GSR and 3iQ both stated publicly they were not affected, and the others had not responded by publication. No single confirmed-affected firm or dollar figure is public as of this writing.

Why this doesn't run like your own breach

Dimension	Your exchange's own hot-wallet compromise	Vendor infrastructure breach (this case)
Who controls remediation?	You do — it's your key, your systems	The vendor — you can only act on your side of the connection
What's the first move?	Revoke the signing key or admin session	Rotate every credential the vendor could reach, at every venue
Do you know the full exposure?	Usually yes, once you scope your own logs	Only partially — you depend on the vendor's own investigation for what was actually read
Regulatory notification clock	Runs from when you knew or should have known	Same clock, but starts from vendor disclosure, which may lag the actual breach
Root-cause fix	Yours to implement	Outside your control — you're waiting on the vendor's patch and their word it worked

The practical result: there's no "contain the attacker" step available to a Haruko client, because the attacker was never in the client's own environment. The entire first-24-hours response is defensive verification across every venue the vendor touches — a fundamentally narrower and more anxious position than owning your own containment.

What to do in the first 24 hours if a shared trading-infrastructure vendor is breached

Assume exposure at every venue the vendor connects to, not just the ones you think matter. A vendor with API access to 100+ exchanges on your behalf means the exposure surface is every credential you handed it, not just your primary trading venue.
Rotate every API key and credential the vendor holds, at every connected venue, immediately. Don't wait for the vendor to confirm which specific keys were read — a memory-read exploit against a shared aggregation process is exactly the scenario where the vendor's own account of scope may be incomplete or still under investigation.
Review permission scopes on those keys before reissuing them. If the compromised vendor integration had write or withdrawal permissions it didn't need, this is the moment to cut them down to read-only or whatever the vendor's function actually requires — not just swap the old key for an equally broad new one.
Pull logs from every connected venue for the exposure window and look specifically for API-key-authenticated activity you didn't initiate. The vendor's compromise window is the relevant window, not just the day you were notified.
Enable inbound IP whitelisting on the vendor connection and on the venues themselves, if you haven't already. This is the specific mitigation Haruko itself recommended to clients, and it closes the path a stolen token would otherwise still be usable through.
Document the timeline and your response for internal governance and regulator questions before memory of it fades. A firm that can show it acted within hours of vendor disclosure is in a materially different position than one that can't reconstruct when it found out or what it did.

What an incident-response engagement delivers when the breach isn't yours

Once Incident Response is engaged for a vendor-side breach, the work is scoped differently from a direct compromise: forensic review of exactly what the compromised vendor integration could reach on your side, coordinated credential and API-key rotation across every venue the vendor connects to, log review across those venues for the exposure window, and a written incident record for internal governance or regulator inquiries — assembled fast enough to matter, since the response window here is measured from vendor disclosure, and vendor disclosure timing isn't something a client controls.

Limitations

This isn't a substitute for mapping vendor concentration risk before an incident forces the question — knowing exactly which shared vendors hold credentials to which venues, and what each one's blast radius would be if compromised, is a pre-incident exercise, not something to build for the first time during a live response. It also isn't a statement about Haruko's security practices specifically, or a claim that this incident is worse or better than other vendor breaches — the facts here are limited to what two independent outlets have reported, and several named firms have already denied being affected. If your firm doesn't use Haruko, the value of this post is the response pattern, not the specific vendor.

What to do next

If your firm depends on a shared trading-infrastructure or portfolio-aggregation vendor and doesn't have a rehearsed response for "the breach happened at our vendor, not at us" — get an incident response retainer in place before that gap gets tested by a live disclosure. For the direct-compromise version of this problem, where the credential that was stolen is your own, see crypto exchange breach response: the first hours.

Frequently asked questions

What actually happened in the Haruko breach? Haruko, a London-based crypto trading and portfolio-infrastructure provider that connects institutional clients to over 100 centralized exchanges and 250+ on-chain protocols, disclosed a cyberattack to clients around September 18, 2026. An attacker exploited a vulnerability in one of Haruko's own processes to extract a user-access token and read data held in that process's memory — not a phishing or credential-stuffing attack against the clients themselves. Fifteen clients were affected, and Haruko told clients some funds were lost, without disclosing an amount.

Were any specific exchanges or named firms confirmed to have lost funds? No single firm has publicly confirmed a fund loss as of this writing. Several institutional names were reported in connection with the incident — Bitcoin Suisse, GSR, Flowdesk, 3iQ Digital Assets, M2, Ampersan, MNNC Group, and Trovio Asset Management — but GSR and 3iQ both stated publicly they were not affected, and the rest had not responded to press inquiries at publication time. Treat the list of named firms as "reported in connection with the story," not as a confirmed victim list.

We're not sure if we're a Haruko client, or we use a different trading-infrastructure vendor. Does this still apply to us? The mechanism is the reason to care, not the specific vendor name. Any firm that routes exchange API keys, trading credentials, or portfolio data through a shared third-party infrastructure provider — whether that's Haruko or a competitor — has the same structural exposure: a single compromise at the vendor can expose credentials scoped to every venue that vendor connects to on your behalf. If you use any centralized trading-infrastructure, custody-adjacent, or portfolio-aggregation vendor, the 24-hour checklist above applies regardless of whether Haruko itself is in your stack.

How is this different from a crypto exchange's own hot-wallet compromise? In a hot-wallet compromise, the exchange's own signing key or admin session is the thing that was stolen, and the exchange itself controls containment — revoke the key, freeze withdrawals, trace the chain, the way our crypto exchange breach response covers. In a vendor breach like this one, you don't control the remediation and you don't have full visibility into what the vendor's process actually exposed — you only control your own side of the connection: the API keys and permissions you granted the vendor at every venue it touches. The response is narrower and entirely defensive: assume exposure, rotate, and verify, rather than contain and trace.

What does an incident-response engagement actually do when the breach happened at a vendor, not at us? The scope is different from a direct breach: forensic review of exactly what data and permissions the compromised vendor integration could reach, credential and API-key rotation across every venue connected through that vendor, log review across those venues for any activity in the exposure window, and a written record of the response for internal governance or regulator questions — even though the root cause sits outside your own systems. It also includes a harder structural question most firms skip until this happens: whether the blast radius of that one vendor relationship was ever actually mapped before the breach forced the question.

Sources and review

The Haruko breach facts (disclosure around September 18, 2026; 15 clients affected; bare-metal server infrastructure; the process-memory/access-token exploit mechanism; the named firms mentioned in reporting and GSR's/3iQ's denials of impact; Haruko's remediation and IP-whitelisting recommendation; the more-than-100-exchange, 250+-protocol connectivity scope) are cross-verified against two independent sources: CoinDesk's reporting and CryptoBriefing's reporting. Neither the specific dollar amount lost nor a single confirmed-affected client firm is public in either source, and this post does not speculate beyond what both outlets report. No AnySec-original numbers, case results, or SLA claims are cited. Author: AnySec Engineering. Published 2026-09-20; last reviewed 2026-09-20.