---
title: "Риск модулей мультиподписи: какие разрешения обходят порог?"
description: "Включённый модуль может выполнять операции из аккаунта с мультиподписью без обычного порога владельцев. Узнайте, как проверять модули, 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.
# Риск модулей мультиподписи: какие разрешения обходят порог?
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Включённый модуль — это отдельный путь авторизации. В смарт-аккаунтах типа Safe одобренный модуль может вызвать `execTransactionFromModule` и выполнить `CALL` или `DELEGATECALL`, не собирая для этой операции обычные подписи владельцев M-из-N. Поэтому отображаемый порог описывает лишь один путь выполнения, а не полную границу безопасности аккаунта.
Модули обеспечивают полезную автоматизацию: лимиты расходов, регулярные платежи, восстановление и операции протокола. Однако их полномочия могут быть широкими: официальный контракт Safe указывает, что включённые модули могут выполнять произвольные транзакции, и предупреждает, что вредоносный модуль способен захватить Safe. Проверяйте каждый включённый модуль, а не только владельцев и порог.
## Как это работает
Сначала владельцы авторизуют `enableModule` обычной транзакцией Safe. Аккаунт сохраняет модуль в реестре включённых модулей. Позже модуль сам проверяет вызывающего и свои правила, затем вызывает `execTransactionFromModule`; аккаунт убеждается, что вызывающий включён, и выполняет запрошенную операцию. Безопасность теперь также зависит от кода, конфигурации, администраторов, ключей обновления и внешних зависимостей модуля.
Guard транзакций и Module Guard — разные средства контроля. Первый проверяет обычные вызовы `execTransaction`, второй — вызовы, инициированные модулями. Guard может отклонить выполнение, но неисправный или чрезмерно строгий Guard способен также вызвать отказ в обслуживании. Установите, какой тип используется, что он проверяет и как его восстановить или удалить.
Fallback Handler — ещё одна точка расширения. Когда calldata не соответствует основной функции аккаунта, аккаунт перенаправляет вызов настроенному Handler и добавляет адрес исходного вызывающего. Handler может добавить проверку подписей и обратные вызовы токенов, но небезопасная логика или конфигурация создаёт дополнительную поверхность разрешений и интерпретации.
## Пример
Казначейство использует порог владельцев 3-of-5 и включает модуль лимитов для обычных платежей. Модуль обновляемый, а администратор обновления — один горячий кошелёк. При компрометации ключа атакующий может обновить модуль, воспользоваться модульным путём и перевести активы без 3 подписей. Порог 3-of-5 остаётся неизменным, но не регулирует этот путь.
Проверка должна определить адрес и верифицированную реализацию модуля, прокси и администратора, лимиты расходов, разрешённые цели и селекторы функций, допустимость `DELEGATECALL`, установленный Module Guard, Fallback Handler и точную транзакцию для отключения модуля. Проверяйте значения в контрактах аккаунта и связанных прокси в каждой сети, а не только в интерфейсе кошелька.
## Риски
- **Риск полномочий:** Уязвимый или вредоносный модуль может переводить активы, одобрять расходующие адреса, менять состояние через `DELEGATECALL` или вызывать другие привилегированные контракты. Ограниченный интерфейс не доказывает ограниченность полномочий в сети.
- **Риск контроля и обновления:** Прокси модуля, администратор, оракул, исполнитель автоматизации или ключ восстановления могут свести видимую схему 3-of-5 к меньшему фактическому набору контроля. Проследите каждый путь обновления и настройки до конечных подписантов и задержек.
- **Риск доступности:** Неисправный Guard может блокировать корректные транзакции, а скомпрометированный модуль — действовать быстрее, чем владельцы согласуют его удаление. Проверьте отключение и восстановление, отслеживайте изменения модуля, Guard и Handler и сохраняйте путь реагирования, не зависящий от удаляемого компонента.
## Распространённые заблуждения
- **Заблуждение 1: «Аккаунт использует 3-of-5, значит каждый перевод требует 3 подписей».** Порог применяется к обычному пути владельцев; включённые модули могут использовать другую политику авторизации.
- **Заблуждение 2: «Один Guard защищает все пути выполнения».** Обычный Guard транзакций и Module Guard охватывают разные точки входа; покрытие зависит от установленного контракта и его правил.
- **Заблуждение 3: «Удаление модуля в интерфейсе устраняет риск».** В каждой сети проверьте реестр включённых модулей, хранилище Handler и Guard, реализацию прокси и выполненные транзакции изменения.
## Похожие темы
- [Риск хранилища при delegatecall](/ru/crypto/delegatecall-storage-risk/)
- [Управление закрытыми ключами](/ru/crypto/private-key-management/)
- [Кошелёк с мультиподписью](/ru/crypto/multisig-wallet/)
- [Мониторинг обновлений прокси](/ru/crypto/proxy-upgrade-monitoring/)
- [Подпись кошелька](/ru/crypto/wallet-signature/)
## Источники
- [Модули Safe](https://docs.safe.global/advanced/smart-account-modules) - Safe Ecosystem Foundation (дата обращения: 2026-08-21)
- [Guard в Safe](https://docs.safe.global/advanced/smart-account-guards) - Safe Ecosystem Foundation (дата обращения: 2026-08-21)
- [Fallback Handler в Safe](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/ru/crypto/multisig-module-risk/index.mdx