Haruko, a London-based institutional crypto technology provider, suffered a targeted cyberattack that affected 15 clients and exposed exchange API and trading information.
The incident matters because Haruko is not a retail exchange or wallet. It is part of the institutional infrastructure layer that connects funds to centralized exchanges, custodians, blockchains and DeFi protocols.
Compromise at an aggregation/risk-management provider can therefore create risk across multiple venues even if the underlying exchanges are not breached.
What Haruko does
Haruko provides institutional clients with:
- portfolio aggregation;
- risk management;
- trade data;
- exchange connectivity;
- custodian connectivity;
- on-chain/DeFi position monitoring.
The company says it serves more than 80 clients and connects to more than 100 centralized trading venues, 30 blockchains and 250 on-chain protocols.
That connectivity is why third-party infrastructure security is systemically important.
How the breach reportedly happened
Messages from Haruko’s CTO reviewed by reporting describe the following sequence:
- attacker exploited a vulnerability in one Haruko process;
- attacker extracted a user-access token;
- token allowed the attacker to capture/read data held in process memory;
- memory could contain read-only exchange API details and trading information.
Haruko described itself—not a specific customer—as the target of the attack.
15 clients affected
Haruko said:
15 clients
were affected.
Reporting said those were Haruko clients that did not use IP whitelisting around the relevant exchange/API access.
This creates an important control lesson:
API permission scope and network-origin restrictions are separate security layers.
A credential may be “read-only,” but exposing it can still create risk if it reveals sensitive market/account information or if another system trusts requests from broader network locations.
Were exchange passwords stolen?
According to the client messages, customers’ own system login credentials were not compromised.
The stolen access token came from Haruko infrastructure.
That distinction matters for incident response because clients may need to rotate:
- Haruko-related tokens;
- exchange API keys;
- IP whitelist configurations;
- server-side secrets;
without assuming their employee passwords were necessarily stolen.
Fund loss remains unquantified
Sources familiar with the incident said some smaller hedge-fund clients may have lost a small amount of funds.
No reconciled dollar amount has been published.
CEXVia therefore records:
- financial loss: Developing / Unquantified;
- data/API exposure: Confirmed in company messages reviewed by reporting.
The incident should not be given a made-up headline dollar loss.
Client boundary: not every named Haruko customer was affected
Haruko publicly names a number of firms as clients.
However, two prominent firms—GSR and 3iQ—said they were not affected.
3iQ specifically said its API access was restricted through IP whitelisting, preventing exposure to the compromised environment.
This is a useful real-world demonstration of layered API security.
Why read-only API data is sensitive
Read-only does not mean harmless.
Exchange API/trading data can reveal:
- balances;
- positions;
- execution history;
- strategy timing;
- counterparties;
- active venues;
- margin structure;
- account identifiers.
That information can support:
- targeted phishing;
- social engineering;
- front-running / strategy copying;
- credential-stuffing campaigns;
- attempts to exploit other API scopes;
- extortion.
What Haruko changed
Haruko told clients that it:
- fixed the vulnerability;
- refreshed server-side secrets;
- recommended inbound IP whitelisting for maximum protection;
- plans to publish a full technical post-mortem.
The quality of that post-mortem will determine whether the industry can assess whether the vulnerability existed in code, process isolation, bare-metal server configuration or another layer.
Infrastructure concentration risk
Institutional crypto firms increasingly outsource portfolio visibility and integration layers.
This creates a supply-chain problem:
One provider may have connection metadata for dozens of exchanges and custodians.
The provider does not need withdrawal authority to become a valuable target.
The most robust design combines:
- minimum API permissions;
- IP whitelisting;
- short-lived tokens;
- hardware-backed secrets;
- memory isolation;
- rapid credential rotation;
- customer-specific segmentation;
- audit logging.
Evidence Status
Company Messages Reported
- 15 clients affected.
- Process vulnerability exploited.
- User-access token stolen.
- Process-memory data exposed.
- Vulnerability fixed.
- Server-side secrets refreshed.
- Full post-mortem planned.
Media / Developing
- Some client funds reportedly lost.
- Exact dollar loss unknown.
- Complete exposed dataset unknown.
- Exact vulnerability mechanics not yet public.
Confirmed Client Statements
- GSR said it was not affected.
- 3iQ said it was not affected and cited IP whitelisting.
Risk Assessment
High institutional infrastructure / supply-chain risk.
The attack affected a limited client set, but the incident demonstrates the concentration risk created by third-party exchange connectivity.
What to Watch Next
Haruko post-mortem, exact client loss, exchange-key rotation, affected-client notifications, regulator/privacy reporting and proof that all access tokens/secrets were invalidated.
FAQ
How many Haruko clients were affected?
15.
Were customer passwords stolen?
Haruko’s messages said clients’ own login credentials were not compromised.
What data was exposed?
Process memory could contain read-only exchange API details and trading data.
Were funds stolen?
Some smaller clients may have lost funds, but no reconciled amount is public.
Why does IP whitelisting matter?
It restricts where an API credential can be used even if the credential itself leaks.
Has Haruko fixed the vulnerability?
Haruko says the vulnerability is fixed and server-side secrets were refreshed; a full post-mortem is still pending.