Haruko, a technology provider that supplies portfolio management, risk monitoring and trading-data infrastructure to institutional digital-asset firms, has been hit by a targeted cyberattack that affected 15 clients, exposing exchange API information and trading records and reportedly resulting in limited financial losses for some customers. The incident, disclosed in reporting on September 18, adds another example of attackers targeting the operational infrastructure that sits between professional crypto investors and the venues where they trade rather than focusing exclusively on exchanges, wallets or decentralized-finance applications themselves. CoinDesk reported that three people familiar with the matter said a small amount of client funds was stolen, although neither the total value of the losses nor the identities of the clients that lost assets were disclosed.

The affected information included read-only application programming interface details associated with exchange accounts, as well as client trading data. APIs are a critical component of institutional digital-asset infrastructure because they allow portfolio-management, risk and execution systems to communicate continuously with exchanges and other venues. Haruko uses those connections to consolidate balances, positions, transactions and risk information across fragmented crypto markets. According to Haruko’s website, its technology connects with more than 100 centralized trading venues, supports more than 30 blockchains and integrates with more than 250 on-chain protocols. The company says it is trusted by more than 80 clients globally.

The attack did not appear to begin with theft of customers’ ordinary account usernames and passwords. According to messages from Haruko co-founder and Chief Technology Officer Adam Carlile reviewed by CoinDesk, the attackers exploited a vulnerability in one of Haruko’s processes and extracted a user-access token. That token was then used to capture information held in the process’s memory, which could contain read-only exchange API details and other customer data. Haruko told clients that their login credentials were not compromised on their own systems, distinguishing the incident from phishing or endpoint attacks aimed directly at employees of the affected investment firms.

Carlile characterized the intrusion as a targeted attack on Haruko itself rather than an operation directed at a particular customer. The company identified 15 affected clients. According to the messages reviewed by CoinDesk, those customers were non-whitelisted clients, meaning they did not have an inbound IP whitelist restricting connections to specifically approved internet addresses. Haruko subsequently recommended that clients configure such whitelisting for maximum protection. The distinction is operationally important because IP restrictions can provide an additional barrier even when a credential or token is exposed: a request using a valid credential may still be rejected when it originates from an unauthorized network address.

Haruko said it has fixed the exploited vulnerability and refreshed its server-side secrets. It also told clients that it plans to publish a full technical post-mortem. Such a review could be important for institutional customers because several questions remain unresolved publicly, including how long the vulnerability was present, how the attacker discovered it, the lifetime and scope of the extracted access token, and the precise mechanism behind the reported loss of client funds. The available reporting does not establish that read-only API credentials by themselves enabled withdrawals. Read-only permissions are normally designed to allow retrieval of account and trading information without granting authority to transfer assets or submit transactions.

That distinction makes the reported financial losses one of the most important unanswered elements of the incident. People familiar with the matter told CoinDesk that a small amount of client funds was stolen and that smaller hedge funds with weaker security controls may have been particularly exposed. The amount has not been quantified, and the exact path from the Haruko compromise to any asset transfer has not been publicly established. Until more technical detail is released, the exposure of read-only information and the theft of funds should not be assumed to have occurred through the same permission mechanism. An attacker with detailed position, balance and transaction information may nevertheless gain intelligence useful for follow-on attacks, social engineering or attempts to exploit other weaknesses.

The breach also illustrates the concentration of operational risk created by the institutionalization of digital-asset markets. Professional trading firms increasingly rely on specialist fintech vendors to normalize information from exchanges, custodians, blockchains, brokers and decentralized applications. That architecture can reduce the engineering burden on an individual hedge fund, replacing dozens of proprietary integrations with a smaller number of standardized connections. At the same time, aggregation can create high-value targets. A vendor with access to data from many firms can provide an attacker with significantly greater leverage than compromising an isolated account.

Haruko positions its platform as a unified infrastructure layer for investment managers, hedge funds, prime brokers, trading firms and treasury teams. Its software provides consolidated portfolio data, risk analytics, transaction information and monitoring across centralized and decentralized venues. Haruko says clients can connect new trading counterparties by entering read-only API keys or wallet addresses, while live and historical data can be accessed through its web interface or API. That model is representative of a broader fintech trend in which institutional firms outsource connectivity and data normalization while retaining investment, execution and custody decisions internally.

The incident therefore raises issues beyond whether any single compromised credential could authorize a withdrawal. Trading records themselves can be highly sensitive for hedge funds and market makers. Position data can reveal strategy concentrations, venue usage, liquidity requirements, margin levels or changes in exposure. Historical transactions may also provide information about execution patterns. For professional investment firms, confidentiality around that data is an important component of operational security even when the underlying API permissions are restricted to viewing information.

Two publicly identified Haruko customers have said they were unaffected. GSR told CoinDesk that it had not been impacted by the breach. 3iQ Digital Assets likewise said its funds remained secure and stated that its API access was restricted using IP whitelisting, preventing exposure to the compromised environment. Haruko’s website also names Bitcoin Suisse, Flowdesk, M2, Ampersan, Monarq Asset Management and Trovio Asset Management among firms using its technology, but inclusion on the company’s client list does not mean those firms were among the 15 affected customers. CoinDesk said several listed clients had not responded to requests for comment before publication.

The role of whitelisting is likely to receive particular attention from institutional risk teams reviewing the incident. Security controls around exchange APIs typically operate in layers. Permission settings can limit an API key to data retrieval rather than trading or withdrawals. IP restrictions can constrain where requests may originate. Credential rotation can limit the usefulness of a stolen secret after an incident, while segregation between services can reduce the amount of information available to any single process. Monitoring systems can then identify unusual authentication attempts or access patterns. No individual measure eliminates risk, but combining controls can prevent one compromised component from becoming sufficient to reach sensitive systems.

The handling of access tokens is another issue likely to be scrutinized. Tokens are widely used by financial software because they allow applications to authenticate users or services without repeatedly transmitting primary login credentials. Their security depends on how narrowly they are scoped, where they are stored, how long they remain valid and whether they can be replayed from unauthorized systems. Haruko’s description of an attacker extracting an access token and accessing information held in process memory makes memory protection, token lifetime and application segmentation relevant subjects for the company’s promised post-incident review.

One person familiar with the incident told CoinDesk that Haruko’s use of bare-metal servers, rather than a large public-cloud platform, contributed to the conditions surrounding the breach. That account should not be interpreted as establishing that bare-metal infrastructure is inherently less secure. Dedicated physical servers and cloud environments can both be operated securely or insecurely depending on architecture, configuration, access controls, monitoring and operational practices. Public-cloud providers can supply extensive security tooling, but responsibility for correctly configuring applications, credentials and permissions still rests substantially with customers. More detailed technical disclosure from Haruko would be needed to determine which infrastructure choices were actually relevant to the attack.

The broader digital-asset security environment makes the Haruko incident particularly relevant for fintech vendors serving professional investors. TRM Labs said attackers carried out 207 crypto hacks during the first half of 2026, more than double the 83 incidents it recorded during the comparable period a year earlier. Total losses reached approximately $972 million. While smart-contract exploits accounted for much of the increase in incident count, infrastructure and operational compromises accounted for approximately 76% of all funds stolen despite representing only about 15% of incidents.

Those figures illustrate why institutional security teams increasingly distinguish between application-level vulnerabilities and compromises of the systems that control credentials, signing authority or access to assets. Smart-contract defects can generate numerous individual incidents, but infrastructure attacks can reach centralized stores of credentials or privileged systems and therefore create outsized financial consequences. TRM said organizations should give greater attention to key management, signing infrastructure, approval workflows and custody controls alongside continued investment in software audits.

For crypto-focused hedge funds, the immediate response to a vendor breach can extend well beyond patching a single application. Firms may need to identify every exchange or custodian linked to the compromised platform, revoke and replace API credentials, verify permission scopes, confirm IP restrictions and review transaction histories for unauthorized activity. They may also need to assess whether exposed portfolio information has confidentiality implications even when no assets moved. The process becomes more complex for institutions operating across dozens of venues because each venue can implement API permissions, whitelisting and credential rotation differently.

The incident may also influence procurement and due-diligence practices across institutional fintech. Asset managers evaluating third-party software increasingly ask not only whether a provider undergoes security audits but how credentials are isolated, whether customer secrets are encrypted independently, what information application processes can hold in memory, how authentication tokens are scoped and whether network whitelisting is enabled by default. Firms may also examine incident-response obligations, notification timelines and contractual responsibility for losses linked to infrastructure failures. The attack on Haruko demonstrates why those questions matter even when a vendor is not itself acting as the legal custodian of client assets.

For Haruko, the next significant disclosure will be the technical post-mortem it has told customers it plans to publish. Investors and clients will be looking for a clear timeline of the compromise, the vulnerability’s root cause, how the malicious activity was detected, the exact categories of information exposed and what controls have changed since the incident. Additional clarity on the reported fund losses would also help distinguish the direct consequences of the Haruko vulnerability from weaknesses elsewhere in affected customers’ security arrangements.

The episode does not appear to have disrupted the broader crypto market infrastructure, and the reported monetary loss has so far been described as small. Its significance instead lies in the attack surface it exposes. Institutional adoption of digital assets has created a growing ecosystem of portfolio systems, analytics providers, custody interfaces, execution platforms and data aggregators that function as critical financial plumbing. As that ecosystem becomes more interconnected, attackers have more incentive to target shared infrastructure capable of providing access to data from multiple institutions at once.

Haruko’s remediation — patching the vulnerability, rotating server-side secrets and urging customers to implement inbound IP whitelisting — addresses immediate elements disclosed about the attack. The longer-term test will be whether the forthcoming technical explanation demonstrates that the company has reduced the probability that a compromised internal process could again expose customer credentials or sensitive trading information. For institutional crypto firms and the fintech providers supporting them, the breach is another reminder that operational resilience depends not only on securing assets at the exchange or custody layer, but also on protecting every technology intermediary with access to the data and credentials connecting those systems.