---
title: "Risiko von Multisig-Modulen: Welche Berechtigungen umgehen den Schwellenwert?"
description: "Ein aktiviertes Modul kann Transaktionen aus einem Multisig-Konto ausführen, ohne den normalen Eigentümer-Schwellenwert einzuholen. So prüfen Sie Module, Guards, Fallback-Handler, Upgrades und Wiederherstellungswege."
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.
# Risiko von Multisig-Modulen: Welche Berechtigungen umgehen den Schwellenwert?
> Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.
## Direkte Antwort
Ein aktiviertes Modul ist ein eigenständiger Autorisierungsweg. Bei Smart Accounts nach dem Safe-Modell kann ein zugelassenes Modul `execTransactionFromModule` aufrufen und einen `CALL` oder `DELEGATECALL` ausführen, ohne für diese Aktion die normalen M-von-N-Signaturen der Eigentümer einzuholen. Der angezeigte Schwellenwert beschreibt daher nur einen Ausführungsweg und nicht die vollständige Sicherheitsgrenze des Kontos.
Module ermöglichen nützliche Automatisierungen wie Ausgabenlimits, wiederkehrende Zahlungen, Wiederherstellung und Protokollvorgänge. Ihre Befugnis kann dennoch weit reichen: Der offizielle Safe-Vertrag beschreibt aktivierte Module als fähig, beliebige Transaktionen auszuführen, und warnt, dass ein bösartiges Modul einen Safe übernehmen kann. Prüfen Sie jedes aktivierte Modul, nicht nur Eigentümer und Schwellenwert.
## Funktionsweise
Die Eigentümer autorisieren zunächst `enableModule` durch eine reguläre Safe-Transaktion. Das Konto speichert das Modul in seinem Register aktivierter Module. Später prüft das Modul selbst Aufrufer und Regeln und ruft dann `execTransactionFromModule` auf; das Konto bestätigt, dass der Aufrufer aktiviert ist, und führt den Auftrag aus. Die Sicherheit hängt nun auch von Code, Konfiguration, Administratoren, Upgrade-Schlüsseln und externen Abhängigkeiten des Moduls ab.
Ein Transaktions-Guard und ein Module Guard sind unterschiedliche Kontrollen. Der Transaktions-Guard prüft reguläre `execTransaction`-Aufrufe, der Module Guard dagegen modulinitiierte Aufrufe. Ein Guard kann eine Ausführung ablehnen, aber ein defekter oder zu strenger Guard kann auch den Dienst blockieren. Stellen Sie fest, welcher Guard-Typ installiert ist, was er prüft und wie er wiederhergestellt oder entfernt werden kann.
Ein Fallback Handler ist ein weiterer Erweiterungspunkt. Wenn calldata zu keiner Kernfunktion des Kontos passt, leitet das Konto den Aufruf an den konfigurierten Handler weiter und hängt die Adresse des ursprünglichen Aufrufers an. Handler können Signaturprüfung und Token-Callbacks ergänzen, doch unsichere Logik oder Konfiguration schafft eine zusätzliche Berechtigungs- und Interpretationsfläche.
## Beispiel
Eine Treasury nutzt einen Eigentümer-Schwellenwert von 3-of-5 und aktiviert ein Freibetragsmodul für Routinezahlungen. Das Modul ist upgradefähig; sein Upgrade-Administrator ist eine einzelne Hot Wallet. Wird dieser Schlüssel kompromittiert, kann ein Angreifer das Modul aktualisieren, den Modulweg aufrufen und Vermögenswerte ohne 3 Eigentümersignaturen übertragen. Der 3-of-5-Schwellenwert bleibt unverändert, gilt aber nicht für diesen Weg.
Die Prüfung sollte Moduladresse und verifizierte Implementierung, Proxy und Administrator, Ausgabenlimits, erlaubte Ziele und Funktionsselektoren, die Zulässigkeit von `DELEGATECALL`, den installierten Module Guard, den Fallback Handler sowie die genaue Transaktion zum Deaktivieren des Moduls erfassen. Prüfen Sie diese Werte je bereitgestellter Chain direkt aus Konto- und Proxy-Verträgen statt nur über eine Wallet-Oberfläche.
## Risiken
- **Befugnisrisiko:** Ein verwundbares oder bösartiges Modul kann Vermögenswerte übertragen, Ausgabenfreigaben erteilen, den Kontostatus per `DELEGATECALL` verändern oder andere privilegierte Verträge aufrufen. Eine eingeschränkte Oberfläche beweist keine eingeschränkte On-Chain-Befugnis.
- **Kontroll- und Upgrade-Risiko:** Modul-Proxy, Administrator, Oracle, Automatisierungsausführer oder Wiederherstellungsschlüssel können eine scheinbare 3-of-5-Struktur auf eine kleinere wirksame Kontrollgruppe reduzieren. Verfolgen Sie jeden Upgrade- und Konfigurationsweg bis zu den endgültigen Unterzeichnern und Verzögerungen.
- **Verfügbarkeitsrisiko:** Ein fehlerhafter Guard kann gültige Transaktionen blockieren, während ein kompromittiertes Modul schneller handeln kann, als Eigentümer seine Entfernung koordinieren. Testen Sie Deaktivierung und Wiederherstellung, überwachen Sie Modul-, Guard- und Handler-Änderungen und halten Sie einen Reaktionsweg vor, der nicht von der zu entfernenden Komponente abhängt.
## Häufige Irrtümer
- **Irrtum 1: „Das Konto ist 3-of-5, daher braucht jede Übertragung 3 Signaturen.“** Der Schwellenwert gilt für den regulären Eigentümerweg; aktivierte Module können andere Autorisierungsregeln haben.
- **Irrtum 2: „Ein Guard schützt jeden Ausführungsweg.“** Reguläre Transaktions-Guards und Module Guards decken verschiedene Eintrittspunkte ab; der Umfang hängt vom installierten Vertrag und seinen Regeln ab.
- **Irrtum 3: „Das Entfernen des Moduls in der Oberfläche beendet das Risiko.“** Prüfen Sie auf jeder Chain das Register aktivierter Module, Handler- und Guard-Speicher, Proxy-Implementierung und ausgeführte Änderungstransaktionen.
## Verwandte Themen
- [Speicherrisiko durch Delegatecall](/de/crypto/delegatecall-storage-risk/)
- [Verwaltung privater Schlüssel](/de/crypto/private-key-management/)
- [Multisig-Wallet](/de/crypto/multisig-wallet/)
- [Überwachung von Proxy-Upgrades](/de/crypto/proxy-upgrade-monitoring/)
- [Wallet-Signatur](/de/crypto/wallet-signature/)
## Quellen
- [Safe-Module](https://docs.safe.global/advanced/smart-account-modules) - Safe Ecosystem Foundation (abgerufen: 2026-08-21)
- [Safe-Guards](https://docs.safe.global/advanced/smart-account-guards) - Safe Ecosystem Foundation (abgerufen: 2026-08-21)
- [Safe Fallback Handler](https://docs.safe.global/advanced/smart-account-fallback-handler) - Safe Ecosystem Foundation (abgerufen: 2026-08-21)
- [ModuleManager.sol](https://github.com/safe-fndn/safe-smart-account/blob/main/contracts/base/ModuleManager.sol) - Safe Ecosystem Foundation (abgerufen: 2026-08-21)
Source: https://wiki.fcontext.com/de/crypto/multisig-module-risk/index.mdx