We manage your security to weather the AI storm →

← Resource Hub

What to Do When a Multisig Signer Is Compromised

By Owen Thurm Published 5 min read

What to Do When a Multisig Signer Is Compromised

Quick answer. Stop routine signing and assume other signers may be exposed. Use up pending nonces, then swap suspect owners in a transaction only trusted signers approve. Check modules, guards and proposers; move funds if the threshold is in doubt.

Watch: What to Do When a Multisig Signer Is Compromised 1:41
Video transcript

If one multisig signer is compromised, assume the others may be too. The largest multisig losses broke the idea that signers fail one at a time.

At Bybit, every signer saw the same masked interface. At Drift, BlockSec says the attacker regained the two of five threshold within three days.

First, contain. Halt non-emergency transactions, alert the team on every channel, and identify which keys may be exposed. Confirm through a channel the attacker cannot reach.

A signature cannot be taken back. It stays executable until its nonce is used, so replace anything unplanned with a harmless transaction at the same nonce.

Then rotate to a clean quorum. Quarantine suspect devices, create keys on fresh hardware, and confirm each address by voice or video. Batch every swap, approved only by trusted signers, and verify onchain.

Owners are not the only way in. Check modules, which act without confirmations, the guard, the fallback handler, the implementation address, and any proposers the suspect owner added.

If suspect signers could reach the threshold, rotation becomes a race. Move first: deploy a new Safe from clean devices, test a small transfer, then move assets and admin roles. WazirX did this after its 2024 loss.

Guardian's Managed Security reviews every multisig transaction before signing, and every configuration change as it lands. Read the full runbook, or talk to Guardian.

A multisig assumes signers fail one at a time. The largest multisig losses broke that assumption.

At Bybit, malicious JavaScript was injected into Safe's web app, "which was accessed by Bybit's signers," Verichains said. CEO Ben Zhou said all the signers saw the masked UI.

At Drift, a council change on March 27, 2026 voided the signatures the attacker had collected. By March 30, BlockSec found a new durable nonce account tied to a member of the new council.

BlockSec says the attacker had regained the 2-of-5 threshold within three days.

So when one key or device looks compromised, plan as if others are too. This runbook is written for Safe; the logic carries to other multisigs.

Confirm and Contain

SEAL's multisig emergency procedures set the first 30 minutes:

  1. Halt all non-emergency transactions.
  2. Alert the team on every channel.
  3. Identify which keys may be compromised.
  4. Escalate to your security team, and record the timeline.

Confirm with the key holder directly, "not via potentially compromised channels", as SEAL's key compromise runbook puts it. If a chat account was taken over, treat its recent messages as suspect.

If the Safe holds admin powers over contracts, consider pausing those contracts until the rotation is done.

Assume others are exposed

Next, list what the suspect signer shares with the others:

  • The same signing interface or wallet software.
  • The same laptop build, browser extensions or password manager.
  • The same chat group, where one fake request reaches everyone.
  • The same outside contact, such as an investor who approached several signers.

Each shared item is a path to another key. Count the signers who could be exposed and compare that number with the threshold.

Clear Pending Transactions

A signature cannot be withdrawn. Safe's help center says signatures "cannot be 'taken back'".

A signed transaction stays executable until its nonce is used. The only way to void it is to sign and execute another transaction with the same nonce.

  • Review every queued transaction, who signed it and who proposed it.
  • Replace anything unplanned with a harmless transaction at the same nonce.
  • If signers may have signed future nonces, use up those nonces as well.

Rotation does not do this for you. Safe counts only current owners' signatures, so removing an owner voids theirs, but signatures from owners who stay remain valid.

Solana councils differ. BlockSec notes that a durable nonce approval cannot be revoked unless the nonce authority advances the nonce. See the Drift exploit.

Rotate to a Clean Quorum

Safe changes its owners through its own transactions. Each of these "can only be done via a Safe transaction", per Safe's docs:

FunctionWhat it doesUse it when
swapOwnerReplaces one owner with a new addressDefault: keeps the signer count the same
removeOwnerRemoves an owner and sets a new thresholdNo replacement is ready yet
addOwnerWithThresholdAdds an owner and sets the thresholdAdding a backup signer
changeThresholdSets a new thresholdThe owner set is clean again

Then work in this order:

  1. Quarantine suspect devices, the first of SEAL's recovery steps.
  2. Create each new key on a fresh hardware wallet with a new seed, as SEAL requires.
  3. Confirm each new address with its holder by voice or video, never through the suspect channel.
  4. Build one batch that swaps every suspect owner and sets the threshold.
  5. Have only trusted signers approve it, each checking the hash on a separate device.
  6. Execute, confirm the owners and threshold onchain from a second source, and only then resume operations.

Verify the rotation like any other transaction. See how to verify a Safe transaction before signing.

When the threshold is in doubt

If suspect signers could reach the threshold on their own, the attacker does not need you. Rotation becomes a race.

Then move first: funds and admin roles go to a new Safe built on clean devices, as in the section below.

Check Modules, Guards and Proposers

Owners are not the only way into a Safe. Check everything that can act without them, or around them.

  • Modules execute "without further confirmations", per Safe's code. Its docs warn that "a malicious module can take over a Safe."
  • A guard runs checks before and after each Safe transaction. Safe warns that "a broken Guard can cause a denial of service for a Safe."
  • The fallback handler receives calls the Safe does not handle itself. Confirm it is the one you set.
  • The implementation address sits in storage slot 0. Bybit's signers approved "a wallet implementation upgrade containing malicious code", per Rekt.
  • Proposers are stored offchain and "can prepare and suggest transactions" without signing. Treat proposals from any proposer the suspect owner added as hostile.

Pull the Safe's events since the suspected compromise: AddedOwner, RemovedOwner, ChangedThreshold, EnabledModule, ChangedGuard and ChangedFallbackHandler.

Check outward powers too: token approvals the Safe granted, and roles it holds in your contracts.

Move Funds If Needed

Rotation fixes the Safe. Sometimes the Safe itself can no longer be trusted.

Move when suspect signers could meet the threshold, when you find a module or guard nobody approved, or when you cannot rule out either.

SEAL's key compromise runbook covers both halves: move hot wallet funds to cold storage or a new wallet, and transfer contract ownership to a secure address.

  1. Deploy a new Safe from a clean device, with owners created on fresh hardware.
  2. Send a small test transfer and confirm it arrives.
  3. Move assets and admin roles, largest exposure first.
  4. Update address books, integrations and monitoring.

WazirX did this after its July 2024 loss. On August 14, 2024, it began "migrating the remaining assets held with Liminal to new multisig wallets", per its incident log.

Post-Incident Review

SEAL's runbook asks how and when the key was compromised, what the attacker did, and "Are other keys at risk?"

  • Have the quarantined devices examined before anyone wipes them.
  • Alert on owner, threshold, module and guard changes. See Safe multisig monitoring.
  • Tighten the signer policy: dedicated devices, timelocks and out-of-band checks. See multisig best practices.

How Guardian Helps

Guardian's Managed Security maps every path to your funds: the contracts that hold them, the roles that can move them, and the keys, signers and multisigs behind each one.

Its security operations team reviews every multisig transaction before it is signed, and every configuration change as it lands. An OpSec audit reviews how your team holds, approves and changes keys.

Frequently Asked Questions

What should I do first if a multisig signer is compromised?

Halt non-emergency transactions, alert the team on every channel and identify which keys may be exposed, as SEAL's emergency procedures advise. Confirm with the signer through a channel the attacker cannot reach.

Does removing a compromised owner cancel pending signatures?

It stops that owner's signatures counting, because Safe only accepts signatures from current owners. Signatures from owners who stay remain valid for their nonce, so execute a replacement transaction at every pending nonce.

How do I change owners on a Safe?

Through a Safe transaction that calls swapOwner, removeOwner, addOwnerWithThreshold or changeThreshold. Each needs the current threshold of owner signatures, so build it carefully and verify the hash on devices you trust.

When should I move funds to a new Safe?

When suspect signers could meet the threshold, when you find a module or guard nobody approved, or when you cannot rule either out. WazirX moved its remaining assets to new multisig wallets after its 2024 hack.

Sources

Have every signer change reviewed as it lands

Guardian reviews every multisig transaction before it is signed and every configuration change as it lands, against a map of every path to your funds.