A targeted cyberattack on Haruko, a London-based technology provider serving institutional crypto firms, exposed exchange API details and trading data belonging to 15 clients, with some smaller hedge funds losing assets as a result.
The attacker exploited a vulnerability in one of Haruko’s processes, extracted a user-access token, and used it to read data held in that process’s memory, according to messages from co-founder and chief technology officer Adam Carlile reviewed by CoinDesk.
That memory contained read-only exchange API details and other client data.
Carlile described it to clients as a targeted attack carried out by an organised group. The affected parties were all of Haruko’s non-whitelisted clients.
Clients’ own login credentials were not compromised on their systems.
Haruko said on 18 September that it had fixed the vulnerability and rotated server-side secrets. It did not respond to repeated requests for comment.
Read-only is not the same as harmless
The instinctive reaction to a read-only API leak is that nothing serious happened. Read-only permissions typically allow an application to see account data without placing trades or withdrawing funds.
Some clients lost money anyway.
The reason is that read-only access tells an attacker exactly what a fund holds, how it is positioned and how it trades. That is an intelligence product, not a harmless data spill.
What turns intelligence into losses is whatever else is weak at the client end. An old withdrawal permission that was never revoked. A wallet address that was never rotated. A stale API key with broader permissions than anyone remembered granting.
Smaller hedge funds with weaker security controls were particularly exposed, according to people familiar with the incident. Neither the aggregate value of the losses nor the precise method by which funds were taken has been disclosed.
That gap matters. Without knowing the mechanism, other Haruko clients cannot fully assess whether the same path exists in their own setup.
The whitelist did the work
The single most useful detail for any institution reading this is that the affected clients were all non-whitelisted.
An inbound IP whitelist restricts access to a specified list of internet addresses. Clients who had configured one were not affected. Clients who had not were.
Haruko told customers that configuring an inbound IP whitelist would provide maximum protection.
That is a configuration setting, not a product feature. It was available to every client, and 15 of them had not enabled it.
The pattern recurs across institutional crypto security. The control that would have prevented the incident usually exists and is optional, and the firms that skip it tend to be the ones with thinner operational resources.
The infrastructure choice is being questioned
Haruko runs its own bare-metal servers, physical machines it controls directly, rather than using a cloud provider such as Amazon Web Services.
That decision gives a company more control over its stack, which is a legitimate reason to make it. It also means fewer built-in layers of access monitoring and process isolation between an exploited process and whatever is sitting in its memory.
Cloud platforms bundle those guardrails by default. Bare metal requires building them.
Whether that choice caused the breach is not established, and the reporting does not confirm it. What can be said is that the attack worked by reading data out of a running process’s memory, and that isolating processes from one another is precisely the kind of protection managed platforms provide as standard.
Haruko says it serves more than 80 clients globally and connects to over 100 centralised trading venues, 30 blockchains and 250 on-chain protocols. Its client base ranges from firms such as GSR and Bitcoin Suisse down to much smaller funds.
It plans to publish a full technical post-mortem.
Infrastructure is where the money goes
The incident fits a pattern that security firms have been documenting all year, and the numbers are stark.
TRM Labs recorded 207 crypto attacks in the first half of 2026, more than double the 83 logged a year earlier, resulting in roughly $972 million in losses.
The distribution is the important part. Infrastructure and operational compromises accounted for about 76% of the money stolen while representing only 15% of incidents.
CertiK, using a different methodology, put first-half losses at approximately $1.32 billion across 344 incidents. The two figures are not directly comparable, but both point the same way.
Attacking a smart contract requires finding a flaw in code that has usually been audited. Attacking the service provider that dozens of firms depend on reaches all of them at once, and the failure is operational rather than cryptographic.
Haruko sits in exactly that position. A single vulnerability in one process reached 15 institutional clients simultaneously.
What clients should check
The practical response is narrow and does not require waiting for the post-mortem.
Enable inbound IP whitelisting where a provider offers it. Audit every API key currently issued and confirm what permissions each actually carries rather than what it was meant to carry. Revoke anything unused. Rotate withdrawal addresses that have been static for long periods.
The broader question is harder. Institutional crypto now runs on a small number of technology providers that sit between funds and exchanges, and those providers concentrate risk by design. A fund can have excellent internal controls and still be exposed through a vendor it does not operate.
That is not unique to crypto. What is unique is that the transactions are irreversible, which removes the recovery mechanism most of traditional finance relies on when operational security fails.
FAQ
What was exposed?
Read-only exchange API details and trading data for 15 institutional clients. Attackers exploited a vulnerability in one of Haruko’s processes, extracted an access token, and read data from that process’s memory. Client login credentials on their own systems were not compromised.
How did funds get stolen from a read-only leak?
Read-only access reveals what a fund holds and how it trades. Combined with weaknesses at the client end, such as an unrevoked withdrawal permission or an unrotated wallet address, that information can be converted into losses. The precise method and amounts have not been disclosed.
Who was affected?
All 15 affected clients were non-whitelisted, meaning they had not configured an inbound IP whitelist restricting access to approved addresses. Haruko has told clients that enabling one provides maximum protection.
Disclaimer: This article is for informational purposes only and does not constitute financial or security advice. Cryptocurrency investments carry significant risk. Always conduct your own research before making any investment decisions.
