首发GCSA 洞察全球网络安全联盟

GCSA洞察：KuCoin交易所身份遭冒用、Bitkub交易所投毒风险与Avalanche百万美元漏洞

KuCoin交易所身份遭冒用 Bitkub交易所投毒风险与Avalanche百万美元漏洞

前言

从交易所品牌钓鱼、恶意程序投放，到 AI 工具供应链风险与百万美元智能合约漏洞，近期多项安全事件与风险线索接连浮现。攻击者不仅可能利用代码缺陷转移资产，也可能通过伪造官方身份或控制软件依赖，将威胁隐藏在用户信任的操作流程之中。

全球网络安全联盟（Global Cybersecurity Alliance，GCSA）通过威胁情报 Agent 监测、独立技术取证与链上交易追踪，对涉及 KuCoin、Bitkub 及 Avalanche 生态的安全事件与潜在风险展开调查，形成三份独立技术分析报告。

在 KuCoin 邮件安全调查中， GCSA 发现攻击者冒用 [email protected] 发件身份，通过仿冒安全中心诱导用户下载疑似远程控制程序。调查同时发现 ku.com 域名存在 DMARC 配置缺失问题。经 GCSA 通报，KuCoin 安全团队确认该问题，并反馈已完成整改，启用 DMARC 隔离策略。

在 Bitkub AI 工具调查中， GCSA 发现其官方文档曾引用的 MCP 工具包在原版本下架后，npm 包名被第三方账号重新注册。未固定版本的安装方式，加上可能明文保存的 API 密钥，使用户面临潜在的软件投毒与凭据泄漏风险。目前尚未发现实际窃取密钥的证据。

在 Avalanche 生态调查中， GCSA 通过链上追踪与合约反编译，还原了 TranchePool 金库因跨日结算逻辑缺陷遭利用的过程。攻击者借助闪电贷与重复提款，在约 202 秒内完成两笔交易，转出约 101.34 万 USDC。该事件属于生态内智能合约漏洞，并非 Avalanche 底层网络遭到攻击。

三项调查涵盖身份伪造、软件供应链风险及智能合约缺陷，涉及不同的攻击机制与证据层级。其中既有已识别的钓鱼攻击，也有尚未证实实际利用的风险，以及已经造成资金损失的合约漏洞。

这些发现表明，数字资产安全风险不仅存在于底层协议，也隐藏在官方邮件、AI 工具依赖及合约业务逻辑之中。

本着负责任披露的原则，GCSA 已通过官方渠道向相关平台通报安全线索并提供技术分析报告。截至发稿时，KuCoin 已反馈核查结果并确认完成相关邮件安全配置整改；Bitkub 尚未回复。

GCSA 现公开三份独立技术调查报告，保留原始分析与关键证据，供业界核查参考，并将根据新增证据及相关方反馈持续更新研究结论。


【一】KuCoin官方邮箱投毒钓鱼分析

近日，我们的威胁情报 Agent 监测到针对 KuCoin 用户的钓鱼邮件攻击，也有客户向 GCSA 反馈收到了这类邮件。有趣的是，邮件显示的发件地址是 [email protected]，用的正是 ku.com 官方域名，收件箱中显示的发件人名称为 KU Security Center。这封信声称用户账户出现异常，催促用户按照邮件中的指引处理。一个带着官方域名的发件地址，让这些要求看起来像是交易所发出的安全通知。我们把收件箱中的发件信息与邮件原文放在一起核对，发现显示的官方身份和实际投递来源并不一致。调查的重点因此转向了邮件认证：攻击者使用自己的发信设施投递，却把官方地址放在用户看到的位置。我们接着查看收信系统留下的认证记录，核对通过认证的域名与这项官方身份之间的关系。

1. ku.com 发件地址伪造

我们查看邮件原文，SPF

 和 DKIM（邮件签名认证）都显示通过。但认证结果对应的是 ku-security.com，发件人字段 From 里.写着的却是 [email protected]。再看投递信息，退信地址是 [email protected]，投递主机是 mail.ku-security.com。SPF 检查使用的是退信地址中的域名，攻击者可以授权自己的服务器发信，从而通过这一项检查。DKIM 使用的也是攻击者自己的签名域名，连写着官方地址的 From 字段一起被签入了邮件。收信方验证这份签名时，用的也是钓鱼域名公布的公钥。攻击者控制投递服务器，就能自己填写 From，伪造这个字段不需要先取得官方邮箱的登录权限。

3RusM3XVoldSWr5DileKBbaouvf06QeOXDtgw88F.jpeg图1邮件原文。From写为[email protected]，实际由ku-security.com投递。

2. ku.com 的 DMARC 配置缺失

2026 年 10 月 29 日，ku.com 没有 DMARC 记录。DMARC 会把已通过 SPF 或 DKIM 认证的域名，与 From 中显示的域名放在一起核对。至少有一项认证通过并且域名对齐，邮件才通过 DMARC 检查。本案里，投递与签名都使用钓鱼域名，From 却使用官方域名。缺少这项记录，收信方就查不到官方域名针对对齐失败邮件声明的隔离或拒收要求。ku.com 的 SPF 以 ~all 结尾，对未授权来源标记软失败。不过，这封信接受 SPF 检查时，使用的是钓鱼域名的授权记录，官方域名的这条规则没有用来核对它的投递。收紧这条 SPF 规则，也不会自动补上针对 From 的域名对齐检查。kucoin.com 同一时期的 DMARC 策略为 quarantine（隔离），它的策略作用于自己的发件域名，不会自动覆盖另一个独立注册域名。

3. 仿冒安全中心与远控样本分析

邮件主题是「【KuCoin】请立即查看资金安全」，正文按钮写着「立即前往安全中心」。Gmail 显示的发件地址为 [email protected]，投递域名为 ku-security.com。正文要求马上核对近期登录、提币与安全设置，把账户异常写成需要立即处理的事项。这封钓鱼邮件里还写着防诈骗提醒，声称交易所不会来电，也不会索取验证码、密码或谷歌验证码。它要求用户停止邮件之外的转账和验证码请求，只在安全中心联系客服；确认完成前，也不要通过其他渠道继续操作。落款注明系统邮件、请勿回复。防诈骗提醒在这里成了引导用户点击按钮的理由：邮件让人警惕外部联络，却把自己的入口当作核查账户的去处。

3N1qMOaNRzcndNj3lFr4WeE7wvZHWWj5D1klARiG.jpeg图2客户收到的钓鱼邮件。发件人显示为[email protected]，通过ku-security.com投递。

客户提供的页面截图里，下一步已经变成了选择 Windows 或 macOS。邮件说要核对登录、提币与安全设置，到了仿冒的 KuCoin 安全中心，用户却要先选电脑系统。页面把这个动作解释成「在对应环境里完成确认」，并用「请现在就完成选择」催促用户继续。截图展示的是系统选择入口，没有列出要核对的登录记录或提币信息。要继续所谓的确认，收件人先得接受从页面获取文件这项要求。邮件里的防诈骗口吻也被带到了网页上，底部继续提醒用户停止页面以外的转账或提供验证码行为，要求在当前页面内完成处理。交易所标识与客户支持文字都留在页面中，而需要用户执行的操作已经从查看账户变成了选择下载文件。

EQHnopDKmkmD2Zq6yJacwnYnX2SUrAnpuIKCgZVP.jpeg

图3仿冒的KuCoin安全中心页面，要求选择Windows或macOS

我们对一份 Windows 文件做了静态分析。这个 9,764,352 字节的程序保留了编译信息，模块名直接写着overlord-client；继续查看文件中的函数名，还能找到overlord-client/cmd/agent/config.Load，对应 Overlord 源码里的配置读取函数。截屏模块也留下了CaptureAndSend函数名，与源码中的实现名称一致。我们又核对了程序里的控制连接格式，它同样出现在 Overlord 客户端源码中。据此，我们确认这份 Windows 文件是 Overlord 远控客户端。

Windows 样本地址为https://ku-security.com:5173/api/file-share/290924a0-2064-477f-b0dd-0cbfd6fa18ab/download，SHA-256 为3beb5f5fa9e01b382b79c152a6eb14b096e1ef0fabbc1ab6faf6b19326899d21。macOS arm64 样本地址为https://ku-security.com:5173/api/file-share/e9daf83a-5bf2-4d72-a98e-deece8984e87/download。Windows、macOS arm64、macOS amd64 三份样本内的回连地址均为wss://3.1.159.255:5173，控制连接地址为wss://3.1.159.255:5173/api/clients/{id}/stream/ws?role=client。连接使用 TLS（传输层安全协议），端口为 5173。ku-security.com 已解析到同一台机器，二进制里没有wss://ku-security.com:5173。

wUpjCRw4147Gx2S8QWFGjV6AUV4VQBdTtHQ9mrmI.jpeg

图4Windows文件的静态分析证据：模块名、函数名、连接字符串与文件偏移。

4. 其他邮件钓鱼案例

2023 年 11 月，攻击组织 Kimsuky 冒充记者，向专家发送采访邮件。邮件的发件地址用了没有部署 DMARC 的媒体域名，收件人的回复却被引向攻击者的账号。美国联邦调查局、国家安全局和国务院在 2024 年 5 月 2 日发布的联合通报 JCSA-20240502-001，附有这些邮件的发件信息和 Gmail 认证结果，隐去了媒体名称。英国税务海关总署则从 2016 年开始部署 DMARC。英国政府在 2018 年 6 月 30 日公布，该机构已拦截约 5 亿封钓鱼邮件。

2024 年 1 月 23 日，邮件服务商 MailerLite 的员工账号被盗用，攻击者借此使用该服务商客户的账号，发送针对加密钱包的钓鱼邮件。受影响的客户账号数从 117 个修正为 70 个，其中 4 个被用于发送钓鱼邮件。MetaMask 2024 年 2 月月报提到 Cointelegraph、WalletConnect 等受影响品牌，当时报告的损失超过 58 万美元。慢雾在 2025 年 5 月记录了冒充 Coinbase 客服的骗局：攻击者通过电话、短信和伪造邮件，诱导用户把资产转到攻击者的钱包。报告还提到了伪造官方发件地址的工具。

693fqOhOB3xNHsRGX1L3IVINYamUuHFJXztYRvmF.jpeg图5邮件钓鱼案例机制示意：Kimsuky伪造发件地址，MailerLite案例涉及发信账号被盗用。

5. 发信域名的 DMARC 配置建议

负责邮件系统的团队应先盘点企业持有的域名，分别检查各自的 DMARC 记录。正在发信的域名，要拿实际业务邮件核对认证结果，外部服务商代发的邮件也要纳入检查。如果先用 p=none 收集认证报告，就要根据报告排查发信来源；这项策略只用于监测，不会要求收信方隔离或拒收邮件。确认合法业务邮件能够通过检查后，再启用 quarantine（隔离）或 reject（拒收）。已经停用且没有合法发信需求的域名，也应发布拒收策略。上线后，通过认证报告排查未经授权的发信来源，同时检查正常业务邮件的退信记录。更换邮件服务商或新增代发渠道时，重新核对实际邮件的认证结果。

6. 用户防范建议

收到“账户异常”或“资金安全”邮件，不要只凭发件地址里的官方域名判断真伪。先不要点邮件中的链接，直接打开平时使用的官方 App 核实，也不要按邮件要求安装所谓的安全程序或接受远程协助。已设置防钓鱼码的，核对邮件中的码；密码、验证码、助记词和私钥都不要交给来信者。误点后关闭页面，不再输入信息或下载文件。运行过下载程序的，先断开这台设备的网络。如果已在可疑页面输入密码或验证码，或运行过程序，换一台未接触这些内容的设备，从官方 App 修改密码、退出其他登录，并检查近期提币记录。保留原始邮件、下载链接和异常记录，通过官方 App 联系客服排查。

fjJNezBHgLqTE7vnYb8MWsfvpvaPWxN67lwBfLtH.jpeg图6可疑邮件的处理步骤：未点击、已点开、输入过密码或验证码、运行过程序

【二】Bitkub官方AI工具被冒用，用户面临投毒风险

2026 年 10 月 31 日，GCSA 安全 Agent 在日常巡检中发现，Bitkub 官方 API 文档中引用的 MCP 工具包 bitkub-trading-mcp-official 已被第三方账号 rd09 接管。该包原版由 Bitkub 发布，后被从 npm 下架但未收回包名，冷却期结束后 rd09 于 10 月 3 日注册并发布 1.0.1 版本。按照 Bitkub 官方教程配置过 AI 助手的用户，API 密钥以明文写在 ~/.claude.json 中，每次启动都会被注入环境变量。即使当时运行报错退出，密钥仍留在磁盘上——发布者随时可以推送一个带窃取脚本的新版本，在用户看到程序界面之前就把密钥读走。


事件经过

Bitkub 在官方 API 文档仓库中提供了一键安装命令，指导用户通过 Claude 等 AI 助手查询行情和管理交易账户。配置时需填入 API Key 和 Secret，命令如下：

claude mcp add bitkub-trading-mcp-official \
  -e BITKUB_API_KEY=your_real_key_here \
  -e BITKUB_API_SECRET=your_real_secret_here \
  -- npx -y bitkub-trading-mcp-official

TUvW85bV5SNJ0CYbRnWb1EDooWhMkMyVzWNZsONA.jpeg图 1：官方教程中的配置界面，包含账户密钥和未固定版本的启动命令

Bitkub 曾发布 1.0.2（2026-07-23）和 1.1.0（2026-08-18）两个版本，后将安装说明放入 HTML 注释中隐藏，并将所有版本从 npm 下架，但未收回包名，也未通知已配置用户。按 npm 规则，包名在冷却期结束后对所有人开放注册。2026 年 10 月 3 日，第三方账号 rd09 注册了该包名并发布 1.0.1 版本，成为 npm 上该包名的唯一发布者。

T5V5iyZZn8dlSIxlKU9qJPtXsfbR5bkve6BtKMB4.jpeg图 2：旧版指向 Bitkub 官方仓库，当前默认版本已由 rd09 发布

GitHub 页面的 Preview 视图已看不到安装命令，但通过 raw 链接、git clone 或 GitHub API 仍能读到完整内容。用户此前保存到本地的配置更不会自动失效。

为什么会有风险

当前 1.0.1 版本只有 263 字节的 package.json，没有可执行文件，npx 运行时会报错退出。问题出在 npm 的安装机制和配置的持久化方式上——报错退出不等于没有执行任何代码。

a0J40GUufa7BR6uuoMRzDnH9nfMEXoBqvde8wmCT.jpeg

图 3：启动设置同时决定运行哪个程序，以及是否向它传入账户密钥

安装脚本先于程序执行

npm install 的流程是：解压 → 执行 preinstall/postinstall 脚本 → 解析入口文件。脚本执行阶段和入口校验是解耦的：即使包内没有有效的可执行文件，preinstall 或 postinstall 脚本也已在安装时运行完毕。rd09 只需推送一个带脚本的新版本，一行 process.env.BITKUB_API_KEY 就能在安装阶段取走密钥。密钥被读取发生在程序启动之前，你连报错都还没看到。

密钥以明文持久化在本地

claude mcp add 命令将 -e 参数中的键值对写入 MCP 配置文件（~/.claude.json 或项目目录下的 .mcp.json）。配置一旦写入，密钥就以明文形式留在磁盘上。即使当时安装的包是空壳，下次启动 AI 助手时凭据仍会被重新注入环境变量。从你敲下那条命令到现在，每一天都是攻击窗口。

npx -y 不验证发布者

npx -y 只按包名查找 dist-tags.latest 指向的版本，-y 跳过的是安装确认提示，不是来源校验。它不会检查 maintainer 是否为 Bitkub，也不会验证包内是否有可执行文件。缓存失效后拉到的就是 rd09 的版本。npx 不会告诉你下载的不是 Bitkub 的代码。


恶意版本可能造成什么后果

密钥带有交易权限时，恶意程序可直接调用 /api/v3/order/create 以市价卖出全部持仓，或调用 /api/v3/user/info 读取余额与历史订单。这些请求在毫秒级完成，用户看到异常时资产已经转移。即使密钥只有查询权限，程序仍能遍历 ~/.ssh/、~/Library/Keychains/、浏览器 cookie 数据库和同目录下的 .env、.mcp.json，打包上传到远程服务器。把交易密钥设为只读并不能阻止这一行为。提现受平台风控限制，但下单和信息读取不受此限。

3S0VZ6lNXlXRYEGyaLVTTcJj3C01ZLsJ8CLp8nJT.jpeg图 4：恶意程序可能利用密钥下单，也可能读取电脑文件


你现在应该做什么

1. 禁用 AI 助手中的 Bitkub 连接

打开 Claude 或其他 AI 助手的 MCP 工具设置，找到 bitkub-trading-mcp-official 条目，删除或禁用。

2. 手动删除本地配置中的密钥

仅禁用工具不会清除已保存的密钥。先运行grep -r "BITKUB_API" ~/.claude.json .mcp.json确认密钥是否残留，再打开以下文件删除相关配置段：

  • ~/.claude.json
  • 项目根目录下的 .mcp.json

3. 吊销并更换 Bitkub API 密钥

登录 Bitkub，进入 API 管理页面，吊销旧密钥并生成新密钥。新密钥不要再用同一条命令配置。

4. 核查账户活动

重点核查 2026 年 10 月 3 日至今的所有订单、提币记录和登录日志。发现异常立即联系 Bitkub 客服并冻结账户。

5. 排查本地其他敏感信息

如电脑上保存过其他交易所、钱包或服务的密钥文件，建议一并更换。

nGFCCF8aqMWyDKgdA3DHvt1tiXA61k7lOv452FSq.jpeg图 5：用户停用旧连接并排查影响；Bitkub 取回包名，更新安装指引

补充说明

npm 平台的包名释放机制

npm 平台有包名释放机制：原发布者撤下所有版本后，包名在冷却期结束后对所有注册用户开放。问题在于 Bitkub 未在撤下旧版前收回包名或更换新名称，也未及时更新文档引导用户迁移。教程从页面上消失不代表风险消失，已配置用户的本地密钥仍然暴露，而平台没有通过任何渠道通知存量用户检查或迁移。

rd09 账号的行为模式

该账号名下有 12 个包，多数与已有机构包重名且只有空壳 package.json。其中一个包（ably-bulk-subscriber）带有 postinstall 脚本，自报为 Dependency Confusion PoC：执行后将 process.env 全量写入 /tmp/dc-poc-test.json，并在控制台打印 "Dependency Confusion PoC — env captured"。任何拿到这段代码的人只需把写入路径改为远程 URL，就完成了从 PoC 到真实窃密的改造。

后续使用建议

今后使用 npm 包前确认发布者为官方组织，启动命令中指定版本号而非依赖 latest。定期排查已配置工具和对应包的状态，密钥权限遵循最小原则，不给不必要的交易或提现权限。

【三】Avalanche TranchePool 101 万美元会计漏洞分析

前情提要

涉事合约是 Avalanche C-Chain 上的一只 Tranche Vault，以 USDC 计价，按 tranche 分别记录存入和已提。攻击前金库余额 1,013,353.611686 USDC，正好等于 tranche 0 尚未提走的部分（存入 3,000,000，已提 1,986,646.388314）。攻击分两笔，相隔 163 个区块、202 秒，中间跨过一次 UTC 零点：

时间（UTC）区块交易动作
2026-10-27 23:56:41987314430x19ab…99fd从 Aave V3 闪电贷借入 1,013,353.611686 USDC，新建 tranche 1，存入同额并当天提回，与金库净额为 0；随后还贷 1,013,860.288492 USDC
2026-10-28 00:00:03987316060x3f6b…8c77跨过零点后，用与第一笔相同的提款 calldata 再提 1,013,353.611686 USDC，金库余额归零


漏洞分析

漏洞合约为0xe25cb545bdd47a8ec2d08001cb5661b00d47621a。

根本原因在于金库将日切结算与提款额度检查绑定在同一个 tranche 记录上，且结算先于检查执行。每个 tranche 一条记录，同时存着存入金额、已提金额和日期；提款时用存入减已提得到可用额，不足本次金额就以错误串 15 回滚。而结算函数在日期变化时直接把已提清零，使同一条记录在跨日后重新给出全额可用额度。

提款时，函数0x8e27c105通过减法计算可用额：

v38 = 0x3db9(_tranches[v7[v16]].field2_0_15, _tranches[v7[v16]].field1_16_31);

field2_0_15是存入金额，field1_16_31是已提金额，0x3db9做减法。检查通过后把本次金额加到已提上。

4xQgCHoWM5AdLu4jyEzUWypXCao5qGwamY91rihE.jpeg图 1：Dedaub 反编译的提款函数，红框内是额度检查取值的两个字段

问题在于提款函数在算可用额之前先调用结算函数0x447c。该函数按日判断，记录日等于当前 UTC 日时整段跳过：

if (uint128(MEM[uint8.max + 1]) == _tranches[varg0].field1_0_15) {
    return ;
}

跨过零点才往下走，在下面的分支里直接把已提字段写成 0：

RcCu8csScqL3ZNuLEFkNUWA6JSnlPAWSnga460rS.jpeg图 2：日切分支把 field1_16_31 直接写成新值

由此有两个不变量被打破。其一，已提不是累计值而是可被日切重置的临时字段，因此同一笔存入在跨日后可以再次给出全额可用额度，无需任何新资金进入。其二，提款只核对 tranche 记录中的可用额，转账前不校验金库的实际 USDC 余额，重置出来的额度可以直接从公共余额兑现。

链上读数印证了这一过程。被提的是攻击中新建的 tranche 1：

时点日已提存入
第一笔后（98731443）179305920010133536116861013353611686
第二笔前（98731605）179305920010133536116861013353611686
第二笔后（98731606）179314560010133536116861013353611686

第二笔之前可用额是 0，第二笔付的却是全额。日字段换成当天，已提被结算清零，存入不动，同一个减法给出的可用额回到全额。结束时已提仍是原值——结算先于检查执行。这一机制对跨日有硬性依赖：同一段提款 calldata 用eth_call在块 98731500（10-27 23:57:41）回放，以错误串 15 回滚；在块 98731605（10-28 00:00:02）回放，返回 1,013,353,611,686；把金额改成 1,000 万，同样回滚 15。

tranche 0 的记录进一步印证了公共余额兑付的问题：存入 3,000,000、已提 1,986,646.388314，差额正好是 1,013,353.611686——与第二笔提走的金额逐位相等。攻击者第一笔用闪电贷存入并当天原额提回，净额为 0；次日零点后用同一段 calldata 再提一次，提走的就是金库原有的这笔钱。


攻击分析

以下分析基于交易 0x19ab…99fd（块 98731443）和 0x3f6b…8c77（块 98731606）。攻击者 EOA 0x6ff1…1246 通过自部署合约 0xf09d…7805 执行全部操作。

Step 1：攻击者调用攻击合约的0xea7b0dec，传入 Aave V3 Pool、USDC 和金额 1,013,353,611,686，合约向 Aave 发起 flashLoanSimple 借出等额 USDC。

Step 2：闪电贷回调 executeOperation 内，攻击合约先 approve 金库同额，随后依次对金库发起 5 笔调用完成建仓与当日提回：先以0xb1f70fbc和0x200634ba创建 tranche 1 的记录；再以0xcec66073触发 transferFrom 将闪电贷资金推入金库；接着以0x2d02d600写入到期日与金额；最后以0x8e27c105将同额 USDC 提回攻击合约。这 5 笔调用均使用金库的合法外部接口，但攻击者将其编排为“当日存入→当日全额提回”的特殊序列，使 tranche 1 的记录在回调结束前即呈现“已存=已提、可用额=0”的状态，为次日重放提款 calldata 埋下前置条件。

Step 3：回调结束前，攻击合约向 Aave 归还本金加利息共 1,013,860.288492 USDC（利息 506.676806）。第一笔交易结束时，金库余额不变，攻击者与金库之间净额为 0；但 tranche 1 的记录已被写入：存入 1,013,353,611,686，已提 1,013,353,611,686，当天可用额 0。

Step 4：202 秒后（块 98731606，已过 UTC 零点），攻击者调用攻击合约的0x767081d1，传入一段 804 字节 data。这段 data 与 Step 2 中第 5 笔调用的 calldata 逐字节相同，展开即0x8e27c105(1013353611686, … )；攻击合约不改写，原样 call 给金库。

Step 5：金库再次进入提款函数。按记录可用额为 0，但因已跨日，结算函数先于额度检查执行，将已提清零，检查随即通过。金库未校验 USDC 余额，直接向攻击合约转出 1,013,353,611,686，余额归零。

结论

本事件源于将日切结算状态与提款额度账本绑定在同一个字段上，且结算先于额度检查执行。已提金额不是累计值，跨日后被重置为零，使同一笔存入记录可以反复给出全额可用额度；而提款转账前不校验金库实际余额，重置出来的额度可以直接从公共池兑现。

协议不应让结算函数改写额度检查所依赖的字段。若需按日统计提款量，应另存一个日维度计数器，与累计已提字段分离。每个 tranche 的提款上限还应受该 tranche 实际投入资金的约束，而非仅凭账本记录从公共余额兑付。此外，应为日切、到期、展期等状态迁移编写不变量测试，确保sum(tranche.available) <= vault.usdcBalance()在任何迁移前后始终成立。

版权声明及免责声明

本报告及相关技术分析由 GCSA 全球网络安全联盟独家发布。如需转载请完整保留 GCSA 官方出处及原始链接，并不得对报告核心观点进行恶意篡改。

本报告仅供网络安全研究、技术交流及风险防范参考。相关分析基于发布时可获得的信息与证据，不构成对任何机构或个人的最终责任认定。GCSA 保留根据新增证据及相关方反馈更新研究结论的权利。

·欢迎关注GCSA以下社交媒体，我们会第一时间更新最新的动态

GCSA推特：x.com/gcsahk

GCSA Telegram频道：t.me/gcsaofficial

GCSA微信公众号：https://mp.weixin.qq.com/s/D3ctdy9JHXM68g-CGZCjUA

来源：GCSA全球网络安全联盟
官网：www.gcsa.org

返回文章列表联系 GCSA