Riesgo de módulos multifirma: ¿qué permisos eluden el umbral?

Un módulo habilitado puede ejecutar operaciones desde una cuenta multifirma sin reunir el umbral normal de propietarios. Aprenda a auditar módulos, Guards, Fallback Handlers, actualizaciones y rutas de recuperación.

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

Un módulo habilitado constituye una ruta de autorización independiente. En cuentas inteligentes del tipo Safe, un módulo aprobado puede llamar a execTransactionFromModule y ejecutar un CALL o DELEGATECALL sin reunir para esa acción las firmas normales M-de-N de los propietarios. Por tanto, el umbral mostrado solo describe una ruta de ejecución, no todo el perímetro de seguridad de la cuenta.

Los módulos permiten automatizaciones útiles como límites de gasto, pagos periódicos, recuperación y operaciones de protocolo. Sin embargo, su autoridad puede ser amplia: el contrato oficial de Safe indica que los módulos habilitados pueden ejecutar transacciones arbitrarias y advierte que un módulo malicioso puede tomar el control de un Safe. Revise cada módulo habilitado, no solo los propietarios y el umbral.

Cómo funciona

Los propietarios autorizan primero enableModule mediante una transacción Safe normal. La cuenta guarda el módulo en su registro de módulos habilitados. Más tarde, el módulo valida por sí mismo al llamante y sus reglas y llama a execTransactionFromModule; la cuenta comprueba que el llamante está habilitado y ejecuta la operación solicitada. La seguridad pasa a depender también del código, configuración, administradores, claves de actualización y dependencias externas del módulo.

Un Guard de transacciones y un Module Guard son controles distintos. El primero revisa llamadas normales a execTransaction, mientras que el segundo revisa llamadas iniciadas por módulos. Un Guard puede rechazar una ejecución, pero uno defectuoso o demasiado restrictivo también puede causar una denegación de servicio. Confirme qué tipo está instalado, qué comprueba y cómo recuperarlo o retirarlo.

Un Fallback Handler es otro punto de extensión. Cuando calldata no coincide con una función principal de la cuenta, esta reenvía la llamada al Handler configurado y añade la dirección del llamante original. Los Handlers pueden incorporar validación de firmas y callbacks de tokens, pero una lógica o configuración insegura crea otra superficie de permisos e interpretación.

Ejemplo

Una tesorería usa un umbral de propietarios 3-of-5 y habilita un módulo de asignaciones para pagos habituales. El módulo es actualizable y su administrador de actualización es una sola billetera caliente. Si esa clave se compromete, un atacante puede actualizar el módulo, usar la ruta de ejecución modular y transferir activos sin obtener 3 firmas. El umbral 3-of-5 sigue intacto, pero no gobierna esta ruta.

La revisión debe identificar la dirección del módulo y su implementación verificada, proxy y administrador, límites de gasto, destinos y selectores permitidos, si se admite DELEGATECALL, el Module Guard instalado, el Fallback Handler y la transacción exacta necesaria para deshabilitar el módulo. Verifique estos valores en los contratos de cuenta y proxy de cada cadena, no solo en la interfaz de una billetera.

Riesgos

Riesgo de autoridad: Un módulo vulnerable o malicioso puede transferir activos, aprobar gastadores, cambiar el estado mediante DELEGATECALL o invocar otros contratos privilegiados. Una interfaz limitada no demuestra que la autoridad en cadena sea limitada.
Riesgo de control y actualización: Un proxy, administrador, oráculo, ejecutor de automatización o clave de recuperación puede reducir una estructura aparente 3-of-5 a un conjunto efectivo menor. Siga cada ruta de actualización y configuración hasta sus firmantes finales y sus demoras.
Riesgo de disponibilidad: Un Guard defectuoso puede bloquear transacciones válidas, mientras que un módulo comprometido puede actuar antes de que los propietarios coordinen su retirada. Pruebe la desactivación y recuperación, vigile cambios de módulos, Guards y Handlers, y conserve una ruta de respuesta que no dependa del componente que se retira.

Errores comunes

Error 1: «La cuenta es 3-of-5, por lo que cada transferencia necesita 3 firmas». El umbral se aplica a la ruta normal autorizada por propietarios; los módulos habilitados pueden usar otra política.
Error 2: «Un Guard protege todas las rutas de ejecución». Los Guards de transacciones y los Module Guards cubren puntos de entrada diferentes; la cobertura depende del contrato instalado y sus reglas.
Error 3: «Retirar el módulo en la interfaz elimina el riesgo». Confirme en cada cadena el registro de módulos habilitados, el almacenamiento de Handler y Guard, la implementación del proxy y las transacciones de cambio ejecutadas.

Temas relacionados

Fuentes

Módulos de Safe - Safe Ecosystem Foundation (consultado: 2026-08-21)
Guards de Safe - Safe Ecosystem Foundation (consultado: 2026-08-21)
Fallback Handler de Safe - Safe Ecosystem Foundation (consultado: 2026-08-21)
ModuleManager.sol - Safe Ecosystem Foundation (consultado: 2026-08-21)