Earlier this week, Haruko, a London-based company that specializes in providing crypto infrastructure access and technical services to institutional clients, found itself at the center of a targeted network attack—according to a CoinDesk report on September 18, a directed cyber assault on its own infrastructure tore open the apparently secure interface boundary between it and its clients. Attackers exploited security vulnerabilities within Haruko's systems to stealthily extract access tokens from some institutional clients, allowing them to log into these clients' read-only API interfaces configured across multiple centralized exchanges, thereby reading account data and transaction information that was originally only circulated in the backend. Several informed sources revealed that a total of 15 institutional clients were affected, with small hedge funds with weaker security controls showing signs of minor fund or asset losses as a result. The nominally ineffective "read-only" permissions were circumvented, turning into an intelligence gateway for the attackers. The service provider's lapse directly weighed upon the clients, forcing the entire industry to confront an unwillingly acknowledged reality: in such a highly-coupled connected architecture, the security perimeter of service providers and the asset safety of clients are inseparable, and "read-only permissions may also cause damage" is no longer a theoretical risk, but an actual incident that has occurred.
From Service Provider to Breach: How Haruko's Infrastructure Was Compromised
In CoinDesk's report, this incident has been clearly described by multiple informed sources as a "targeted attack on Haruko itself," rather than an isolated incident caused by a careless client. The attackers chose to break into the service provider side first, exploiting security vulnerabilities within Haruko’s infrastructure to bypass the surface defenses of the clients. Through this breach, they extracted access tokens of several institutional clients from Haruko's system and then utilized these tokens to invoke the read-only API interfaces configured by clients at multiple centralized exchanges, pulling the originally backend-circulated account read information and transaction data en masse. According to publicly available information, the attackers obtained read permissions rather than direct trading or withdrawal capabilities, but the sensitive trading profiles of at least 15 institutional clients were still exposed, with small hedge funds having weaker security controls pointed out as possibly experiencing minor losses of funds or assets.
For Haruko, this was not about who made a "configuration error," but rather a comprehensive suite of infrastructure that was proven to have exploitable weaknesses. After the incident was detected internally or externally, Haruko began a hurried "self-rescue": fixing the exploited vulnerabilities, refreshing server-side keys, attempting to lock the door before it was walked through repeatedly, and communicating with the affected clients to alert them to potential risks. Public reports also emphasized that the identity of the attacker, the background of the attack group, and the technical details of the vulnerabilities remain undisclosed, and that no specific figures regarding the scale of losses were provided externally—indicating that even though an immediate patch had been applied, the extent of the hidden risks left behind by this compromised service provider channel would only be gradually uncovered in subsequent investigations and resolutions.
Why Read-only API Breach Still Causes Damage
According to public reports, what was compromised this time was not a high-permission interface that could directly place orders or withdraw funds, but rather the read-only API information and transaction data configured by clients at centralized exchanges. In other words, what the attackers held was a "telescope" of institutional accounts: visible, but without access to the money. However, for institutions used to pulling reports, reconciling accounts, and conducting risk control in the backend, this telescope contained all daily actions—order pacing, trading pair preferences, typical holding periods, concentration of positions, and even rough outlines of certain strategies. Once long-term and systematically observed by strangers, these sensitive charts, which originally only appeared in risk control meeting rooms, became laid out on the attackers' desks. Even though there is currently no public evidence indicating that the attackers directly controlled the trading or withdrawal permissions of the affected accounts, it is at least certain that the read-only data of 15 institutional clients was accessed, which opened a highly valuable entry point for any subsequent intelligence-based attacks.
CoinDesk cited several informed sources stating that small hedge funds with weak security controls could have suffered minor losses of funds or assets in this incident, although the specific paths and amounts have yet to be disclosed. The industry's explanation of how such "read-only leaks turn into tangible losses" predominantly relies on common security logic: possessing knowledge of a certain institution's position structure and trading habits makes it possible to design phishing, social engineering, or market manipulation actions targeted at other interfaces, accounts, or scenarios. Small institutions with inadequate security investments are particularly ill-equipped to bear such "intelligence-enhanced" risks. The Haruko incident thus became a striking footnote: treating read-only permissions as absolutely safe in an environment where service provider security vulnerabilities occur, and one's own risk control is weak, can easily be proven post-factum to be nothing more than a self-comforting assumption.
The Security Gaps of Small and Medium Hedge Funds Were Amplified in This Incident
In the Haruko incident, the primary focus was not on technical details, but on the structural resource disparities. Large institutions can allocate separate projects for security, with dedicated teams monitoring the lifecycle management of access tokens, permission level distinctions, and abnormal behavior alerts; many small and medium hedge funds, on the other hand, outsource these tasks to "vendor default configurations." Once the attackers obtained access tokens from Haruko, the true determinant of loss limits was no longer the words "read-only," but whether the client side had filled in the most basic protective measures—whether access tokens were rotated on schedule, interfaces meticulously power-separated, and whether additional access controls were applied to key accounts.
CoinDesk quoted sources stating that small hedge funds with weaker security controls might have lost minor amounts of money or assets as a result, and this statement itself indicates the differences in security baselines based on outcomes. Information to be verified suggests that among the 15 affected clients, many accounts did not have inbound IP whitelisting configured (to be verified), although Haruko had previously recommended that clients enable this configuration (to be verified); if true, then the reason the "read-only data leak" could be converted into tangible risk largely stems from the fact that these basic configurations, which were originally to be handled by the client side, had long been shelved in the backlog. As of now, public information has not disclosed the specific identities and amounts of loss of each institution, and the regulatory-level disclosures and complete technical details from Haruko have yet to be released. However, from the focus of existing reports, it is clear: on the same supply chain, the weaker the security budgets and process management of one link, the more prone it becomes to being singled out in the event of an incident, and the harder it is to prove afterwards that they were merely a "collateral victim" rather than a "participant in exposing the attack surface."
The Invisible Supply Chain Risks Connecting Multiple Exchanges Were Ignited
Tracing one layer up along this chain, Haruko, as a crypto technology service provider, is itself the central node of institutional infrastructure: headquartered in London, its business is to help institutional clients connect multiple centralized exchanges and on-chain infrastructure, consolidating dispersed accounts, strategies, and risk controls into its systems. Information pending verification suggests it may serve over 80 clients globally, connecting more than 100 exchanges, 30 blockchains, and 250 on-chain protocols (to be verified), meaning that as soon as an issue arises at this level, the affected scope naturally extends beyond any single exchange or account to the entire access network.
This attack targeted Haruko's infrastructure directly rather than a specific exchange or individual institutional account, with attackers acquiring access tokens through vulnerabilities in its systems and then utilizing this "bus" to reach the read-only APIs of multiple centralized exchanges. At least 15 institutional clients were simultaneously exposed to the same attack surface. The "outsourced hub" that was selected to enhance access efficiency and unify risk control, when the vulnerability was triggered, transformed into a supply chain risk: this single point of failure for the service provider bound originally isolated institutions together on a security level. Thus, this incident has been repeatedly discussed within the industry—not because of how exaggerated the loss figures are, but because it clearly delineated an equation: under this highly centralized access model, service provider security equals client security, raising the pressing question of who will conduct security assessments of the supplier and to what granularity, which is transforming from a neglected detail to an essential question in the institutional risk framework.
The New Bottom Line for Institutional Security from the Haruko Lessons
The Haruko incident at least provided a reference answer to this question: security boundaries cannot be drawn solely around one's own system, and all technical service providers holding access tokens and controlling access paths must be included within the same risk perspective. Haruko's actions post-incident to repair the exploited security vulnerabilities and refresh the server-side keys essentially served as a belated “master switch” for itself and its clients, but it also highlights that there was previously insufficient attention paid to foundational controls such as read-only tokens, permission levels, and IP whitelisting. For institutions, the generation, storage, and rotation mechanisms for access tokens, minimal configurations for read/write permissions, which IPs can reach exchange interfaces, and due diligence on service providers' security capabilities and emergency processes can no longer be viewed as outsourced matters that can simply be delegated to suppliers, nor can they be assumed to be risk-free just because the interface is labeled as read-only. Amid the uncertainty surrounding the identity of the attacker, technical details remaining undisclosed, and an ongoing investigation, this incident is regarded within the industry as a cautionary tale regarding supply chain security, indicating that similar attacks are likely to continue occurring. Institutions and service providers need to establish a more transparent framework for security collaboration—from contract terms to audit rights and emergency response mechanisms—truly establishing the actionable bottom line that "service provider security = client security."
Join our community to discuss together and become stronger!
Exclusive Hyperliquid benefits for AiCoin: https://app.hyperliquid.xyz/join/AICOIN88
Exclusive Aster benefits for AiCoin: https://www.asterdex.com/zh-CN/referral/9C50e2
On-chain Telegram community: https://t.me/AiCoinWhaleData
On-chain community: https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin on-chain Twitter: https://x.com/aicoinwhaledata
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
