Haruko 不是普通 retail exchange，也不是用户钱包。
它属于 institutional crypto infrastructure layer，为 hedge funds / institutions 提供：
- portfolio aggregation；
- risk management；
- trading data；
- CEX connectivity；
- custody connectivity；
- on-chain / DeFi monitoring。
这次 targeted cyberattack 影响 15 个 clients，说明第三方 infrastructure 一旦被攻破，可以在 underlying exchange 本身没有被 hack 的情况下，把多个 institution 的数据和权限暴露出来。
Haruko 的 Attack Path
根据 Haruko CTO 发给 clients、并被媒体查看的信息，当前 sequence 是：
- attacker exploit Haruko 某个 process vulnerability；
- 取得一个 user-access token；
- 通过该 token 读取 process memory；
- memory 中可能包含 read-only exchange API details 与 trading data。
Haruko 把自己定义为 targeted entity，而不是某个 specific customer 被直接攻破后横向扩散。
为什么是 15 个 Client？
Haruko 表示受影响数量为：
15 clients
报道进一步称，这些 affected clients 没有在相关 API connection 上使用足够严格的 IP whitelist protection。
这里有一个非常重要的 control concept：
API Permission Scope 与 Network-Origin Restriction 是两个不同层。
Read-only key 即使不能直接 withdrawal，也可能：
- 暴露 position；
- 暴露 balance；
- 暴露 strategy；
- 暴露 account / venue map；
- 给 attacker 提供后续 attack intelligence。
如果其他 surrounding controls 弱，它甚至可能间接变成 fund loss。
Client Password 被偷了吗？
Haruko 给 clients 的信息称：
客户自己系统的 login credentials 没有被 compromise。
被拿走的是 Haruko infrastructure 内的 access token。
所以 incident response 不能只改 employee password，还需要处理：
- Haruko token；
- exchange API key；
- IP whitelist；
- server-side secrets；
- integration credential。
到底损失多少钱？
知情人士称部分 smaller hedge-fund clients 可能有少量 fund loss。
但目前没有：
- reconciled dollar amount；
- official client-by-client loss table；
- Haruko final loss number。
因此 CEXVia 只能写：
Financial Loss — Developing / Unquantified
不能为了 headline 随便写一个金额。
不是所有 Haruko Clients 都被影响
Haruko website 会列出一些 customers，但不能因为公司是 Haruko client 就写成“被 hack”。
目前：
- GSR 表示未受影响；
- 3iQ 表示未受影响；
- 3iQ 特别提到它使用 IP whitelist，因此 API access 不在 compromised environment 中可用。
这是很好的 layered-security 实际案例。
“Read-Only”为什么仍然敏感？
Read-only trading / exchange data 可能包含：
- balances；
- positions；
- execution history；
- strategy timing；
- venues；
- margin structure；
- account identifiers。
Attacker 可以利用这些信息做：
- spear phishing；
- social engineering；
- front-running / strategy copying；
- credential attack；
- extortion；
- 针对其他 integration 的二次攻击。
Haruko 做了什么？
Haruko 对 clients 表示：
- vulnerability 已 fixed；
- server-side secrets 已 refresh；
- 建议使用 inbound IP whitelist；
- 将发布 full technical post-mortem。
真正关键的是 post-mortem 要回答：
- vulnerability 在 code 还是 infrastructure？
- token 为什么可以从 memory 被读取？
- affected process isolation 是否不足？
- bare-metal / deployment model 是否贡献 risk？
- compromised token lifetime 多长？
Third-Party Infrastructure Concentration Risk
Institution 越来越依赖一个 platform 连接：
- 100+ exchanges；
- custodians；
- 30 blockchains；
- hundreds of protocols。
这类 provider 即使没有 withdrawal authority，也仍然是高价值 target。
更好的 design 应同时有：
- least-privilege API；
- IP whitelist；
- short-lived tokens；
- HSM-backed secrets；
- memory isolation；
- per-client segmentation；
- rapid rotation；
- audit logs。
Evidence Status
Company Messages Reported
- 15 clients；
- process vulnerability；
- access token stolen；
- process-memory exposure；
- vulnerability fixed；
- secrets refreshed；
- post-mortem planned。
Media / Developing
- 部分 funds lost；
- exact amount unknown；
- exposed dataset unknown；
- full root cause pending。
Client Statements
- GSR not affected；
- 3iQ not affected，并明确提到 IP whitelist。
Risk Assessment
High Institutional Infrastructure / Supply-Chain Risk。
What to Watch Next
Haruko post-mortem、client loss、API rotation、affected-client notification、privacy/regulator reporting，以及 old access token / secrets 是否全部 invalidated。
FAQ
多少 Haruko clients 被影响？
15 个。
客户自己 password 被偷了吗？
Haruko messages 称没有。
暴露什么数据？
Process memory 可能包括 read-only exchange API details 和 trading data。
有资金损失吗？
部分 smaller clients 据报有，但没有 final amount。
为什么 IP whitelist 有用？
即使 key 泄露，也限制它只能从 approved network location 使用。
Vulnerability 修了吗？
Haruko 说已修复并 refresh secrets，但 full post-mortem 仍未发布。