Haruko, the UK-based crypto infrastructure vendor, told clients a targeted attacker exploited a vulnerability in one of its processes, stole a user access token from memory, and walked away with read-only exchange API details and trading data for fifteen customers—all of whom had skipped inbound IP whitelisting. CoinDesk published CTO Adam Carlile’s client messages on September 18, 2026; sources also said a small amount of client funds was stolen, though the amount was not disclosed. GSR and 3iQ publicly said they were not impacted.
Incident details: BreachHistory — Haruko API breach 2026. Reporting: CoinDesk, Altcoin Buzz, and CoinEdition.
Timeline
September 15, 2026 is the incident date recorded in Haruko’s disclosure chain—the day the attack activity tied to the process vulnerability and token theft. Client-facing communication and trade press coverage landed September 18, 2026, which is when most of the market learned the scope: fifteen clients, read-only API exposure, memory capture, and remediation steps already underway.
Haruko said it fixed the vulnerability and rotated server-side secrets. It urged customers to enable IP whitelisting and promised a technical post-mortem. What is not yet public at indexing is a line-by-line CVE-style writeup of the process flaw or the attacker’s initial access vector beyond “targeted” and “process vulnerability.”
What we know vs what we do not
Known from Haruko via CoinDesk: Exploitation of a Haruko process vulnerability; extraction of a user access token; data captured from process memory potentially including read-only exchange API details and trading data; exactly fifteen affected clients, each lacking inbound IP whitelisting; client login credentials on client systems were not compromised according to Haruko; vulnerability patched; server-side secrets rotated; IP whitelisting recommended.
Known from sources to CoinDesk but not fully quantified: A small amount of client funds was stolen. No dollar or token amount was published.
Known negatives: GSR and 3iQ stated they were not impacted—useful for their LP and compliance teams, not a guarantee about other funds.
Unknown: Attacker identity, whether read-only keys were escalated elsewhere, full list of affected clients, whether trading data included positions still open at theft time, and regulatory filings beyond press coverage.
What Haruko does — and why API keys matter
Haruko sits in the stack institutions use to connect to exchanges, normalize balances, and run treasury workflows. Even read-only API keys are high value: they reveal holdings, historical trades, counterparty patterns, and sometimes withdrawal addresses in metadata. Attackers combine that intelligence with social engineering against fund admins or hunt for withdrawal-enabled keys on other systems.
Read-only does not mean “safe if leaked.” It means the stolen Haruko-side material was scoped to non-withdrawal API configurations as described—but CoinDesk’s sources still reported some fund loss, which implies either separate mechanisms or misuse beyond pure read access. Haruko has not publicly reconciled those two facts in one document at indexing time.
How the attack worked (as disclosed)
The chain described is memory-centric: compromise a Haruko process, pull an access token, read what that token unlocked from live process memory. That pattern fits attackers who already achieved code execution or deep application access—not a simple phishing email to a retail user.
All fifteen impacted clients shared one configuration choice: no inbound IP whitelisting on the Haruko side. Whitelisting is tedious—IPs change, colo moves, DR sites multiply—but it is also the difference between “stolen token works from anywhere” and “stolen token dies at the network edge.” Haruko’s post-incident urging is effectively an admission that optional controls were not universal among clients.
Client-system login credentials were not compromised per Haruko. That narrows remediation: rotate exchange API keys, review Haruko-side permissions, enable whitelists, and audit who can see trading dashboards—not reset every employee laptop by default.
What was exposed
For the fifteen clients:
- Read-only exchange API details (connection parameters attackers could reuse or probe).
- Trading data visible to Haruko’s processes—historical and possibly recent activity depending on what sat in memory at capture time.
Haruko did not publish a field-level spreadsheet of every JSON key leaked. Compliance teams should assume anything Haruko’s platform could read for those APIs is in scope until a forensic letter says otherwise.
What was not exposed (per company)
Login credentials stored on client systems were not compromised according to Haruko’s messaging. That is not the same as “no exchange account risk”—API keys are themselves secrets—but it does mean the breach narrative is not “harvester stole Okta passwords for fifteen hedge funds.”
Who is at risk
The fifteen non-whitelisted clients
Direct victims must rotate keys, enable IP restrictions, review open orders and withdrawal allowlists on exchanges, and compare trading logs for anomalies around mid-September 2026.
Counterparties and prime brokers
Trading data can reveal strategy timing. Competitors or malicious actors who obtain it may infer execution patterns even without withdrawal rights.
Other Haruko customers
Not in the fifteen does not mean ignore the post-mortem. Patch adoption, whitelist enforcement, and secret rotation should be mandatory this week, not optional reading.
Retail crypto users
This is not a consumer wallet app breach. Unless you are staff at an affected institution, “Haruko data breach” does not mean your mobile wallet seed phrase leaked from this incident.
Crypto infrastructure context in 2026
2026 already saw adjacent pain in the same ecosystem: support-system breaches at bitcoin vendors, SSO flaws at email providers touching crypto brands, and fake government data requests to fintechs. Haruko fits the pattern where attackers target the plumbing—API aggregators, portfolio tools, email—rather than only centralized exchanges.
Institutional players often stack vendors. One process vulnerability at a middleware provider becomes fifteen exchange faces. That is why regulators and LPs ask about fourth-party risk during diligence.
IP whitelisting — why fifteen clients matter
Inbound IP whitelisting on API middleware is unpopular because operations teams travel, fail over, and use dynamic cloud egress. But the Haruko incident is a live case study: every confirmed victim had not enabled it. Firms that treat whitelisting as “nice SOC2 checkbox” got a expensive counterexample.
Practical compromise many funds use: whitelist primary and DR egress IPs, break-glass procedure for traders on VPN, and alert on any authentication from non-listed IPs even if policy temporarily allows it. Haruko explicitly pushed whitelisting after the breach—listen to that as requirement, not marketing.
Fund loss without public amounts
CoinDesk’s sources said a small amount of client funds was stolen. “Small” for a crypto fund can still be seven figures; without numbers, risk teams should not downgrade severity. Possible explanations that do not contradict the read-only API description include: stolen keys elsewhere, social engineering after trading intelligence, or misuse of permissions not described in the short client note. Do not invent which path applied; do investigate all.
What Haruko said and promised
CTO Adam Carlile’s client messages—reviewed by CoinDesk—emphasized fix, rotation, whitelisting, and an upcoming technical post-mortem. Waiting for that post-mortem before internal architecture review is backwards; start controls now, validate details when published.
Phishing tied to Haruko headlines
Attackers will email crypto ops teams:
- “Haruko mandatory API rotation — enter keys here” on a typosquat domain.
- Fake CoinDesk or “Haruko Security” PDFs with macro malware.
- Slack or Telegram messages claiming to be Haruko support asking for exchange read-only keys “to verify you are not in the fifteen.”
Real vendors use established client channels and never collect API secrets over email. Rotate keys only inside official Haruko UI or documented runbooks.
Action items
- Confirm with Haruko whether your organization is among the fifteen; do not trust third-party “leaked client lists.”
- Rotate all exchange API keys connected through Haruko; treat old keys as burned.
- Enable inbound IP whitelisting on Haruko and on exchange APIs where supported.
- Review exchange audit logs for mid-September 2026 API use from unknown IPs.
- Check withdrawal allowlists and address books for unauthorized additions.
- Brief LP and compliance with facts from Haruko/CoinDesk—avoid rumor channels.
- Monitor for Haruko’s technical post-mortem; map findings to your own middleware vendors.
- If you are GSR or 3iQ, your public not impacted statements reduce immediate key rotation urgency—but still review vendor concentration risk.
Comparison to read-only vs trade keys
Exchange APIs often ship with permission tiers: read, trade, withdraw. Haruko emphasized read-only material in process memory. Funds should inventory which keys Haruko ever stored and whether any client mistakenly attached broader permissions. Configuration drift kills read-only assumptions.
Regulatory and disclosure lens
UK and EU crypto service providers face increasing incident reporting expectations. At indexing, this story broke via trade press rather than a long regulatory PDF. Affected institutions may still have their own SEC, FCA, or MAS obligations independent of Haruko’s timeline.
Technical memory theft — reader plain English
When software runs, secrets often sit in RAM: session tokens, API bearer strings, decrypted config. An attacker who executes code inside the Haruko process space can scrape that memory without touching a client’s laptop. That is why “client credentials not compromised” can still coexist with “API details exposed”—the theft point was vendor infrastructure, not employee Chrome profiles.
Vendor diligence questions
If you are evaluating crypto middleware in late 2026, ask vendors: Do you support mandatory IP allowlists? How do you isolate customer tokens in memory? What is your mean time to rotate all server secrets after a process RCE? Can we get per-client audit logs to our SIEM? Haruko’s incident turns those from boilerplate into scored criteria.
Was I affected?
Only if you are a Haruko client—and possibly only if you were one of the fifteen without whitelisting. Retail traders using exchanges directly without Haruko are outside the confirmed scope. When in doubt, email your fund’s CTO using known contacts, not links in breach-news Twitter threads.
What “read-only” still means in practice
Haruko described the exposed exchange credentials as read-only. That label matters for withdrawals — and it does not erase risk. Read-only API keys still leak positions, fills, balances, and venue metadata that competitors or extortionists can use. If any venue key was mis-scoped with trade or transfer rights, the path from “readonly” to money movement gets shorter fast.
Sources told CoinDesk a small amount of client funds was stolen. The public record does not explain the amount or the exact withdrawal path. Until Haruko’s promised post-mortem lands, treat that detail as reported, not fully explained.
IP whitelisting is the control Haruko pushed hardest afterward. Every one of the 15 impacted clients had left it off. Firms that already enforce allowlists — GSR and 3iQ among those who spoke publicly — used that setting as their clean bill of health. That is firm-specific, not a free pass for peers who skipped the toggle.
Canonical record
2026 Haruko process vulnerability and token theft
Sources:
- CoinDesk — client messages and fund loss sourcing
- Altcoin Buzz — whitelisting angle
- CoinEdition — trading data exposure summary
For related institutional crypto incidents see BreachHistory coverage of Pocket Bitcoin’s support-system breach and Revolut’s fake government-domain disclosure.
Post-incident architecture review
Security teams should diagram where Haruko tokens live: which processes, which containers, which secrets managers. Memory scraping attacks push vendors toward short-lived tokens, hardware enclaves, or sidecar isolation—none of which Haruko has publicly committed to in the September 18 articles. Clients can still shorten token TTL on exchange APIs and require manual approval for large trades regardless of vendor roadmap.
Open questions for the post-mortem
Did the attacker need prior credentials to reach the vulnerable process? Was the vulnerability known internally before exploitation? Were any clients whitelisted but impacted via support impersonation? The community should not treat silence as “no.” Treat it as “not yet disclosed.”
Summary stakes
Fifteen institutions. Read-only exchange API intelligence plus trading data. Optional IP controls that were off. Some funds lost money according to sources, amount unknown. Fix shipped, secrets rotated, whitelisting preached. That is the Haruko data breach 2026 story in one breath—everything else is institution-specific response.
Exchange API rotation — operational steps
Ops teams should treat September 2026 as a fire drill: revoke old Haruko-linked keys on each exchange UI, create keys with minimum read/trade scopes, store them in hardware-backed secret managers, and document which desk trader owns each key. Exchanges like Binance, Coinbase Institutional, and Kraken Futures expose audit trails—export CSV logs covering September 15–20 for SOC review.
Threat modeling read-only leakage
Adversaries who know your open positions and hedge timing can front-run or manipulate OTC negotiations even without withdraw permission. Compliance officers should brief investment committees that read-only Haruko exposure is a material non-public information risk inside the firm, not “just metadata.”
Concentration risk when middleware fails
Funds using multiple aggregators should compare Haruko’s post-mortem (when it lands) against your second vendor’s isolation model. Single-vendor dependency turns one process bug into firm-wide key rotation weekend. GSR and 3iQ’s not impacted statements highlight that exposure was subset—not universal—among Haruko’s book.
Incident communications template
If you are CISO at an affected fund, LP letter should state: confirmed in fifteen, read-only API/trading data in memory, client passwords not on Haruko per vendor, keys rotated, whitelisting enabled, exchange logs reviewed, unknown fund loss amount if applicable. Avoid quoting CoinDesk “small” loss as immaterial without numbers.
UK regulatory lens (high level)
Haruko is UK-based; clients may have cross-border reporting duties. This article does not cite FCA filings at indexing—check your compliance queue independently.
SIEM queries for September 2026
Security engineers should hunt Haruko-related OAuth and API tokens used from geographies your fund never trades from, POST bodies to exchange REST endpoints outside office hours, and new API key creations on exchanges immediately after September 15. Correlate with Haruko support tickets in case the vendor notified you before press.
Third-party risk questionnaires
Update your vendor risk register entry for Haruko with incident date, fifteen-client scope, whitelisting gap, and remediation status. LP due diligence in Q4 2026 will ask; having CoinDesk and Haruko post-mortem links ready speeds audits without exaggerating impact beyond confirmed facts.
Separate Haruko login from exchange login
Haruko said client-system login credentials were not compromised. Still rotate Haruko dashboard passwords if your policy mandates rotation after any vendor incident—cheap hygiene that does not contradict the vendor statement about theft path.