﻿---
title: "多签模块风险：哪些权限可以绕过阈值？"
description: "已启用的模块可以在不收集常规 Owner 阈值签名的情况下从多签账户执行交易。了解如何审计模块、Guard、Fallback Handler、升级和恢复路径。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 多签模块风险：哪些权限可以绕过阈值？

> 仅供教育参考，不构成投资建议；投资可能产生损失。

<a id="answer"></a>

## 直接答案

已启用的模块是一条独立授权路径。在 Safe 风格的智能账户中，获准模块可调用 `execTransactionFromModule`，在不为该操作收集常规 M-of-N Owner 签名的情况下执行 `CALL` 或 `DELEGATECALL`。因此，界面显示的 Owner 阈值只描述一条执行路径，并非账户的完整安全边界。

模块可支持限额、定期付款、恢复和协议操作等实用自动化。但其权限可能很广：Safe 官方合约说明已启用模块可以执行任意交易，并警告恶意模块可能接管 Safe。审查时必须检查每个已启用模块，不能只看 Owner 和阈值。

<a id="mechanism"></a>

## 工作机制

Owner 首先通过常规 Safe 交易授权 `enableModule`，账户随后将模块写入已启用模块注册表。之后，该模块自行验证调用者及规则，再调用 `execTransactionFromModule`；账户确认调用方确实已启用后执行请求的操作。此时，安全性还取决于模块代码、配置、管理员、升级密钥和外部依赖。

交易 Guard 和 Module Guard 是两种不同的控制。交易 Guard 检查常规 `execTransaction` 调用，Module Guard 则检查模块发起的调用。Guard 可以拒绝执行，但故障或过度限制的 Guard 也可能造成拒绝服务。应确认安装了哪种 Guard、它检查什么，以及如何恢复或移除。

Fallback Handler 是另一扩展点。当 calldata 与账户核心函数均不匹配时，账户会将调用转发给配置的 Handler，并在 calldata 后附加原始调用者地址。Handler 可增加签名验证和代币回调，但不安全的逻辑或配置也会新增权限与解析攻击面。

<a id="example"></a>

## 示例

某金库采用 3-of-5 Owner 阈值，并启用额度模块处理日常付款。该额度模块可以升级，而升级管理员是单个热钱包。如果该密钥被盗，攻击者可能升级模块、调用模块执行路径，并在未取得 3 个 Owner 签名时转走金库资产。3-of-5 阈值本身未被更改，但不约束这条路径。

审查应识别模块地址及已验证实现、代理与管理员、支出上限、允许的目标和函数选择器、是否允许 `DELEGATECALL`、已安装的 Module Guard、Fallback Handler，以及禁用模块所需的确切交易。每条部署链都应从账户合约和相关代理合约核验这些值，不能只依赖钱包界面。

<a id="risks"></a>

## 风险

- **权限风险：** 有漏洞或恶意模块可能转移资产、授权 spender、通过 `DELEGATECALL` 改变账户状态，或调用其他特权合约。功能受限的界面并不能证明链上权限同样受限。
- **控制与升级风险：** 模块代理、管理员、预言机、自动执行者或恢复密钥，可能让表面上的 3-of-5 安排实际只由更少主体控制。应追踪每条升级与配置路径，直到最终签名者和时间延迟。
- **可用性风险：** 故障 Guard 可能阻止有效交易，而被攻陷模块的行动速度可能快于 Owner 协调移除的速度。应测试禁用与恢复流程，监控模块、Guard 和 Handler 变更，并保留不依赖待移除组件的响应路径。

<a id="misconceptions"></a>

## 常见误区

- **误区 1：“账户是 3-of-5，所以每笔转账都要 3 个签名。”** 阈值适用于常规 Owner 授权路径；已启用模块可以使用不同的授权策略。
- **误区 2：“一个 Guard 会保护所有执行路径。”** 常规交易 Guard 与 Module Guard 覆盖不同入口，实际覆盖范围取决于已安装合约及其规则。
- **误区 3：“在界面移除模块就消除了风险。”** 应在账户存在的每条链上核对链上已启用模块注册表、Handler 和 Guard 存储、代理实现及已发出的变更交易。

<a id="related"></a>

## 相关主题

- [Delegatecall 存储风险](/zh-cn/crypto/delegatecall-storage-risk/)
- [私钥管理](/zh-cn/crypto/private-key-management/)
- [多签钱包](/zh-cn/crypto/multisig-wallet/)
- [代理升级监控](/zh-cn/crypto/proxy-upgrade-monitoring/)
- [钱包签名](/zh-cn/crypto/wallet-signature/)

<a id="sources"></a>

## 来源

- [Safe 模块](https://docs.safe.global/advanced/smart-account-modules) - Safe Ecosystem Foundation（查阅日期：2026-08-21）
- [Safe Guard](https://docs.safe.global/advanced/smart-account-guards) - Safe Ecosystem Foundation（查阅日期：2026-08-21）
- [Safe Fallback Handler](https://docs.safe.global/advanced/smart-account-fallback-handler) - Safe Ecosystem Foundation（查阅日期：2026-08-21）
- [ModuleManager.sol](https://github.com/safe-fndn/safe-smart-account/blob/main/contracts/base/ModuleManager.sol) - Safe Ecosystem Foundation（查阅日期：2026-08-21）

Source: https://wiki.fcontext.com/zh-cn/crypto/multisig-module-risk/index.mdx
