Invest1 publisher2 min readPublished
Missing IP whitelisting linked to which Haruko customers had data exposed
Haruko says the exchange credentials exposed in a token theft were read-only and that it holds no client assets. People familiar with the matter say a small amount of client money was taken anyway, and no figure has been published.
The Investor · Invest desk
What happened
- Adam Carlile, Haruko's co-founder and chief technology officer, told clients that attackers exploited a flaw in one internal process, pulled a user access token from its memory and obtained read-only exchange API details and trading records for 15 customers.
- All fifteen affected firms were customers that had not enabled inbound IP whitelisting, the setting that confines API traffic to approved network addresses.
- Haruko says it has closed the vulnerability, rotated server-side secrets and advised every customer to turn on IP restrictions, with a fuller technical account expected later.
- People familiar with the matter said a small quantity of client funds was taken, and those losses appear to have landed on smaller hedge-fund users whose own security controls were lighter.
- Haruko lists more than 80 institutional clients, among them GSR, Bitcoin Suisse, Flowdesk, 3iQ Digital Assets and Trovio Asset Management on its public site.
Compiled by The InvestorSomething wrong?How this is made
Why it matters
- cost The clean-up bill sits with the customers, who have to rotate every connected key, test whether strategy data left their systems and confirm no follow-on activity, while the breached vendor held none of their assets.
- contradiction Haruko's own messages describe credentials that could only read, and people familiar with the matter describe money leaving, so an affected fund cannot yet tell whether it is handling an information exposure or a theft.
- exposure One vendor's credential store made the smallest clients the reachable ones, so a fund's counterparty risk here was set by its own operational controls rather than the size of the platform it plugged into.
- decision Each of the 80-plus clients now picks between the operational friction of pinning API traffic to approved addresses and leaving live exchange connectors callable from anywhere.
Read-only credentials retrieve positions and trade history [6]. Haruko does not hold client assets [4]; its job is connectivity and visibility across more than 100 centralized venues, dozens of blockchains and hundreds of on-chain protocols [5]. So what an intruder could reach through those keys was the position book. Rotating a key ends the connection, but it does not retract what already came through, and the affected clients are now working through every connected key and checking whether strategy data left their environment [20].
Fifteen customers against a client list Haruko puts at more than 80 is at most 18.75 percent, and lower if the list runs longer than 80 [3][15][21]. One person familiar with the architecture said Haruko runs on dedicated bare-metal servers instead of a major public cloud [19]. That can reduce some shared-environment risks while limiting certain managed security features [19].
The two accounts of the damage come from different places. Adam Carlile, Haruko's co-founder and chief technology officer, told clients the exposed exchange API details were read-only and that the operation was aimed at Haruko itself, not at any single customer [3][6][10]. The missing funds are reported by people familiar with the matter [7]. No dollar figure has been published [9]. The client messages said company login details stored on clients' own systems were not compromised [12].
Most of the names on Haruko's public client page had not commented when the first accounts of the incident circulated; GSR said it was not affected [16][17][18]. In my view the diligence question that changes here is whether a middleware vendor enforces network restrictions by default, since the set of affected funds was defined by a toggle the customer owned [11]. If the fuller technical account Haruko has promised shows the token could only ever read, and the missing money traces to separate compromises inside those smaller funds, the loss sits with the funds' own controls [14][8].
What to watch
- The fuller technical account Haruko has promised, and whether it says the token's scope stayed read-only throughout.
- Whether any of the still-silent clients on Haruko's public list confirms a loss and puts a number on it.
- Whether Haruko switches inbound IP whitelisting on by default instead of advising customers to enable it.