A vendor almost nobody outside institutional trading desks had heard of a week ago is now the center of a live case study in third-party crypto risk. Haruko, a London-based technology provider that plugs hedge funds and asset managers into exchanges, custodians and blockchains, disclosed on September 18, 2026, that attackers had broken into its systems and pulled data tied to 15 clients. Some of those clients, according to CoinDesk’s reporting, lost actual funds.
The breach itself is small by crypto standards. No headline nine-figure number, no drained smart contract, no exchange going dark. But the mechanics matter more than the size. Haruko wasn’t holding customer coins the way an exchange does. It was the plumbing: the software that lets a fund’s dashboard talk to Binance, Coinbase, or a dozen other venues at once. When that plumbing sprang a leak, the exposure spread across every client who hadn’t locked their pipes down. That’s the story institutional crypto has been trying to avoid since Prime Trust folded in 2023, and it’s why this Haruko cyberattack is drawing outsized attention from a market that has spent the past year absorbing hard lessons on crypto wallet security from a very different corner of the industry.
What Happened: Inside the Haruko Cyberattack
Haruko sells what it calls a consolidated view of institutional crypto activity: portfolio tracking, risk management and trade-data infrastructure that connects to exchanges, custodians, blockchains and DeFi protocols. According to its own website, the firm links more than 80 clients to over 100 centralized trading venues, 30 blockchains and 250 onchain protocols. That scale is exactly what made the incident worth watching. One compromised vendor, many exposed accounts.
Reporting from CoinDesk, based on messages reviewed from Haruko co-founder and CTO Adam Carlile, says the breach exposed clients’ read-only exchange API details and trading data. APIs are how Haruko’s servers and a client’s exchange accounts exchange information without a human logging in each time. Carlile told affected clients directly: “This was a targeted attack by a group on us.” He added a specific count: “It was 15 clients impacted.”
Those 15 were, per the CoinDesk account, all of Haruko’s non-whitelisted clients — accounts that hadn’t set up inbound IP whitelisting, the security control that limits which computers are allowed to talk to a given API key. Clients who had already locked their access down to specific IP addresses were untouched. That single fact turned a company-wide breach into a two-tier outcome: some funds walked away clean, others didn’t.
How the Attack Worked: A Token Pulled From Memory
The technical detail that separates this from a generic phishing story is where the attacker actually got in. Per Carlile’s account to clients, the attacker exploited a vulnerability in one of Haruko’s own processes and extracted a user-access token directly from that process’s memory. From there, they could read whatever data sat in memory alongside it, including read-only exchange API details.
That’s a server-side compromise, not a credential-stuffing attack against individual clients. Login credentials clients used inside their own environments were reportedly untouched. The hole was in Haruko’s infrastructure, not in any one customer’s password hygiene. One person familiar with the incident told CoinDesk the breach was possible in part because Haruko runs bare-metal servers, physical machines dedicated to the company, rather than a cloud platform such as Amazon Web Services, which bundles in additional network-level security controls by default.
Haruko says it has since fixed the exploited vulnerability and rotated its server-side secrets. It also told clients that turning on an inbound IP whitelist would deliver, in the company’s words relayed to customers, “maximum protection.” A fuller technical post-mortem is reportedly still coming.
Who Got Hit, and Who Says They Didn’t
Haruko doesn’t publish a full client roster, but its marketing site names Bitcoin Suisse, GSR, Flowdesk, 3iQ Digital Assets, M2, Ampersan, MNNC Group (now rebranded as Monarq Asset Management) and Trovio Asset Management as customers. None of that confirms which 15 accounts were actually affected, and two firms moved fast to say it wasn’t them.
A GSR spokesperson told CoinDesk: “GSR has not been impacted by any rumored breach.” 3iQ went further, with a representative saying: “3iQ was not affected by this breach. Our funds remain fully secure, and our API access is restricted through IP whitelisting, preventing any exposure to the compromised environment.” Bitcoin Suisse, Flowdesk, M2, Ampersan, Monarq and Trovio did not respond to requests for comment before CoinDesk’s story published.
Haruko itself did not respond to repeated requests for comment, according to the same report. That silence, paired with named clients rushing to deny exposure, is its own signal. Whitelisting is now a line firms want on record, publicly, within hours of a vendor breach.
Why “Read-Only” API Access Still Creates Risk
Read-only sounds safe. It isn’t, not entirely. A read-only key can’t place a trade or move funds on its own, but it can hand an attacker a live map of a fund’s positions, counterparties, order flow and exchange relationships. For a market-making or arbitrage desk, that’s proprietary strategy data walking out the door. Trading data was reportedly taken alongside the API details in this breach, according to CoinDesk’s sourcing.
There’s a second layer of risk engineers in this space have flagged for years: permission scope creep. Keys get issued as read-only, then get quietly upgraded, or sit next to trading keys in the same account without anyone re-auditing them. The OWASP API Security Top 10 lists broken object-level authorization and excessive data exposure as two of the most common ways API breaches turn into financial losses, and both map cleanly onto what happened at Haruko. A key configuration engineers might sketch for a hardened institutional setup looks like this:
{
"key_id": "trading-desk-04",
"permissions": {
"read": true,
"trade": false,
"withdraw": false
},
"ip_whitelist": ["203.0.113.10", "203.0.113.11"],
"rotation_days": 30,
"alert_on_new_ip": true
}Every field in that example maps to a control Haruko’s non-whitelisted clients were missing on September 18: no IP restriction, and no forced rotation cadence that would have expired the exposed token before it could be misused.
The Numbers: 2026 Is Already a Record Year for Crypto Attacks
The Haruko cyberattack didn’t happen in a quiet year. Blockchain intelligence firm TRM Labs reported a record 207 attacks on crypto companies in the first half of 2026, more than double the 83 recorded in the same period a year earlier. Total losses across those incidents hit $972 million, based on TRM’s figures.
The detail that makes Haruko relevant rather than incidental: infrastructure and operational compromises accounted for roughly 76% of the money stolen in H1 2026 despite representing only about 15% of total incidents, per TRM’s breakdown. Attacks aren’t getting more frequent at the infrastructure layer. They’re getting more expensive when they land there. Security firm CertiK, using a broader methodology that folds in phishing and scams alongside hacks, put first-half 2026 losses at roughly $1.32 billion across 344 incidents, a wider net that still points the same direction: money is following the weakest link in the chain, and vendors sit right at that link. That trend lines up with what our own reporting found when crypto hacks hit a record 50 incidents in August 2026, and with the broader shift toward stolen keys overtaking code bugs as the leading cause of DeFi losses this year.
H1 2026 Crypto Attack Data at a Glance
| Metric | H1 2026 | H1 2025 | Source |
|---|---|---|---|
| Total attacks on crypto companies | 207 | 83 | TRM Labs |
| Total losses (TRM methodology) | $972 million | Lower, not itemized | TRM Labs |
| Share of dollars lost to infrastructure/operational compromise | ~76% | Not published | TRM Labs |
| Share of incidents that were infrastructure/operational | ~15% | Not published | TRM Labs |
| Total losses (broader methodology incl. scams/phishing) | $1.32 billion / 344 incidents | Not published | CertiK |
| Haruko clients affected | 15 | n/a | CoinDesk |
Historical Context: How Haruko Compares to Crypto’s Biggest Hacks
Crypto has a long memory for nine- and ten-figure losses, and Haruko doesn’t come close to that list on dollar terms. What makes it worth studying is the category it falls into: a compromise of the connective tissue between institutions and markets, rather than a direct hit on an exchange’s hot wallet or a bridge’s smart contract.
Mt. Gox, in February 2014, lost roughly $460 million in bitcoin and triggered the industry’s first true systemic crisis. Bitfinex lost about $72 million in August 2016. Coincheck’s January 2018 breach cost around $530 million. Poly Network’s cross-chain exploit in August 2021 drained about $610 million, most of which the attacker later returned. Ronin Network’s bridge hack in March 2022 cost Axie Infinity’s ecosystem roughly $625 million. FTX’s November 2022 collapse left an estimated $8 billion hole in customer funds, though that was a governance and custody failure rather than an external hack. Bybit’s February 2025 breach, the largest crypto theft on record, ran to roughly $1.5 billion, a shock that pushed much of the industry toward the multisig hardening now standard at serious custodians.
Haruko sits at the opposite end of that scale in dollar terms, and in a different lane entirely in mechanism. It’s not an exchange losing custody of coins. It’s a vendor losing control of the credentials that connect clients to their own exchange accounts.
Major Crypto Hacks and Breaches, 2014-2026
| Incident | Date | Approx. loss | Attack type |
|---|---|---|---|
| Mt. Gox | February 2014 | ~$460 million | Exchange hot wallet |
| Bitfinex | August 2016 | ~$72 million | Exchange hack |
| Coincheck | January 2018 | ~$530 million | Exchange hot wallet |
| Poly Network | August 2021 | ~$610 million | Cross-chain bridge exploit |
| Ronin Network | March 2022 | ~$625 million | Bridge validator compromise |
| FTX | November 2022 | ~$8 billion shortfall | Custodial collapse, not a hack |
| Bybit | February 2025 | ~$1.5 billion | Cold wallet transfer compromise |
| Haruko | September 2026 | Undisclosed, described as small | Vendor/infrastructure token theft |
Market Impact: What This Means for Institutional Crypto Adoption
Institutional money has spent the past two years moving into crypto through exactly the kind of middleware Haruko sells. Funds don’t want to build direct integrations with a dozen exchanges and custodians themselves, so they buy a platform that does it for them. That trade-off, speed of integration for concentrated risk, is now under a microscope.
The immediate market impact is procedural rather than price-driven. No token cratered because of this news, and no exchange saw a run on withdrawals. What moved instead were compliance checklists. Institutional allocators who read the CoinDesk report now have a very specific question to put to any vendor pitching them a unified view of their crypto positions: is access IP-whitelisted by default, or opt-in? Haruko’s own admission that whitelisting delivers “maximum protection” implies it wasn’t the default state for every client, and that’s the detail compliance teams will chase hardest in the coming weeks.
Expect this to show up in due-diligence questionnaires before it shows up in any regulatory filing. Institutional crypto vendors that can point to default-on IP restrictions, mandatory key rotation and cloud-hosted infrastructure with provider-level DDoS and network controls have a new sales pitch, whether or not they intended one. It’s the same instinct that drove funds to demand independent reserve checks after the Tether KPMG audit earlier this year: trust a vendor’s security claims less, and verify more.
The Vendor Risk Problem Nobody’s Pricing In
Crypto’s security conversation for most of the past decade has focused on two things: exchange custody and smart-contract audits. Both matter, and both have gotten meaningfully better. What hasn’t kept pace is scrutiny of the middleware layer that institutional traders now depend on daily. A fund can run a flawless internal security program, enforce hardware-key logins for every employee, and still get exposed because a vendor three steps removed from its balance sheet got popped.
This fits a pattern our cryptocurrency coverage keeps circling back to: the weak point in digital-asset security has moved from the blockchain itself to the software wrapped around it. That’s structurally similar to problems the traditional software industry has wrestled with for years around SaaS vendor risk, just compressed into a market where the assets are bearer instruments and transactions can’t be reversed. A stolen SaaS API key at a normal company usually means a data leak. A stolen crypto API key, even a read-only one, can be a map straight to the assets themselves once an attacker cross-references it with other leaked data. Chainalysis has tracked this shift toward operational and infrastructure targeting across its annual crime reporting for several years running.
Contracts between funds and infrastructure vendors are the next likely pressure point. Expect institutional clients to start demanding breach-notification clauses with fixed timelines, mandatory third-party penetration testing, and audit rights, the same terms that became standard in enterprise SaaS deals after a decade of vendor breaches on that side of the industry.
Competitive Landscape: How Custody and Infrastructure Rivals Stack Up
Haruko occupies a specific niche: portfolio, risk and connectivity software rather than asset custody itself. That distinguishes it from custody-first players like Fireblocks, Copper and Anchorage Digital, which hold or control private keys through policy engines and multi-party signing rather than simply relaying exchange API data. None of those custody providers were implicated in this incident, and the architectural difference is the point: a compromise of a connectivity layer exposes data and configuration, while a compromise of a custody layer can expose the assets directly.
That distinction is exactly why institutional buyers increasingly split vendors into tiers by blast radius. A connectivity and analytics tool that never touches signing keys carries a lower theoretical ceiling on loss than a custodian holding the keys outright, but as Haruko shows, a lower ceiling doesn’t mean zero, particularly when trading data and API scopes can still be weaponized. Firms serving the same institutional base, Talos on the execution side, FalconX on prime brokerage, Fireblocks and Copper on custody, will all face renewed questions this month about default security posture, hosting choice, and whether IP whitelisting is opt-in or mandatory.
What Haruko and Its Clients Are Doing Now
On the record, Haruko’s response has three parts: patch the exploited vulnerability, rotate server-side secrets, and push every remaining client toward IP whitelisting. That’s a reasonable incident-response playbook, and it matches how most infrastructure vendors respond to a token-theft event once discovered. What’s still missing publicly is the promised full technical post-mortem, attribution of the attacker, and a client-by-client accounting of losses.
On the client side, the split is already visible. GSR and 3iQ went public within a day to say their own controls held. The rest of Haruko’s named customers stayed quiet through CoinDesk’s initial reporting window, which is its own kind of signal in a market where silence after a breach headline tends to get read as something to hide rather than nothing to say.
Lessons for Engineering Teams Building on Exchange APIs
For engineers building or maintaining exchange integrations, the practical takeaways from this Haruko cyberattack are narrow but concrete. First, don’t treat read-only as synonymous with harmless. Second, IP whitelisting should be a default, not an opt-in checkbox buried in account settings. Third, tokens pulled from process memory are a reminder that secrets management needs to extend past storage and into runtime, where a vulnerable process can leak whatever sits in memory alongside it.
What Regulators Might Do Next
Haruko is a UK-based firm serving a global institutional client base, which puts it loosely in view of the Financial Conduct Authority’s operational-resilience expectations for regulated firms that outsource critical functions. Those rules were written with traditional finance vendors in mind, not crypto middleware specifically, so this incident is likely to feed into the ongoing argument for extending outsourcing and third-party risk frameworks explicitly to digital-asset infrastructure providers, rather than triggering new rules on its own.
5 Predictions for What Happens Next
- Haruko publishes a technical post-mortem within weeks, naming the exploited component without naming the attacker, similar to how other infrastructure vendors have handled comparable disclosures.
- At least one more named Haruko client either confirms impact or issues its own denial, following the pattern GSR and 3iQ set within 24 hours of the story breaking.
- Rival connectivity and portfolio-tools vendors serving institutional crypto clients publish security-posture statements or force IP whitelisting to default-on within the next quarter, using this incident as the reason.
- Institutional due-diligence questionnaires for crypto infrastructure vendors add explicit questions about bare-metal versus cloud hosting and default API key scopes, mirroring enterprise SaaS security reviews.
- TRM Labs’ and CertiK’s second-half 2026 reports show infrastructure and vendor compromises holding or growing their share of total dollar losses, even if headline attack counts plateau.
Frequently Asked Questions
What is Haruko?
Haruko is a London-based crypto technology provider that gives institutional clients, including hedge funds and asset managers, a consolidated view of their trading positions, risk and data across exchanges, custodians, blockchains and DeFi protocols. It says it connects more than 80 clients to over 100 trading venues, 30 blockchains and 250 onchain protocols, according to its own company website.
Was money actually stolen in the Haruko cyberattack?
According to sources cited by CoinDesk, some smaller hedge-fund clients with weaker security controls may have lost a small amount of funds. No total dollar figure has been confirmed publicly, and Haruko has not issued its own public statement on losses at the time of writing.
Were exchange login credentials stolen?
No. Reporting indicates clients’ login credentials on their own systems were not compromised. The attacker instead extracted a user-access token from Haruko’s own server infrastructure, exposing read-only API details and trading data associated with that token.
How many Haruko clients were affected?
Fifteen clients were affected, according to Haruko co-founder and CTO Adam Carlile, cited in messages reviewed by CoinDesk. Those were reportedly all of Haruko’s clients that had not enabled inbound IP whitelisting.
Which companies confirmed they were not affected?
GSR and 3iQ Digital Assets both told CoinDesk they were not impacted. 3iQ specifically cited its use of IP whitelisting as the reason its funds remained secure. Other named Haruko customers, including Bitcoin Suisse, Flowdesk, M2 and Trovio Asset Management, did not respond to requests for comment before the initial report published.
Why does IP whitelisting matter so much here?
IP whitelisting restricts which computers or networks are allowed to use a given API key, even if that key’s credentials are stolen elsewhere. Clients who had this control enabled at Haruko were not among the 15 affected accounts, making it the single clearest differentiator between exposed and unexposed clients in this incident.
How does this compare to bigger crypto hacks like Bybit or Ronin?
It’s far smaller in dollar terms and different in mechanism. Bybit and Ronin involved direct compromises of exchange or bridge infrastructure holding customer assets, with losses in the hundreds of millions to over a billion dollars. Haruko is a vendor whose systems don’t hold customer assets directly, so the exposure ran through API credentials and trading data rather than through a hot wallet or bridge contract.
What should institutional crypto clients do after a vendor breach like this?
Security teams generally recommend rotating any API keys shared with the affected vendor, enabling IP whitelisting if it wasn’t already active, auditing key permissions to confirm no unnecessary trade or withdrawal scopes exist, and requesting a written incident timeline and remediation plan from the vendor before resuming normal integration use.
