Christmas week has a predictable rhythm onchain: Fewer engineers awake, more retail activity, more “quick checks” on phones, more copying and pasting, more trust placed in familiar interfaces. Attackers exploit that rhythm through timing, distribution, and gaps in how people ship code and move funds.
Chapter 1: The wallet that shipped itself a backdoor
It begins like most supply-chain incidents do: quietly, inside something users already trust.
A malicious release of the Trust Wallet Chrome extension (v2.68) was distributed, and users were later urged to move to v2.69. The malicious build ran in the browser, where the private material is briefly usable, and where a wallet must sometimes handle mnemonics and decryption paths as part of normal function.
From there the logic is brutally direct. The backdoored extension code iterated through wallet data, prompted for mnemonic phrases, decrypted stored secrets after the user unlocked the wallet, and exfiltrated the mnemonic to attacker infrastructure (public reporting points to api.metrics-trustwallet[.]com). Once the attacker has the seed, the rest is automation: recreate wallet, sign valid transactions, drain assets at the pace of opportunity.
The publishing path matters as much as the payload. Reporting describes the malicious version as published outside the normal release flow, with signs that developer secrets and store publishing capability were abused (Chrome Web Store API key misuse and compromise of developer secrets have been discussed in incident coverage). The attackers used the update channel to deliver malicious code. The impact was reported in the $7M–$8.5M range with thousands of affected wallets.
In a holiday window, that’s the perfect crime: It scales, it’s fast, and every drained wallet looks “legitimate” onchain because it is.
Chapter 2: The New Year email that only needed one signature
As the calendar flips, the attacker switches from distribution to persuasion.
Investigators flagged a cluster of drains across EVM chains: hundreds of wallets, typically under $2,000 each, totaling over "07,000 at the time of reporting. Victims described an email framed as a mandatory MetaMask upgrade, wrapped in New Year branding.
A campaign that consistently takes small-to-medium amounts across many wallets often fits “approval drainer” economics more than “seed compromise” economics. With a seed, the attacker empties everything quickly. With approvals and signatures, the attacker relies on users being logged-in, signing what looks routine, and granting a spender contract the right to move tokens later.
So the likely flow is simple:
- lure to a clone site,
- prompt a “verification” that is really a signature or approval,
- use that authorization to transfer tokens out, chain by chain, wallet by wallet.
It’s the quiet cousin of a full key theft. No malware needed, no exploit needed, just one convincing prompt when the user’s guard is down.
Chapter 3: The address that looked right in the transaction history
Then comes the kind of attack that feels almost unfair because it’s pure interface friction turned into loss.
Address poisoning exploits how people verify address strings.
A single incident dominated December’s loss totals: roughly $50M USDT lost to an address poisoning scam. The victim’s behavior reads like “best practice,” which is what makes it so effective: Withdraw from an exchange, send a small test transfer to confirm the destination, then send the real amount.
The attacker waits for the test. Then they send a dust transfer from an address engineered to resemble the true recipient (matching prefix and suffix characters), so it appears in the victim’s recent transaction list. When the victim later copies the address from history, they pick the poisoned entry and send the large transfer to the attacker.
No deception onchain, only deception in what the wallet UI makes easy.
Chapter 4: Protect the signers behind a “Multisig”
Holiday incidents also lean into a recurring theme: Teams and whales rely on multisigs, then discover the real boundary is the endpoint where signing happens.
A whale multisig reported as 0xde5f…e965 was drained for ~$27.3M, with ~4,100 ETH routed through Tornado Cash, and indications that remaining positions were still attacker-controlled. The initial classification was “private key compromise.”
Then the deeper forensic narrative surfaced: Analysis cited by coverage suggests total losses may exceed $40M, with indicators dating back to early November, and a striking detail: The multisig’s ownership may have been flipped to attacker control minutes after creation, implying the multisig could have been compromised almost from birth and used as a staging structure.
A “multisig” depends on the security of its signers and governance. If signer devices are compromised, if the initial owner set is tampered with, or if governance is captured, the multisig simply becomes an attacker-run Safe with better branding.
Chapter 5: Endpoint malware, cross-chain consequences
One of the clearest examples of endpoint compromise around year-end incidents was the babur.sol case: ~$27M stolen spanning a Solana wallet and an Ethereum Safe multisig. Public reporting attributes the initial access to malware execution on the victim’s computer, followed by private key exposure, including keys relevant to the Safe.
The mechanics are classic and ugly:
- the attacker wins the machine,
- the machine yields keys or seed backups or signing capability,
- the attacker signs valid transactions on multiple networks,
- the theft crosses ecosystems because the user does.
In a sense, this is the purest “blockchain attack” story: Nothing happened to the blockchain. The blockchains worked fine. The user’s endpoint didn’t.
Chapter 6: When governance is the exploit surface
The final category is the one defenders dread because it looks like legitimate admin activity until it’s too late: Governance and upgrade privileges.
Unleash Protocol (Story ecosystem) suffered an unauthorized contract upgrade and subsequent asset transfers, attributed to governance privilege compromise (multisig authority abused). Stolen assets were reported across several tokens with confirmed losses around $3.9M, followed by incident response actions and public comms.
This pattern is consistent across ecosystems:
- attacker obtains enough governance power (stolen signer key, compromised signer device, misconfigured threshold),
- attacker upgrades implementation or changes privileged parameters,
- attacker drains value with “valid” admin calls.
The most sobering part is that many monitors won’t alert on an “upgrade” because upgrades happen all the time.
Epilogue: A network-level bug and a validator halt
Then, on Dec 27, the story goes from userland and app-land to chain operations.
Flow Foundation confirmed an exploit of a Flow execution layer vulnerability. About $3.9M was moved off-network before validators coordinated a network halt. Reporting describes bridging out via common cross-chain rails and a response that involved validators, bridges, and exchanges. Debate followed about rollback vs targeted recovery; public coverage notes Flow moved away from a full rollback after backlash.
This is the holiday nightmare scenario for a chain: exploit plus urgency plus governance decisions under pressure, with every option carrying tradeoffs.
New security tools and better user education can help protect digital assets.
Happy New Year 2026… Stay safe!