Introducing Blockaid's Risk Exposure:
A real-time onchain compliance solution that lets organizations monitor addresses, transactions, and act the moment they're exposed to illicit funds.
Powered by Blockaid’s first-party signals to make policies programmatically enforceable.
A sincere thank you to the @blockaid_ team for being the first to detect the exploit and for their support throughout the investigation.
We would also like to thank the @SEAL_911 team for their assistance and responsiveness during the incident.
The collaboration and professionalism shown by both teams have been invaluable as we work through this situation.
Based on additional information from our investigation and the Alephium team's analysis, the exploit does not appear to have involved a compromise of guardian private keys. Instead, it appears to have involved an exploit that allowed forged malicious events/messages to be observed and signed by guardians. We look forward to the Alephium team's forthcoming postmortem for additional technical details.
🚨Blockaid detected an exploit targeting the Alephium TokenBridge on Ethereum.
~$815K drained in ~7 minutes via 3-of-4 compromised guardian keys signing forged VAAs. 13.76M wrapped ALPH minted (>100% of prior supply) + USDT/USDC/WBTC/WETH unlocked from custody.
More details in 🧵
The StakeDAO deployer private key (0x000755Fbe4A24d7478bfcFC1E561AfCE82d1ff62) was compromised. The attacker used it to reconfigure the LayerZero v2 OFT peer on the vsdCRV (Vote Boosted sdCRV) token contract, redirecting trust from the legitimate Ethereum-side vsdCRVOFTAdapter to an attacker-deployed malicious contract - then sent a forged cross-chain message that minted 5,446,744,073,709 vsdCRV (~5.4 trillion tokens).
🚨 Blockaid detected an ongoing exploit targeting
@StakeDAOHQ on Arbitrum.
The attacker just minted over 5.4 trillion vsdCRV and is actively swapping it for ETH.
More details in 🧵
Blockaid expands Chain Support for @Aster_DEX:
→ Transaction Scanning across deposits, withdrawals, and perp activity
→ Address Scanning on every counterparty before capital moves
→ Token Scanning for honeypots, rugpulls, and impersonation
→ Risk Exposure for compliance screening, including sanctioned entities, mixers, stolen funds, and fraud operations
Trading firms and asset managers now have the real-time security and compliance coverage to meet institutional standards onchain.
Suspected root cause: SquidRouterModule executeSameChainActions() vulnerability. Attacker deployed Foundry-based exploit contracts that called the module's DelegateBundler path to impersonate authorized delegates on victim Safes. This allowed executing arbitrary Uniswap V3 swaps from each Safe, swapping
real assets for a worthless attacker-deployed token ("u", max supply, 42 holders). Attacker pre-seeded Uniswap V3 pools pairing "u" against target tokens, removed liquidity post-drain, and converted all proceeds to 3.07M DAI.
🚨 Blockaid detected an ongoing exploit targeting the SquidRouterModule on Ethereum and Base.
86 Gnosis Safes drained for ~$3M in ~2 hours.
All stolen tokens swapped to DAI via attacker-controlled Uniswap V3 pools.
More details in 🧵
Suspected Root cause: Private key compromise of a minting multisig owner.
The @StablREuro minting multisig had a 1-of-3 threshold - a single compromised key was enough for full control. The attacker:
1. Added themselves as owner
2. Replaced the other 2 legitimate owners
3. Minted 8.35M USDR + 4.5M EURR
4. Swapped ~$10.4M face value on DEXes, realizing 1,115 ETH ($2.8M) due to thin liquidity
This is not a smart contract bug - it's a key management and governance failure.
This is not a smart contract bug — it's a key management and governance failure.
🚨Community Alert
Blockaid's exploit detection system has identified an ongoing exploit on @StablREuro.
~$2.8M extracted so far.
Both tokens are depegged: 0x50753cfaf86c094925bf976f218d043f8791e408 (StablR Euro)
and
0x7b43e3875440b44613dc3bc08e7763e6da63c8f8 (StablR USD) on Ethereum.
More details to follow.
🔎 Suspected root cause - TL;DR
The bridge authenticates cross-chain message retries with keccak256(abi.encodePacked(...)) over four consecutive dynamic-bytes fields (initiator, from, to, swapData). abi.encodePacked has no length prefixes, so the field boundaries aren't encoded - different field allocations can pack to the identical byte string and therefore the identical keccak.
The attacker:
1) Originated a real, oracle-multisig-signed MAP→ETH message to a precomputed CREATE address. Destination had no code yet → bridge cached a "NotContract" retry commitment.
2) Deployed the exploit contract at that exact address.
3) Called retryMessageIn with rearranged bytes-field boundaries that pack to the IDENTICAL 601-byte string as the planted message → same keccak → guard passes → bridge mints 10^15 MAPO (~4.8M× supply) to attacker.
Not a key compromise, not a light-client bug, not a MAPO bug. Pure Solidity abi.encodePacked footgun on multiple dynamic-bytes fields.
🚨 Community alert
@MapProtocol / @ButterNetworkio bridge exploited on Ethereum and Bsc.
Attacker tricked Butter Bridge V3.1 (OmniServiceProxy) into minting ~1 quadrillion MAPO — about 4.8M× the legitimate ~208M supply — directly to a brand-new EOA.
More details in🧵