Address poisoning (or "address spoofing") is a relatively new way of tricking crypto wallet users and making them send funds to scammers.
How it usually works
A malicious actor scans a victim's transaction history to identify addresses that are frequently used for outbound ERC20 transfers
Then they generate one or more addresses that look very similar to the above, normally having the same (or almost the same) last 4 symbols
Finally, they generate a transaction that shows up in the wallet transaction history and mimics a legitimate transaction
In the screenshot below there's how it looks in the Safe{Wallet} UI. As you can see, a scammer sent an equal amount of USDC (which is a fake USDC but has the same symbol) and used an address that has the same 3 first symbols and 4 last symbols.
What happens next, usually, is a wallet user might copy the scammer's address thinking that they copy a legitimate one, and send real money to it.
How Safe{Wallet} protects users from address poisoning
We detect the transactions that look like imitations, using the criteria described above, plus the fact that a transaction wasn't executed by Safe itself.
These transactions are marked as malicious (see screenshot above) and a user gets a warning on copying this address (see screenshot below).
Nested Safe poisoning
A more sophisticated variant of address poisoning has recently been discovered, specifically targeting Safe{Wallet} multisig users through the "nested Safes" feature.
How it works
Anyone can create a new Safe and add any other existing Safe as one of its owners. When they do this, the newly created Safe automatically appears as a "nested Safe" in the parent Safe's UI even though the parent Safe's signers never created or authorized it.
Attackers exploit this by:
Identifying high-value Safe multisigs and their signers
Bulk-creating malicious Safes (in one observed campaign, ~200 were created in a single transaction) with lookalike addresses that closely match the victim's legitimate nested Safes
Adding the victim's Safe as an owner on these malicious Safes, causing them to surface in the victim's UI as seemingly legitimate nested Safes
Pre-signing transactions on the malicious Safe so that any funds sent to it are immediately drained to an attacker-controlled wallet
With a similar-looking address and a zero balance (just like any newly created Safe would have) — a user can easily mistake it for their own and send funds directly to it.
Why this is particularly dangerous
Unlike standard address poisoning, which relies on a user copying an address from their transaction history, nested Safe poisoning plants the malicious address close to the original Parent Safe. On first glance this makes it far harder to spot, especially for teams that frequently create and manage sub-accounts.
How Safe{Wallet} has responded
Following this discovery, the Safe team took immediate steps: flagging all identified malicious addresses via security partners and building backend filtering to detect lookalike addresses (matching prefix/suffix patterns), along with developing improved curation UX that requires users to explicitly select and verify their nested Safes rather than having them auto-populated.
You can see an example of this below;
How to protect yourself
Always verify the full address of any nested Safe before sending funds, not just the first and last few characters. Cross-reference the address with what was shown on-chain at creation time, and treat any unfamiliar nested Safe appearing in your UI with suspicion, even if it looks like one you just created.