Squads Emergency Alert: Address poisoning and forged multisig accounts; a whitelist mechanism will go live

Solana native multi-signature protocol Squads issued a warning on the X platform on April 14, stating that attackers are carrying out an address poisoning attack against Squads users. By forging fake accounts whose first and last characters match those of real multi-signature addresses, they trick users into sending funds to malicious addresses or signing unauthorized transactions. Squads confirmed that there is no evidence that user funds have been harmed, and said this is a social engineering attack at the interface level rather than a security vulnerability at the protocol level.

Attack Mechanism Breakdown: How a Two-Layer Deception Structure Creates Fake Accounts

Attackers use publicly available public-key data on the blockchain to design a double-deception architecture.

First layer: Automatically add the target user to a forged multi-signature account The attackers read the public keys of existing Squads users from the chain, programmatically create a new multi-signature account with the target user as a member, and make the forged account appear in the interface like an organization that the user is “legitimately participating in.” This lowers the target user’s vigilance.

Second layer: Generate “vanity” addresses with matching first and last characters Using address collision computations, attackers generate a public key whose first and last characters are exactly identical to those of the user’s real multi-signature address. When combined with the habit of most users to check only the first and last characters of an address, the forged account has a fairly high probability of visually deceiving users.

Squads clearly stated that the attackers cannot directly access or control user funds through the methods above. All loss risk comes from actions users take after being tricked, not from a technical protocol-layer breach.

Squads’ Phased Response Measures

Immediate warning banner: Within two hours after the attack is detected, show a warning banner on the interface targeting attacks against suspicious accounts

No-interaction account alert: Add a dedicated warning prompt to multi-signature accounts that have never interacted with the user, reducing the risk of accidental actions

White-list mechanism rollout: In the coming days, introduce a white-list mechanism that allows users to clearly mark known trusted multi-signature accounts, and the system will automatically filter unknown accounts

Immediate user protection recommendations: Ignore all multi-signature accounts that were not created by you personally and were not explicitly added by clearly trusted members; when verifying addresses, perform a complete character-by-character comparison—never rely solely on visual matching of the first and last characters.

Broader Context: Solana Ecosystem Social Engineering Threats Keep Escalating

This Squads address poisoning attack is part of a broader escalation of social engineering security threats in the Solana ecosystem recently. Earlier, there was a $285 million theft incident involving the Drift protocol. Investigating organizations determined that it was mainly due to social engineering rather than a flaw in smart contract code—attackers spent months impersonating legitimate trading companies, gradually gained trust, and obtained system access permissions.

The Solana Foundation and Asymmetric Research have launched a STRIDE security program for this purpose, to continuously monitor and replace traditional one-time audits with formal verification, and to establish a Solana Incident Response Network (SIRN) to coordinate real-time crisis response across the whole network. After the Drift incident, multi-signature setups and high-value protocols in the ecosystem are facing more stringent security scrutiny, and Squads’ rapid response model provides a reference template for crisis response for other protocols in the ecosystem.

Frequently Asked Questions

What is an address poisoning attack? What is special about the Squads case?

An address poisoning attack typically refers to attackers creating fake addresses that closely resemble the target address, tricking users into taking incorrect actions. The special aspect of the Squads case is that the attacker not only collides to generate vanity addresses whose first and last characters match, but also automatically adds the target user to the forged multi-signature account—making the fake account look like a legitimate organization that the user has “participated in,” with an even more complex layer of deception.

Does the Squads multi-signature protocol itself have a security vulnerability?

Squads explicitly denies a protocol vulnerability. The attacker cannot use address poisoning to access existing users’ multi-signature account funds, nor can they change the member settings of existing multi-signature accounts. This attack is social engineering at the interface layer, relying on deceiving users into making incorrect actions themselves rather than a technical intrusion.

How can users identify and defend against this type of address poisoning attack?

There are three core protection principles: one, ignore all multi-signature accounts that were not created by you personally or were not explicitly added by trusted members; two, perform a complete character-by-character comparison when verifying addresses—do not rely only on visual matching of first and last characters; three, after the Squads white-list mechanism goes live, actively mark trusted accounts via the white list to improve the reliability of account identification.