← Back to Blog

Multisig Wallet Security: Gnosis Safe Vulnerabilities and Best Practices

2026-04-18 multisig gnosis safe solidity security threshold governance 2026

In March 2022, Axie Infinity's Ronin Bridge lost $625 million in a single transaction. The root cause was not a clever mathematical exploit — it was a multisig with too few signers and keys stored on internet-connected machines. Four months later, the Harmony Horizon Bridge lost $100 million for the same category of reason: a 2-of-5 multisig whose signing keys were compromised.

Multisig wallets exist to eliminate single points of failure. When they are misconfigured or implemented incorrectly, they become the single point of failure.

This post walks through six vulnerability classes — from threshold misconfiguration to metamorphic contract upgrades — with code-level examples and a production hardening checklist for Gnosis Safe deployments.

Why Multisig Matters

A standard externally owned account (EOA) grants full protocol control to whoever holds one private key. One phishing email, one compromised machine, or one insider threat is enough to drain the treasury.

Multisig wallets require M-of-N signatures before executing any transaction. For an attacker to steal funds they must compromise M independent keys simultaneously — a dramatically harder task when signers use hardware wallets and are geographically distributed.

The operational security math is straightforward: a 3-of-5 multisig means an attacker must compromise three independent signers before a single dollar moves. Compare that to the Ronin Bridge, where Axie Infinity accidentally configured one entity (Sky Mavis) to control four of the nine validator keys — effectively turning a 5-of-9 multisig into a 1-of-2 from an attacker's perspective.

Multisig is necessary. It is not sufficient on its own.

Vulnerability 1: Insufficient Threshold

A threshold that is too low defeats the purpose of multisig entirely.

2-of-2 is a common beginner configuration. It sounds strict — both parties must agree — but if one key is lost or one signer is unavailable, the wallet is permanently bricked with no recovery path. Teams that cannot move funds during an incident are just as harmed as teams whose funds are stolen.

1-of-N is operationally convenient and operationally catastrophic. Any single compromised signer drains the wallet.

The Harmony Horizon Bridge used a 2-of-5 configuration. Attackers needed only two compromised keys — a low bar against a determined, well-funded threat actor.

Production minimum: 3-of-5. For protocol treasuries holding more than $1M, 4-of-7 or higher is the standard. The threshold should be high enough that no single geographic region or organizational unit controls a quorum.

Rule of thumb:
- Development / testnet: 2-of-3
- Staging / small treasury (under $500K): 3-of-5
- Production treasury (over $1M): 4-of-7 or 5-of-9
- Critical infrastructure (bridge, core upgrade key): 5-of-9 with hardware-only signers

Vulnerability 2: Signer Key Compromise

A threshold of 5-of-9 provides no protection if five of those nine keys live on internet-connected machines inside the same AWS account.

The Ronin Bridge incident demonstrated this. Sky Mavis held four validator keys on shared infrastructure. When attackers breached that infrastructure, they captured four keys in one operation. A fifth key belonging to the Axie DAO had been temporarily granted to Sky Mavis to handle transaction load — and was never revoked. Five keys, one breach.

Hot wallet signers — keys in browser extensions, on developer laptops, or in CI/CD pipelines — are exposed to:
- Malware and keyloggers
- Phishing and session hijacking
- Supply chain attacks on npm packages loaded by the same browser
- Insider threats with access to shared secrets

Required controls:

  1. Hardware wallets for every production signer (Ledger, Trezor, or GridPlus Lattice1). The private key never touches an internet-connected machine.
  2. Geographic distribution. Signers should be in different cities, ideally different continents.
  3. Organizational distribution. No single team, company, or legal entity should control a quorum.
  4. Key rotation on a defined schedule (annually minimum; immediately after any personnel change).
  5. A documented offboarding procedure: when a signer leaves, rotate that key before their last day.

Vulnerability 3: Missing Timelock

Even a perfectly configured multisig with hardware wallet signers can execute a malicious transaction if the signers are deceived — or if a majority of them turn rogue.

Without a timelock, a multisig can drain a treasury or upgrade a contract to a malicious implementation in a single block. By the time community members or security monitoring systems notice, the funds are gone.

A timelock (typically implemented via OpenZeppelin's TimelockController) inserts a mandatory delay between when a transaction is queued and when it can be executed. A 48-hour timelock gives the community time to:
- Detect an unusual pending transaction
- Raise an alarm on social channels
- Coordinate an emergency response (pausing the protocol, alerting exchanges, etc.)

import "@openzeppelin/contracts/governance/TimelockController.sol";

// Deploying a 48-hour timelock
uint256 minDelay = 48 hours;
address[] memory proposers = ...; // multisig address
address[] memory executors = ...; // multisig address or address(0) for open execution

TimelockController timelock = new TimelockController(
    minDelay,
    proposers,
    executors,
    address(0) // admin: set to address(0) after setup to prevent bypass
);

The multisig should be the proposer. The timelock should be the owner of the protocol contracts. Direct ownership by the multisig — with no timelock in between — removes the community's detection window entirely.

Production standard: 48 hours minimum for treasury operations; 72 hours or more for contract upgrades.

Vulnerability 4: Custom Multisig Signature Verification Bugs

Most teams should use Gnosis Safe rather than write their own multisig. Custom implementations introduce a category of signature verification bugs that are subtle, hard to test, and catastrophic in production.

Off-by-one in threshold check

// VULNERABLE: uses < instead of <=
// A 3-of-5 multisig passes with only 2 valid signatures
function executeTransaction(..., bytes[] memory signatures) external {
    require(signatures.length < threshold, "Not enough signatures");
    // ...
}

// CORRECT: require at least threshold signatures
function executeTransaction(..., bytes[] memory signatures) external {
    require(signatures.length >= threshold, "Not enough signatures");
    // ...
}

Duplicate signer attack (unsorted signatures)

If the contract verifies that each recovered address is a valid owner but does not enforce that signers are unique, an attacker can submit the same valid signature multiple times to satisfy the threshold.

// VULNERABLE: no duplicate check
function _verifySignatures(bytes32 hash, bytes[] memory signatures) internal view {
    for (uint256 i = 0; i < signatures.length; i++) {
        address signer = ECDSA.recover(hash, signatures[i]);
        require(isOwner[signer], "Invalid signer");
        // No check: signer could appear twice
    }
}

// CORRECT: enforce strict ascending order on recovered addresses
function _verifySignatures(bytes32 hash, bytes[] memory signatures) internal view {
    address lastSigner = address(0);
    for (uint256 i = 0; i < signatures.length; i++) {
        address signer = ECDSA.recover(hash, signatures[i]);
        require(isOwner[signer], "Invalid signer");
        require(signer > lastSigner, "Signatures must be sorted; duplicate detected");
        lastSigner = signer;
    }
}

Gnosis Safe enforces this pattern natively. Custom implementations routinely miss it.

Missing signature malleability check

ECDSA signatures have a known malleability property: for any valid (r, s, v) signature, (r, -s mod n, v') is also mathematically valid. Without a check on the s value, an attacker can resubmit a modified signature as if it were a fresh signer's approval.

// CORRECT: restrict s to the lower half of the curve order
// OpenZeppelin's ECDSA.recover() does this automatically
// If implementing manually:
require(
    uint256(s) <= 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0,
    "Invalid signature s value"
);

Vulnerability 5: Metamorphic Contract Upgrade Attack

Multisig wallets are often designated as the owner authorized to upgrade protocol contracts. This makes the multisig a high-value target for a specific class of attack: convincing the signers to approve an upgrade to a malicious implementation.

The attack flow:

  1. An attacker submits a seemingly benign upgrade proposal with a contract address that passes code review.
  2. The malicious contract uses a metamorphic deployment pattern — CREATE2 with a deployer that can SELFDESTRUCT and redeploy different bytecode to the same address.
  3. Signers approve the upgrade based on the reviewed code.
  4. Before execution (or immediately after, in the same block via a bundler), the attacker redeployes different, malicious bytecode to that address.
  5. The DELEGATECALL from the proxy now executes attacker-controlled code with the protocol's storage context.

Defense measures:

Vulnerability 6: Social Engineering and Governance Attacks

Not every multisig attack is technical. The Beanstalk governance exploit in April 2022 — a $182M loss — used a flash loan to acquire a supermajority of governance tokens in a single block, then passed a malicious proposal that drained the protocol treasury. The attack bypassed any multisig because Beanstalk's governance executed proposals directly without a multisig or timelock requirement.

While technically a governance failure rather than a multisig failure, the lesson applies directly to multisig security: a determined attacker will target the path of least resistance, and that path is often human.

Social engineering scenarios against multisig signers:

Controls against social manipulation:

Gnosis Safe Production Checklist

What ContractScan Detects

Vulnerability Slither Detection AI Detection
Missing access control on admin functions Yes — unprotected-upgrade, missing-access-control Yes
Off-by-one in threshold check Partial — incorrect-equality Yes
Duplicate signer (unsorted check missing) No Yes
Signature malleability (missing s check) Partial Yes
Multisig as direct owner (no timelock) No Yes
Metamorphic upgrade risk (CREATE2 + SELFDESTRUCT) Partial — suicidal Yes
Hot wallet signer pattern in deployment scripts No Yes

AI-based analysis is especially valuable for the vulnerabilities that pattern-matching tools miss: logic errors in custom signature verification, missing timelock enforcement, and upgrade path risks that require understanding contract interactions rather than individual functions.

Audit Your Multisig Integration

Misconfigured multisig wallets and custom signature verification bugs are among the most expensive vulnerabilities in DeFi — and among the most preventable. ContractScan runs Slither, Mythril, Aderyn, Semgrep, and AI-based code reasoning against your contracts in under five minutes.

Audit your multisig integration at https://contract-scanner.raccoonworld.xyz

Important Notes

This post is for educational and informational purposes only and does not constitute financial or legal advice. ContractScan is a tool to reduce security risks and does not guarantee discovery of all vulnerabilities. It is strongly recommended to undergo a manual audit by a professional security firm before deploying high-value projects. We assume no legal liability for any losses incurred through the use of this service.

Scan your contract for this vulnerability
Free QuickScan — Unlimited quick scans. No signup required.. No signup required.
Scan a Contract →