---
title: "Risco de módulos multissig: quais permissões contornam o limite?"
description: "Um módulo habilitado pode executar operações de uma conta multissig sem reunir o limite normal dos proprietários. Saiba como auditar módulos, Guards, Fallback Handlers, upgrades e caminhos de recuperação."
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.
# Risco de módulos multissig: quais permissões contornam o limite?
> Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.
## Resposta direta
Um módulo habilitado é um caminho de autorização separado. Em contas inteligentes no estilo Safe, um módulo aprovado pode chamar `execTransactionFromModule` e executar um `CALL` ou `DELEGATECALL` sem reunir, para essa ação, as assinaturas M-de-N normais dos proprietários. Portanto, o limite exibido descreve apenas um caminho de execução, e não toda a fronteira de segurança da conta.
Os módulos viabilizam automações úteis, como limites de gastos, pagamentos recorrentes, recuperação e operações de protocolo. Contudo, sua autoridade pode ser ampla: o contrato oficial do Safe diz que módulos habilitados podem executar transações arbitrárias e alerta que um módulo malicioso pode assumir o controle de um Safe. Analise cada módulo habilitado, não apenas os proprietários e o limite.
## Como funciona
Primeiro, os proprietários autorizam `enableModule` por uma transação Safe normal. A conta guarda o módulo no registro de módulos habilitados. Depois, o módulo valida por conta própria o chamador e suas regras e chama `execTransactionFromModule`; a conta confirma que o chamador está habilitado e executa a operação solicitada. A segurança passa a depender também do código, configuração, administradores, chaves de upgrade e dependências externas do módulo.
Um Guard de transação e um Module Guard são controles distintos. O primeiro verifica chamadas normais a `execTransaction`, enquanto o segundo verifica chamadas iniciadas por módulos. Um Guard pode rejeitar uma execução, mas um Guard com defeito ou restritivo demais também pode causar negação de serviço. Confirme qual tipo está instalado, o que ele verifica e como recuperá-lo ou removê-lo.
Um Fallback Handler é outro ponto de extensão. Quando calldata não corresponde a uma função principal da conta, ela encaminha a chamada ao Handler configurado e acrescenta o endereço do chamador original. Handlers podem adicionar validação de assinaturas e callbacks de tokens, mas lógica ou configuração insegura cria outra superfície de permissão e interpretação.
## Exemplo
Uma tesouraria usa um limite de proprietários 3-of-5 e habilita um módulo de permissões para pagamentos rotineiros. O módulo pode receber upgrade, e o administrador desse upgrade é uma única carteira quente. Se essa chave for comprometida, um invasor pode atualizar o módulo, usar o caminho de execução modular e transferir ativos sem obter 3 assinaturas. O limite 3-of-5 permanece intacto, mas não governa esse caminho.
A análise deve identificar o endereço e a implementação verificada do módulo, proxy e administrador, limites de gastos, destinos e seletores permitidos, se `DELEGATECALL` é aceito, o Module Guard instalado, o Fallback Handler e a transação exata para desabilitar o módulo. Verifique esses valores nos contratos da conta e dos proxies em cada cadeia, e não apenas na interface da carteira.
## Riscos
- **Risco de autoridade:** Um módulo vulnerável ou malicioso pode transferir ativos, aprovar gastadores, alterar o estado por `DELEGATECALL` ou invocar outros contratos privilegiados. Uma interface limitada não comprova autoridade on-chain limitada.
- **Risco de controle e upgrade:** Proxy, administrador, oráculo, executor de automação ou chave de recuperação podem reduzir um arranjo aparente 3-of-5 a um conjunto efetivo menor. Rastreie cada caminho de upgrade e configuração até os signatários finais e os atrasos.
- **Risco de disponibilidade:** Um Guard defeituoso pode bloquear transações válidas, enquanto um módulo comprometido pode agir antes que os proprietários coordenem sua remoção. Teste desativação e recuperação, monitore alterações de módulos, Guards e Handlers e mantenha um caminho de resposta que não dependa do componente removido.
## Erros comuns
- **Erro 1: “A conta é 3-of-5, então toda transferência precisa de 3 assinaturas.”** O limite vale para o caminho normal autorizado pelos proprietários; módulos habilitados podem seguir outra política.
- **Erro 2: “Um Guard protege todos os caminhos de execução.”** Guards de transação e Module Guards cobrem pontos de entrada diferentes; a cobertura depende do contrato instalado e de suas regras.
- **Erro 3: “Remover o módulo na interface encerra o risco.”** Confirme em cada cadeia o registro de módulos habilitados, o armazenamento do Handler e do Guard, a implementação do proxy e as transações de alteração executadas.
## Tópicos relacionados
- [Risco de armazenamento com delegatecall](/pt-br/crypto/delegatecall-storage-risk/)
- [Gerenciamento de chaves privadas](/pt-br/crypto/private-key-management/)
- [Carteira multissig](/pt-br/crypto/multisig-wallet/)
- [Monitoramento de upgrades de proxy](/pt-br/crypto/proxy-upgrade-monitoring/)
- [Assinatura de carteira](/pt-br/crypto/wallet-signature/)
## Fontes
- [Módulos Safe](https://docs.safe.global/advanced/smart-account-modules) - Safe Ecosystem Foundation (acessado: 2026-08-21)
- [Guards Safe](https://docs.safe.global/advanced/smart-account-guards) - Safe Ecosystem Foundation (acessado: 2026-08-21)
- [Fallback Handler Safe](https://docs.safe.global/advanced/smart-account-fallback-handler) - Safe Ecosystem Foundation (acessado: 2026-08-21)
- [ModuleManager.sol](https://github.com/safe-fndn/safe-smart-account/blob/main/contracts/base/ModuleManager.sol) - Safe Ecosystem Foundation (acessado: 2026-08-21)
Source: https://wiki.fcontext.com/pt-br/crypto/multisig-module-risk/index.mdx