本周早些时候，总部位于伦敦、专门为机构客户提供加密基础设施接入和技术服务的 Haruko，发现自己成了枪口正对的那一环——据 CoinDesk 9 月 18 日报道，一次针对其自身基础设施的定向网络攻击，撕开了它与客户之间看似安全的接口边界。攻击者利用 Haruko 系统中的安全漏洞，悄悄提取了部分机构客户的访问令牌（access token），借此登录这些客户在多家中心化交易所配置的只读 API 接口，读取原本只在后台流转的账户数据和交易信息。多位知情人士称，共有 15 家机构客户被波及，其中安全控制较弱的小型对冲基金，已经因此出现少量资金或资产损失的迹象。名义上并不具备“动账”能力的只读权限，被绕道变成了攻击者的情报入口，服务商的一次失守，顺着供应链直接压在了客户头上，逼迫整个行业重新面对一个不情愿承认的现实：在这种连接高度耦合的架构下，服务商的安全边界和客户的资产安全根本分不开，“只读权限也可能致损”不再是理论风险，而是已经发生的事故。
从服务商到破口：Haruko基础设施如何被打穿
在CoinDesk的报道里，这起事件被多位知情人士明确描述为“针对Haruko自身的定向攻击”，而不是某一家粗心客户的孤立事故。攻击者先把突破口选在服务商一侧，利用Haruko基础设施中的安全漏洞，绕开了客户表面的防线。顺着这道裂缝，他们从Haruko的系统中提取出部分机构客户的访问令牌，再用这些令牌去调用客户在多家中心化交易所配置的只读API接口，把原本只在后台流转的账户只读信息和交易数据，成批拽到自己面前。据公开信息，攻击者拿到的是读权限，而不是可以直接下单、提币的写接口，但至少15家机构客户的敏感交易画像因此暴露，有安全控制较弱的小型对冲基金被指出可能出现少量资金或资产损失。
对Haruko而言，这不是谁的“配置错误”，而是一整套基础设施被证明存在可被武器化的薄弱环节。事件被内部或外部监测发现后，Haruko开始紧急“自救”：修复被利用的安全漏洞，刷新服务器端密钥，试图在同一路径被反复踩踏之前先把门重新锁上，并与受影响客户沟通，提醒他们关注潜在风险。公开报道同时强调，攻击者身份、攻击团伙背景以及漏洞的技术细节尚未披露，具体损失规模也没有对外给出明确数字，这意味着即便第一时间的补丁已经打上，这条曾被打穿的服务商通道究竟留下了多深的隐患，还只能在后续的调查和处置中慢慢被挖出来。
只读API失守，为何仍然会流血
从公开报道看，这次被打穿的，并不是能直接下单、提币的高权限接口，而是客户在中心化交易所配置的只读API信息和交易数据。换句话说，攻击者手里拿到的是机构账户的“望远镜”：看得见，却碰不到钱。但对习惯在后台拉报表、对账、风控的机构来说，这副望远镜里装着的是全部日常动作——下单节奏、交易对偏好、典型持仓周期、仓位集中度，乃至某些策略的大致轮廓。一旦被陌生人长期、系统性地窥视，这些原本只在风控会议室里出现的敏感图表，就被平摊在攻击者的案头。即便目前没有公开证据表明攻击者直接掌控了受影响账户的交易或提币权限，但至少可以确定的是，15家机构客户的只读数据被访问，这为任何后续基于情报的攻击打开了一个极具价值的入口。
CoinDesk引述多位知情人士称，安全控制较弱的小型对冲基金客户，可能在这次事件中损失了少量资金或资产，尽管具体路径和数额尚未披露。行业内对这种“只读泄露如何变成真金白银损失”的解释，多半依赖通用安全逻辑：掌握了某家机构的持仓结构和交易习惯，就有可能在其他接口、其他账户或其他场景中有的放矢地设计钓鱼、社工或市场对手盘行为，而安全投入不足的小型机构，恰恰是最难承受这种“情报加成”的一环。Haruko事件于是成为一个鲜明注脚：把只读权限当成绝对安全的前提，在服务商发生安全漏洞、而自身风控又薄弱的环境下，很容易在事后被证明只是一个自我安慰的假设。
中小对冲基金的安全短板在这起事件中被放大
在 Haruko 这次事故里，被放大的首先不是技术细节，而是结构性的资源差距。大型机构可以为安全单独立项，有专职团队盯着访问令牌生命周期管理、接口权限分级、异常行为告警；很多中小对冲基金则把这些工作外包给“供应商默认配置”。当攻击者从 Haruko 那里拿到 access token 之后，真正决定损失上限的，已经不再是“只读”这三个字，而是客户侧有没有把最基础的防护环节补齐——访问令牌是否按周期轮换、接口是否被精细分权、关键账户是否做了额外的访问控制。
CoinDesk 引述知情人士称，安全控制较弱的小型对冲基金客户可能因此损失少量资金或资产，这个表述本身，就是在用结果倒推安全基线的差异。有待验证的信息称，本次受影响的 15 家客户中，不少账户并未配置入站 IP 白名单（待验证），而 Haruko 此前曾向客户建议启用这一配置（待验证）；如果属实，那么“只读数据泄露”之所以能被转化为实质风险，很大一部分是因为这些原本应由客户侧承担的基础配置，被长期搁置在 backlog 里。截至目前，公开信息尚未披露各家机构的具体身份和损失金额，监管层面的披露和 Haruko 官方的完整技术细节也仍未公布，但从现有报道的聚焦点可以看出：在同一条供应链上，安全预算和流程管理越薄弱的那一环，越容易在事故中被点名，越难在事后证明自己只是“陪跑的受害者”而不是“开放攻击面的参与者”。
连接多家交易所的隐形供应链风险被点燃
沿着这条链往上追一层，Haruko 这种加密技术服务商本身就是机构基础设施的中枢节点：总部在伦敦，业务就是帮机构客户打通多家中心化交易所和链上基础设施，把原本分散的账户、策略和风控，集中接到自己的系统里。有待验证的信息称，它可能为全球超 80 家客户提供服务，连接 100 多家交易所、30 条区块链和 250 个链上协议（待验证），这意味着，只要它这一层出问题，波及范围天然不再是某一家交易所、某一个账户，而是整条接入网络。
这次攻击的直接对象正是 Haruko 的基础设施，而不是某家具体交易所或单一机构账户，攻击者通过其系统中的安全漏洞拿到访问令牌，再顺着这条“总线”去触达多家中心化交易所的只读 API，至少 15 家机构客户被同时暴露在同一攻击面之下。原本为了提升接入效率、统一风控而选择的“外包中枢”，在漏洞被触发时反向放大成供应链式风险：服务商这一单点故障，让原本相互隔离的机构在安全层面被绑在一起。也因此，这起事件被行业拿来反复讨论——不是因为损失数字有多夸张，而是它清晰地写出了一个等式：在这种高度集中化的接入模式下，服务商安全被等同于客户安全，谁来为供应商做安全审查、做到什么粒度，正在从被忽视的细节变成机构风险框架里的必答题。
从Haruko教训看机构安全的新底线
Haruko 事件至少给出了这道题的一个参照答案：安全边界不能只画在自家系统上，所有握着访问令牌、掌握接入路径的技术服务商，都必须被纳入同一套风险视野。Haruko 在事后修复被利用的安全漏洞并刷新服务器端密钥，本质上是在给自己和客户补上一道迟来的“总闸”，但也说明此前对只读令牌、权限分级和 IP 白名单等基础控制的重视程度远远不够。对机构而言，访问令牌的生成、存储与轮换机制，读写权限的最小化配置，哪些 IP 可以触达交易所接口，以及对服务商端安全能力和应急流程的尽职调查，都不能再被视作“交给供应商就好”的外包事项，更不能因为接口被标注为只读就被默认为零风险。在攻击者身份、技术细节尚未公开、调查仍在进行的前提下，这起被行业视作供应链安全警示案例的事件，至少预示着类似攻击还会继续出现，机构与服务商之间需要从合同条款、审计权利到应急联动机制建立更透明的安全协作框架，把“服务商安全=客户安全”真正落成可执行的底线。
加入我们的社区，一起来讨论，一起变得更强吧！
AiCoin专属Hyperliquid福利：https://app.hyperliquid.xyz/join/AICOIN88
AiCoin专属Aster福利：https://www.asterdex.com/zh-CN/referral/9C50e2
链上电报（Telegram）社群：https://t.me/AiCoinWhaleData
链上社区：https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin链上推特：https://x.com/aicoinwhaledata
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
