The Haruko cyberattack highlights a practical lesson about crypto API security risks: keeping your main assets in a self-custody wallet does not make every connected exchange account safe. If an attacker obtains an exchange API key with trading, withdrawal, or broad account permissions, they may be able to act through that account even without your wallet’s seed phrase.
On September 18, 2026, CoinDesk reported that crypto technology provider Haruko suffered a cyberattack affecting 15 clients, with some funds reportedly lost. The incident matters this week because it shows how an access layer between trading platforms and portfolio software can become a target. CoinDesk’s report is the current source for the incident details; the broader security lesson is about limiting what API credentials can do.
What changed this week—and why it matters
The new development is the reported Haruko attack and its stated impact on 15 clients. Public reporting does not establish every technical detail of the intrusion, so it would be unsafe to assume that all affected users lost funds in the same way or that a particular credential was definitely responsible.
What the report does make clear for ordinary crypto users is that “self-custody” is not a security guarantee for funds left on, or connected to, a centralized exchange. A user can protect a hardware or software wallet while still exposing a separate trading account through an API key, an integration, a portfolio manager, or a trading bot.
That distinction is important:
- Wallet keys authorize on-chain actions from a blockchain address.
- Exchange API keys authorize actions inside an exchange account.
- Integration credentials may let a third-party service read data or submit trading instructions on your behalf.
- Withdrawal permissions can create a direct route for assets to leave the exchange account.
The security boundary is therefore not just your wallet. It includes every service that can observe, trade, move, or manage your funds.
What is an exchange API key?
An application programming interface, or API, lets one program communicate with another. An exchange may issue an API key and secret so that portfolio software, an accounting tool, or a trading application can retrieve balances and place orders without asking you to log in manually each time.
An API key is usually not the same as your exchange password. It is a separate credential with its own permissions, IP restrictions, expiration settings, and audit history. The exact controls vary by platform, but common permissions include viewing account data, placing or cancelling trades, transferring funds, and withdrawing assets.
This creates convenience, but also creates a second set of credentials to protect. An attacker does not necessarily need your password or seed phrase if a valid API secret already grants enough authority.
Why broad permissions increase the blast radius
The phrase “blast radius” describes how much damage one compromised credential can enable. A read-only key may expose balances, transaction history, and trading activity but normally cannot place orders. A trading-enabled key may let an attacker buy, sell, or cancel orders. A withdrawal-enabled key can be substantially more dangerous because it may allow assets to leave the exchange account.
Permissions should match the task. If a tax application only needs transaction history, it should not receive trading rights. If a bot needs to place orders, it generally does not need permission to withdraw. If an integration requires every permission, ask whether the convenience is worth concentrating so much authority in one credential.
A useful comparison looks like this:
| API permission | What it may allow | Main risk if exposed | Safer default |
|---|---|---|---|
| Read-only | View balances, orders, and history | Privacy loss and targeted phishing | Use when monitoring or accounting |
| Trading | Place, change, or cancel orders | Losses from unauthorized trades or market manipulation | Limit to a dedicated trading account |
| Transfer | Move assets between supported accounts | Unauthorized internal transfers | Disable unless essential |
| Withdrawal | Send assets away from the exchange | Direct loss of funds | Disable; use allowlists if available |
| Administrative | Change settings or manage keys | Account takeover and permission escalation | Avoid for third-party tools |
The names differ between exchanges. Read the platform’s current API documentation rather than relying on a label such as “standard” or “full access.” For example, Coinbase’s API documentation explains that API authentication is used to authorize requests, while the particular product and permission model determine what those requests can do.
How an attack can reach connected funds
There are several possible paths from a compromised service to a user’s exchange balance. These are general scenarios, not a claim about the specific Haruko intrusion.
Stolen secrets
A service may store API keys so it can act on a customer’s behalf. If attackers penetrate that service, they may search for secrets in databases, logs, backups, configuration files, or developer systems. Strong encryption and careful secret management reduce this risk, but they do not make a permanently valid key harmless.
The same principle applies if a user copies an API secret into a compromised computer, browser extension, spreadsheet, or messaging app. A secret that can be replayed elsewhere is different from a hardware-wallet signature that requires a user’s physical device and approval.
Over-permissioned integrations
A user may approve a tool for one purpose and forget that the key can do more. A portfolio tracker that only needs balances should not be able to trade. A market-making or automation service may need trading access, but withdrawal access can often remain disabled.
The problem is not merely whether a provider is reputable. It is whether the credential remains powerful after the provider, the user’s device, or an employee account is compromised.
Account chaining
Trading firms and technology providers may connect multiple venues, accounts, and operational systems. A single integration can therefore become a central point of failure. The more accounts a credential can reach, the more important it is to separate clients, restrict networks, rotate secrets, and monitor activity.
This resembles other crypto incidents where the vulnerable component is not necessarily the blockchain itself. Our guide to the crypto attack surface map explains why wallets, devices, bridges, applications, and service providers all belong in a user’s threat model.
What this does—and does not—say about self-custody
Self-custody protects control of assets held in your own wallet when the private keys are secured. An exchange API key does not give an application control of that wallet unless you separately expose the wallet’s signing capability or approve an on-chain transaction.
However, self-custody does not automatically protect:
- Funds held on a centralized exchange.
- Stablecoins or other assets deposited as trading collateral.
- Assets that an exchange account can withdraw to an attacker’s address.
- Personal information and trading history exposed through an integration.
- Other accounts reachable through reused passwords, devices, or credentials.
The right conclusion is not that exchange APIs are inherently unsafe. APIs are useful tools, and carefully limited keys can be safer than repeatedly sharing a password with an application. The conclusion is that exchange access should be treated as a separate custody and authorization problem.
How to audit your exchange API access
If you have ever connected an exchange to a portfolio tracker, tax tool, trading bot, market-data service, or institutional platform, review it now. The following checklist is a practical starting point:
- List every integration. Check each exchange’s API-management page, connected-app page, and security log.
- Delete anything unused. An old key is still a live credential until revoked or expired.
- Reduce permissions. Keep read-only access for reporting, trading access only where necessary, and withdrawal access off whenever possible.
- Use IP allowlisting. If a provider offers fixed outbound addresses, restrict the key to those addresses. Treat this as an additional control, not a complete solution.
- Separate funds. Keep only the amount needed for a strategy or trading operation in the connected account. Do not use one key across your entire portfolio.
- Turn on alerts. Monitor new API keys, permission changes, withdrawals, login events, and unusual orders.
- Rotate after uncertainty. If a device, provider, employee account, or vendor may have been exposed, revoke the old key and create a new one through the official exchange website.
- Secure the exchange account itself. Use a unique password, phishing-resistant multifactor authentication where available, withdrawal address allowlists, and account-level locks.
Do not send an API secret to support through chat or paste it into a public issue, document, or screenshot. Legitimate support should not need the secret value. If you suspect compromise, revoke access first and investigate afterward; waiting for perfect certainty gives an attacker more time.
A simple custody design for everyday users
A safer setup separates roles. Keep long-term holdings in a self-custody wallet that is not connected to trading APIs. Use a separate exchange account or subaccount for active trading, fund it with only what the strategy needs, and connect a key with the narrowest possible permissions.
For reporting, create a read-only key if the exchange supports one. For automation, use a dedicated key, fixed IP addresses, order-size limits, and independent alerts. Where an exchange supports withdrawal address allowlists or time delays, enable them—but understand that a compromised account may still incur trading losses even if withdrawals are blocked.
You can also review the broader distinction between personal custody and third-party control in Not Your Keys: What Exchanges Hold. The goal is not to eliminate every service; it is to ensure that one compromised integration cannot expose your entire crypto setup.
Key takeaway
The Haruko report is a reminder that crypto security has layers. A protected self-custody wallet can remain unaffected while a connected exchange account, API credential, or trading service is compromised. Review each API as an authorization grant: know what it can read, trade, transfer, or withdraw, and remove powers that the integration does not need.
The most useful action today is simple: open every exchange’s API settings, revoke unused keys, disable withdrawal permissions, and separate long-term holdings from accounts used by automated tools. That reduces the potential damage from credential theft without requiring you to stop using exchanges or portfolio software.
This article is for educational purposes and is not financial advice.
