雪磐研报:一枚 Owner 权限,引爆 9,900 万枚 TSR

Tessera 安全事件复盘

2026 年 6 月 1 日晚，北京时间 19:38 左右，BNB Chain 上的 Tessera 项目被卷入一场链上风暴。

几秒钟内，TSR 代币的命运被改写。

这不是一个典型的闪电贷攻击，也不是常见的重入漏洞，更不是复杂的价格操纵。攻击者做的第一件事非常简单：拿到一个关键合约的 owner 身份。

随后，9,900 万枚 TSR 被铸出并抛向市场，价格几乎垂直下坠。

事件开场：谁握着铸币钥匙

这起事件里有三个关键角色：

如果把这三个地址放进雪磐安全的链溯光里看，最先应该关注的不是单笔转账金额，而是权限关系：

TSR 代币合约 -> MINTER_ROLE -> VEA 合约 -> VEA owner -> Executor EOA 链溯光的价值在这里不是替代分析师下结论，而是把分散在合约日志、交易输入、代币事件和地址属性里的证据压缩成一张可复核的事件视图：谁控制了铸币入口，谁接过了 owner，谁在随后触发了 mint。

TSR 主合约本身并不是一个完全裸奔的合约。

它的 mint(address to, uint256 amount) 函数受 MINTER_ROLE 控制，并且设置了最大供应量：

uint256 public constant MAX_SUPPLY = 100_000_000 10*18; function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) { require(totalSupply() + amount <= MAX_SUPPLY, "Minting exceeds max supply"); _mint(to, amount); } 也就是说，攻击者不能直接调用 TSR 主合约随意增发。

真正危险的地方在另一层：VEA 合约拥有 TSR 的 MINTER_ROLE。

换句话说，谁能控制 VEA，谁就间接握住了 TSR 的铸币钥匙。

转折：一笔合法的 owner 转移

北京时间 2026 年 6 月 1 日 19:38:24，VEA Executor 发出了一笔关键交易：

transferOwnership(address newOwner) 交易哈希：

0xf799e7b0cdbccf843b2f13768a681c2e07479c8cf1c58452378bbbc2af7d2453 这笔交易把 VEA 的 owner 从：

0x61a23E0eBa09096fFEb954aa8A93c3079e87cF17 转给了攻击地址：

0x2201037A1755eC48eC5f00Fea21A10A9E56f2Dd8 链上事件日志显示：

OwnershipTransferred( previousOwner = 0x61a23E0eBa09096fFEb954aa8A93c3079e87cF17, newOwner = 0x2201037A1755eC48eC5f00Fea21A10A9E56f2Dd8 ) 这一步非常关键。

攻击者不是绕过了 onlyOwner 检查，也不是利用 Solidity 黑魔法强行改写了 owner。链上证据显示，原 owner 发出了一笔有效签名交易，把 owner 身份转给了攻击地址。

我通过历史状态读取确认：

owner 身份的变化，就发生在这笔 transferOwnership 交易里。

在链溯光的合约安全事件视图里，这一步会被标记为 Owner 权限变更。它本身不等于攻击成功，但在高权限合约上，owner 变更应该进入重点复核队列，尤其是：

1. 新 owner 是否为此前未出现过的地址。

2. 原 owner 是否为单点 EOA。

3. 变更后是否紧跟 mint、upgrade、pause、setMinter、grantRole 等高权限操作。

高潮：攻击者站上铸币机

拿到 VEA owner 身份后，攻击者立刻开始下一步。

北京时间 2026 年 6 月 1 日 19:38:25，攻击者调用 VEA 的：

mint(uint256 amount) 交易哈希：

0x25093e573c116562c8839dc67a15ac21761271006a8dfe50b18fa475564bfcd1 链上日志显示，TSR 合约产生了典型的 ERC20 铸币事件：

Transfer( from = 0x0000000000000000000000000000000000000000, to = 0x6f2b45B950d1739EF67C76F4106df6d6E84904cB, value = 99,000,000 TSR ) 也就是说，9,900 万枚 TSR 不是从某个用户账户里偷走的，而是从零地址新铸出来的。

随后，攻击者通过 VEA 执行后续交易，将这些 TSR 抛向市场。根据 Specter 披露，攻击者卖出获得约 240 万美元，并将资金转入 Tornado Cash。DEXScreener 上 TSR/USDT 池的 24 小时跌幅一度接近 -99.99%。

单看 TSR 代币合约，只会看到一条零地址 Transfer 铸币日志；单看 VEA 合约，只会看到 owner 被转走。真正关键的是把两件事连起来：

VEA owner 变更 -> 新 owner 在短时间内调用 VEA mint -> TSR 合约向 VEA 铸造 99,000,000 枚 TSR 链溯光 AddressPlus 针对这种跨合约路径做了事件关联：即使 owner 事件发生在 VEA，mint 日志发生在 TSR，也可以把它们放到同一条时间线中，提示“Owner 变更后触发大额铸币”，并保留两笔交易哈希供复核。

这是不是代码漏洞

答案要分层看。

TSR 主合约层面

从 TSR 主合约本身看，这不是典型代码漏洞。

TSR 的 mint 函数有 onlyRole(MINTER_ROLE) 限制，攻击者地址本身没有 MINTER_ROLE。真正拥有铸币权限的是 VEA 合约。

VEA 和权限治理层面

问题非常严重。

VEA 是 TSR 的铸币通道，而 VEA 的 owner 权限由一个 EOA Executor 控制。链上 eth_getCode 显示，VEA Executor 0x61a23...cF17 不是合约地址，而是 EOA。

这意味着，一个单点 EOA 间接控制了 TSR 的大额铸币路径。

攻击前，VEA owner 是 Executor；攻击中，Executor 把 owner 转给攻击者；攻击后，攻击者调用 VEA 铸出 9,900 万枚 TSR。

这条路径本质上是：

TSR.mint() -> onlyRole(MINTER_ROLE) -> MINTER_ROLE holder = VEA -> VEA.owner() = Executor EOA -> Executor transferOwnership(attacker) -> attacker calls VEA mint -> VEA calls TSR mint 所以，这次事件更准确的归类不是“TSR 主合约 mint 裸奔”，而是：

高权限铸币链路被 EOA 单点控制，随后该 EOA 发出异常转权交易，导致攻击者接管 VEA 并触发大额增发。 攻击者为什么能拿到 owner 身份

链上能证明的是：攻击者的 owner 身份来自一笔合法的 transferOwnership。

链上无法直接证明的是：原 owner 为什么会发出这笔交易。

目前最可能的原因有三类：

1. Executor 私钥或运行环境被攻破。

2. 自动化执行器或后端逻辑被诱导执行危险操作。

3. 内部误操作或恶意行为。

无论是哪一种，最终结果都是一样的：VEA 的 owner 被转给攻击者，攻击者由此获得了触发铸币路径的能力。

真正的风险：不是 mint，而是谁能触发 mint

很多项目在做合约审计时，会重点检查：

mint 函数有没有权限控制？ 但这起事件提醒我们，更重要的问题是：

谁拥有这个权限？ 这个权限还能被谁间接控制？ 控制者是不是 EOA？ owner 能不能一笔交易转给任意地址？ 拥有 minter 权限的合约是否还有自己的 owner、admin、executor？ Tessera 事件里，TSR 主合约看起来有权限控制，但 minter 权限下放给了 VEA；VEA 又被 Executor 控制；Executor 是 EOA。

攻击路径最终不是打穿 TSR，而是接管 VEA。

这就是典型的权限图风险。

对项目方来说，这类问题应该在上线前通过权限图审计暴露出来；对交易所、钱包和安全团队来说，这类信号则应该进入持续监控规则。雪磐安全团队在处理此类案例时，通常会把工作拆成两层：

合约代码审计 -> 检查 mint、role、owner、upgrade、pause 等高权限入口 -> 识别权限是否被委托给外部合约或单点 EOA 链上行为监控 -> 监控 owner/admin/role 变更 -> 监控变更后的大额 mint、upgrade、资金迁移和混币路径 链溯光负责把链上行为侧的证据结构化；雪磐安全团队可以进一步结合源码审计、权限图建模和部署架构复核，判断这是私钥风险、执行器风险、权限设计风险，还是内部流程风险。

对 AI 代码审计编排的启发

如果使用 AI 做自动化安全分析，这类事件不能只扫描单个合约函数。

系统需要构建跨合约权限图。

一个有效的审计编排应该能自动追踪：

1. 代币合约是否存在 mint/burn/upgrade/role 管理函数。 2. mint 是否受 role 或 owner 控制。 3. role 持有者是不是外部合约。 4. 外部合约自己的 owner/admin/executor 是谁。 5. owner/admin 是否为 EOA。 6. 是否存在 transferOwnership、upgradeTo、setExecutor、setMinter 等危险入口。 7. 是否存在一次性大额 mint、无速率限制、无 timelock、无 pause 的组合风险。 一旦识别出下面这种结构，就应该直接给出高危告警：

高危：代币铸币权限被委托给可由单 EOA 控制的外部合约。 风险：EOA 私钥泄露、后端被控或误操作后，可导致大规模增发。 建议：使用多签、timelock、mint cap、rate limit、pause 和链上审批流。 这也是链溯光继续产品化和交付落地的重点方向：不是只做“地址查一查”，而是把代码审计、权限图、链上监控规则和 AI 事件报告连起来。

面向类似 Tessera 的事件，链溯光和雪磐安全服务可以覆盖三类工作：

1. 事后复盘：输入合约地址或交易哈希，快速还原 owner 变更、mint、资金流和关键时间线。

2. 监控规则设计：把 owner/admin/role 变更、大额 mint、upgrade、pause 等敏感操作纳入 watch 规则和通知流程。

3. 事前审计：结合雪磐安全团队的合约代码审计，识别单点 EOA、委托铸币、无 timelock、无速率限制等权限治理问题。

时间线

结语

Tessera 事件不是一个“黑客绕过 Solidity 代码”的故事。

它更像是一个权限治理失控的故事。

TSR 的主合约没有把门完全敞开，但它把钥匙交给了 VEA；VEA 又把最终控制权放在一个 EOA 手里。当这个 EOA 发出 transferOwnership 的那一刻，攻击者就已经站在了铸币机前。

真正的教训是：在 DeFi 安全里，代码只是第一层，权限关系才是攻击者真正寻找的地图。

如果说传统审计看的是函数，那么下一代 AI 审计应该看的，是整张权限网络。

对项目方、交易所、钱包和投资机构来说，这类事件的核心不是“事后知道发生了什么”，而是能否更早发现权限链路里的不稳定点。

链溯光 AddressPlus 是雪磐安全面向链上安全情报和事件研判的产品，适合用于：

安全事件复盘 合约权限图审计辅助 高权限操作监控规则设计 投资尽调与项目风险复核 交易所 / 钱包风控线索研判 私有化链上情报工作台建设 如果你的项目存在 owner、admin、minter、executor、upgrade proxy、timelock、多签等复杂权限结构，建议不要只检查单个函数是否有修饰器，而是把完整权限链路拉出来复核。雪磐安全可以基于链溯光报告和人工审计流程，协助做合约代码审计、权限治理检查、敏感操作监控方案和事件复盘报告。