Haruko cyberattack exposed API and trading data for 15 crypto clients
CoinDesk reports that attackers exploited a vulnerability in the institutional technology provider’s infrastructure; some client funds may have been stolen, but the amount and full attack path remain undisclosed.
A targeted cyberattack on Haruko, a London-based technology provider for institutional digital-asset firms, affected 15 clients and exposed exchange API details and trading data, according to CoinDesk’s report. Crypto Times independently described the same incident and said Haruko’s customer communications identified 15 affected clients.
The attack exploited a vulnerability in one of Haruko’s processes, allowing an attacker to extract a user access token and capture information held in process memory. Haruko co-founder and chief technology officer Adam Carlile told a customer that the affected clients were non-whitelisted, meaning they had not restricted inbound connections to approved internet addresses.
The exposed material reportedly included read-only exchange API information and trading data. Read-only does not mean risk-free. It can limit direct trading or withdrawal permissions, but the practical risk depends on each client’s configuration, adjacent credentials, account controls and what other information was present in memory.
Losses are reported, but not quantified
Three people familiar with the incident told CoinDesk that a small amount of client funds was stolen and that smaller hedge funds with weaker security controls may have been more exposed. Neither Haruko nor the sources disclosed a dollar amount, the affected firms or a complete list of exchanges and accounts involved.
Haruko did not respond to repeated requests for comment cited by CoinDesk. GSR, which Haruko lists among its clients, said it was not affected by any rumored breach. Other named firms did not respond before publication. Those non-responses do not prove impact or non-impact, and the reported loss remains an attributed claim rather than a completed forensic finding.
The distinction matters for accountability. A data exposure, a compromised API token and an unauthorized transfer are different events with different technical and legal consequences. The public record currently supports the first two more clearly than it establishes the full chain to any reported theft.
Haruko says it patched the weakness
Haruko told customers it had fixed the vulnerability and refreshed its server-side secrets. The company recommended inbound IP whitelisting and said it plans to publish a technical post-mortem. That report should clarify the vulnerable component, token lifetime, affected venues, timeline of detection, evidence of access and whether outside forensic or regulatory reviews are under way.
The incident illustrates a concentration problem in institutional crypto operations. Haruko says its platform connects clients to more than 100 centralized trading venues, 30 blockchains and 250 on-chain protocols. A shared integration layer can reduce operational friction, but it also creates a high-value target whose compromise can expose several counterparties at once.
The next useful evidence is the company’s post-mortem, client-specific disclosures and any exchange or law-enforcement notices. A patch is not a complete incident report. Institutional users should treat this as a reported security event, not proof that every named client lost funds or that the final scope is known.
