M13 Digital

Providing On-chain Intelligence Services and Tools → instant security alerts on Telegram ↓

[M13 Digital @m13_digital]

M13 Alerts PRO serves different operational needs depending on who is using it:

https://t.co/dLAT8MmQck

For protocols that want to demonstrate operational control to their users, investors, or counterparties, the system provides an independent, continuous audit of their own administrative activity. Every governance action, every upgrade, every parameter change is recorded and classified.

For funds and asset managers with DeFi exposure, the system provides continuous confirmation that the protocols holding their positions are operating within expected parameters. Administrative changes, unusual TVL behavior, or oracle anomalies are detected immediately. The AI-generated descriptions translate every technical event into human language, making the information accessible to non-technical stakeholders without losing precision.

For security analysts and forensic investigators, M13 Alerts functions as a real-time intelligence layer and evidentiary record. The full event trail (address, transaction hash, block number, event type, decoded arguments, severity, and temporal correlation with prior events) is available for any monitored project. This record supports both active investigation and retrospective analysis with the depth of detail that security work demands.

For independent investors conducting due diligence before allocating to a protocol, the onboarding assessment produces a structured map of the protocol's dependencies and risk surface, identifying single points of failure, unusual access control configurations, and architectural vulnerabilities before any monitoring begins.

#BlockchainCompliance #DeFiSecurity #BlockchainAnalytics #FundManagement #DueDiligence #OnChainMonitoring #BlockchainForensics #BlockchainIntelligence

[M13 Digital @m13_digital]

Exploiter address ETH:
0xD1ea823D421E0c829ee11F772AF487fd352678EA

Exploiter address BSC:
0x6aa22cb8420e94fc2119364b4c7885710ae753bb

Malicious Implementation on ETH: 0xee1bd9356fe66591f600d5769f3e0e03f012cafa

Malicious Implementation on BSC: 0xd18cdc9f07733ca207e9977879c51e22e9b57fcb

Compromised Safe Multisig 3/6 ETH:
0x576412843C35af26a16Cff903363F6dc429f8A2a

TransferOwnership TxHash ETH:
https://t.co/p3bCo7Ium1

[M13 Digital @m13_digital]

🛡️ #SecurityAlert

Humanity Protocol and its founder Terence Kwok have confirmed a security incident involving the compromise of a private key of a Humanity Foundation member, which resulted in the draining of more than $30M from wallets linked to the project.

The price of the $H token dropped by ~90% in reaction to the dumping into Ethereum swaps. For now, there are no signs of vulnerabilities in the smart contracts or in the Proof-of-Humanity mechanisms based on biometrics.

[Humanity @Humanityprot]

We're aware of a security incident involving the compromise of private keys belonging to a member of the Humanity Foundation. The safety of our community is our top priority, and we want to be fully transparent about what we know.
As a precaution, please do NOT interact with the bridge or any liquidity pools until we give the all clear. This is the single most important step you can take to protect your funds right now. We are actively working with leading security experts and our exchange partners to assess the scope of the incident and secure all affected systems.
We're deeply sorry that this has happened. Protecting this community is our responsibility, and we don't take that lightly. We will share verified updates as soon as we have them and we won't speculate before facts are confirmed.

Official updates will only come from this account or @terencekwok
Beware of the scammers and impersonators who exploit moments like this. We will never DM you first or ask for your seed phrase or private keys.

[M13 Digital @m13_digital]

In short, the root cause was the compromise of a Gnosis Safe multisig (3/6), where 3 out of 6 keys were controlled by a SINGLE OPERATOR.

https://t.co/WsT4q7eXl1

With these 3 keys, the attacker executed transferOwnership() on the ProxyAdmin, took full admin control, and deployed a malicious implementation upgrade on both Ethereum and BSC, which allowed them to drain and mint new $H tokens.

[Humanity @Humanityprot]

INCIDENT UPDATE:

Last night, June 8, the H token was hit by a coordinated attack across Ethereum and BSC. While we’re still investigating this incident, we want to be transparent with our community about what happened.

As of right now, ~$36M+ has been stolen across both chains and dumped. This was a result of a breach that happened after an employee’s laptop was compromised.

Three of six Gnosis Safe owner keys controlling the Hyperlane bridge ProxyAdmin were compromised. The attacker used these to transfer ProxyAdmin ownership to their own wallet, then upgraded the bridge contract to a malicious implementation and swept ~141.2M H in a single transaction.

Three of five BSC Safe owner keys were also compromised. The attacker performed the same ProxyAdmin seizure on BSC, deployed a malicious implementation with an unlimited mint function, and minted 200,000,005 H in two tranches directly to their wallet.

We’ve now halted all deposits and withdrawals to the affected bridges and are working with all related parties, including exchanges, to minimize the damage. Further to our internal investigation, we’re also working closely with the police to investigate this incident and recover some of the stolen funds.

People in this community worked hard for what they hold here, and we feel the weight of that. We want to apologize for what has happened and thank you for your patience, messages, and for sticking with us.

[M13 Digital @m13_digital]

Exploiter address:
0x4925120CbE5A78Bf08F26f6E8cdF820f4c1D3dfB

Ethereum Claim FLUID TxHash:
https://t.co/qRNCwkznu3

[M13 Digital @m13_digital]

🛡️ #SecurityAlert

Fluid contained a security incident that compromised the off-chain merkle rewards distribution infrastructure across the Ethereum, Base, and Arbitrum chains, resulting in the draining of 125k $FLUID (~$185k) and 51.9k $GHO (~$51.7k).

[Fluid 🌊 @0xfluid]

We identified and contained a compromise affecting our off-chain merkle rewards distribution infrastructure.

Importantly:

• The core protocol remains fully secure and is governed by governance and the 7/14 team multisig.
• All protocol smart contracts are safe and unaffected.
• User funds are not at risk from this incident.

The impacted contract is not part of the core protocol infrastructure and was used solely for rewards distribution with minimal funds in its balance.

Our team is actively investigating the incident. We will share a detailed post-mortem as soon as possible.

We appreciate the community’s patience and support as we work through this.

[M13 Digital @m13_digital]

Source: https://t.co/sFxzSxfMkf

[YAM 🌱 @yieldsandmore]

Fluid lost 125k FLUID and 51.9k GHO due to a key compromise.

A wallet was able to claim rewards from multiple Fluid Merkle distributors using empty-proof Merkle claims, then swap funds and route ETH into Tornado Cash.

Exploiter: https://t.co/7xhmZpwqE3

The timeline on Ethereum was very tight: proposer submits root, approver approves it, exploiter claims FLUID ~24 seconds after proposal. The GHO claim followed minutes later. The same wallet then swapped the claimed GHO and FLUID, bridged some Base/Arbitrum proceeds out, and later deposited ETH into Tornado Cash Router.

Several hours later, an admin-style batched tx removed the old proposer/approver roles across multiple Fluid rewards contracts:
https://t.co/Gx4G8uPdTg

Fluid has told users that Merkle reward claiming is temporarily paused for a few days, potentially up to a week, while updates are made. They also said rewards will continue accumulating retroactively and claiming will resume once updates are complete. No communication about a key compromise or loss of funds.

[M13 Digital @m13_digital]

Taking into account that 34 hours before the drain, a wallet dormant for over 9 months called the updateValset() function, reducing the validator set from 58 to 34, the most likely root cause is a compromise of the signing infrastructure.

Exploiter address:
0x7B582033061b96cC3F9421e73a749ED7C62da1F9

updateValset() TxHash:
https://t.co/yU6T25XGvc

[M13 Digital @m13_digital]

🛡️ #SecurityAlert

The Gravity Chain, which operates as a bridge between Ethereum ⇆ Cosmos, was exploited today through the Gravity Bridge contract on the Ethereum side resulting in the drain of ~$5.4M, specifically 4.3M $USDC, 274 $WETH, 434K $USDT, and ~14.1K $PAYG.

[Gravity Bridge @gravity_bridge]

There was an unfortunate incident on Gravity. Validators should halt their validators and orchestrators while this incident is being investigated.

[M13 Digital @m13_digital]

Source: https://t.co/35mEr8Z7Du

Exploiter address:
0xC4574DDEF299e7E563971e200433e592EeaaFA69

Original owner:
0x47BAcf935066b802EAA0067eC14AB035B24eB78b

transferOwnership() TxHash:
https://t.co/LxiU2w1srx

0xC4574D... setting EIP-7702 delegation:
https://t.co/qm6UN896SC

Removed liquidity (example Tx):
https://t.co/8U5RZUcUVR

[GoPlus Security 🚦 @GoPlusSecurity]

🚨 GoPlus Security Alert: DxSale Legacy Locker Exploit Drains $7.3M, Suspected Insider Involvement; Another $15.5M in Funds and LPs Still Require Emergency Action ❗️❗️

I. Incident Timeline

In August 2025, Telegram channels surfaced offering “DxSale insider-connected” services to unlock legacy LPs for sale publicly.

At 01:08 UTC on May 26, 2026, the original owner address 0x47BAcf93 called transferOwnership, transferring control of the locker contract to attacker address 0xC4574D.

On May 27, 2026 (20 hours before the attack), attacker wallet 0xC4574D received 104 BNB (~$67K) from Bybit as initial funding.

At 03:45 UTC on May 28, 2026, the attacker leveraged the EIP-7702 delegation mechanism to batch-drain more than 1,400 LP pools.

Within hours after the attack, the funds were routed through more than 80 wallet hops before eventually cashing out via multiple Binance addresses.

II. Root Cause Analysis

1️⃣ transferOwnership Lacked Security Protections:
The legacy DxSale locker contract (deployed in 2021) inherited the standard Ownable pattern for its transferOwnership function, allowing the owner to transfer ownership to any address at any time, without a timelock, without multisig protection, and without monitoring or alert mechanisms. Once the owner private key is compromised — or the owner itself becomes malicious — all assets locked in the contract face the risk of being fully drained.

2️⃣ Legacy Contracts Left Unmaintained for Years:
Since being deployed in 2021, the contract has continued holding a large amount of LP tokens from early BNB Chain projects, with the cumulative value exceeding tens of millions of dollars. However, these assets remained in a vacuum state: no audit updates, no security monitoring, original owners potentially having exited the industry, and contract code never upgraded.

3️⃣ EIP-7702 Was Abused for Batch Exploitation:
By leveraging the batch-processing capability enabled by EIP-7702, the attacker was able to drain more than 1,400 pools within a single transaction flow.

4️⃣ Suspected Insider Premeditation:
According to an investigation by eyeonchains (see Figure 1), as early as August 2025, Telegram channels were already openly offering services to “unlock legacy LPs through DxSale insider connections.” This indicates the attackers had long been aware of the exploitable nature of the contract owner privileges. Combined with the fact that the attack execution stretched across multiple days, proceeded at a controlled pace, and received no response from the project team, the incident strongly resembles a nine-month-long insider-planned exit operation.

🧐🕵️ Combined with DxSale’s historical infrastructure connections to projects such as SAFEMOON (whose team members were later criminally charged), the nature of this incident appears more consistent with an organized insider exit scam than with an isolated external exploit.

III. Attack Flow Analysis

1️⃣On May 26, the original owner account of the DxSale Legacy Locker contract 0xEb3a9C updated the owner address to attacker address 0xC4574D:
https://t.co/QAHi9MWQJd

Note:
In addition to the exploited Locker contract 0xEb3a9C, other Locker contracts whose owner was

updated to 0xC4574D include:
0x81E0eF68e103Ee65002d3Cf766240eD1c070334d (~$13.2M)
0x2D045410f002A95EFcEE67759A92518fA3FcE677 (~$2.2M)
0x5b5e94485c9628793B01A38762921Dc37B6829b6 (~$1.3K)

2️⃣The attacker deployed exploit contracts (such as 0x74Ad1E), then upgraded 0xC4574D using EIP-7702, with the Delegator set to the exploit contract address (such as 0x74Ad1E):
https://t.co/jjGU8jBsXr

3️⃣The attacker directly invoked the unlockToken function in the DxSale Legacy Locker contract using owner privileges, unlocking the LP tokens stored in the contract and transferring them to 0xC4574D:
https://t.co/CzLrIkkx6h

4️⃣ After obtaining the unlocked LP tokens, the attacker removed liquidity from the pools. Example transaction (see Figure 2):
https://t.co/bU4FqxoOzg

IV. Key IOC Summary

Exploited Locker Contract:
0xeb3a9c56d963b971d320f889be2fb8b59853e449

Original Owner (Suspected Insider / or Private Key Compromise):
0x47BAcf935066b802EAA0067eC14AB035B24eB78b

Primary Attacker Wallet
0xC4574DDEF299e7E563971e200433e592EeaaFA69

EIP-7702 Delegator Contracts
0x74Ad1Ef17Fbb3e494c31c72F7ec730A27FEf0310
0x996521B5Bb2bbF34764d89932f0Ea206e6A3A388
0xd6c7d6b19b9c05E8591542a13D297047C362d268
0xA0795423A2647eC750fEA5cAD3B709cFe7C814be
0xc2efbD94aeDFf1555b97ddCb216646DFC01e4718

Intermediate Aggregation Address A
0x47F80D09d1Bd0BB675ac627BDC1d1244731F66bf

Intermediate Relay Address B
0xF19acAD8E DCd733A8bF9175C93da9AB660afC747

Secondary Transfer Wallet A
0xb71c1C2A0cD7A88f1317f9A996e4d121E7db5E92

Secondary Transfer Wallet B
0x4c5ee9703653C8e7725C65593bff372655e0453C

Example Attack Transaction:
https://t.co/CzLrIkkx6h

V. Security Recommendations

1️⃣ Projects should immediately verify whether their LPs remain locked in contracts 0xEb3a9C56, 0x81E0eF68, 0x2D045410, or 0x5b5e9448. If affected, immediate action should be taken to withdraw funds. Approximately $15.5M in assets still require urgent self-rescue measures.

2️⃣ The initial funding source was Bybit (104 BNB), and KYC tracing is recommended. The final cash-out routes involved multiple Binance addresses, and relevant security teams are advised to submit on-chain evidence and request freezing of attacker-related accounts.

3️⃣ Security mechanisms must be strengthened. Critical admin functions should always be protected by timelocks, owner privileges must use multisig wallets, and all ownership changes should trigger manual review procedures (including those involving EIP-7702).

4️⃣ As of now, DxSale has not issued any public incident response statement, and its silence itself warrants attention.

[M13 Digital @m13_digital]

🛡️ #SecurityAlert

DxSale announced that it is investigating and will provide answers regarding the security incident involving the legacy 'DxLock' contract, deployed under the classic Ownable pattern on the $BNB Chain in 2021. The attack resulted in the draining of liquidity from more than 1,400 pools (~$7.3M).

On May 26, 2026... the original owner (0x47BAcf93...) executed a transferOwnership() to the controller address (0xC4574DDE...), using EIP-7702 delegation to batch multiple privileged owner operations that enabled the removal of liquidity.

[DxSale.Network @dxsale]

🚨 Incident Report 🚨

We're aware of a recent exploit and liquidity drain. Investigation is underway
🔍 Stay tuned for updates.

#DXsale #Security

[M13 Digital @m13_digital]

https://t.co/D2sjhwqZsi

[mrwildcat @mrwildcat7]

Unfortunately, a few hours ago, at least 297 wallets were drained across EVM chains. The funds were consolidated at the following address: 0x43D49AeF7aAf0Dcf015b20057C5364E092D66615 and were later distributed via @FixedFloat. Nearly $500k was stolen. I suspect a massive private key leak associated with a wallet provider.

[M13 Digital @m13_digital]

🛡️ #SecurityAlert

Bexo Wallet has confirmed the community alerts regarding an incident involving at least 297 wallets across different EVM chains, totaling ~$500k in stolen funds.

All transactions were directly signed with private keys, without TransferFrom() or Permit() functions. It is suspected that the exploiter compromised the infrastructure used to manage the storage/backup of seed phrases.

[Bexo @bexowallet]

🔒 Aviso importante para usuarios de Bexo
▎ Detectamos actividad irregular en algunas cuentas.

Recomendamos transferir tus fondos a una billetera externa.

▎ Estamos investigando y trabajando para resolverlo. Más info comunicandose con soporte via la app

Avisenles a sus amigos porfavor! Muchas gracias.

[M13 Digital @m13_digital]

🛡️ #SecurityAlert

The Sui blockchain network has stopped producing blocks for nearly 1 hour today.

Sui published the official statement:

[Sui @SuiNetwork]

Activity on Sui mainnet has resumed after a halt due to a crash bug in the gas charging logic introduced by the 1.72 release. A full incident review will be shared in the coming days.

[M13 Digital @m13_digital]

Exploiter address:
0xeF3C054d8F7eD0a7D61c8da56ff55F090577aa25

Malicious contract deployed on ETH:
https://t.co/tar6e6rgMA

StakeDAO Deployer compromised address:
0x000755Fbe4A24d7478bfcFC1E561AfCE82d1ff62

Set Peer() to the malicious contract:
https://t.co/x1Ln2pYVqS

Mint TxHash:
https://t.co/QP8LkN4LQc

[M13 Digital @m13_digital]

🛡️ #SecurityAlert

Apparently, the attacker compromised the deployer’s private key and modified the LayerZero v2 peer OFT config. in the vsdCRV contract, minting ~5.45T $vsdCRV tokens.

The exploiter then began swapping part of these tokens for ETH on Arbitrum DEXs. But due to low liquidity, they only bridged ~43.78 $ETH to Ethereum.

The remaining tokens are still held in the attacker’s main wallet.

[Stake DAO @StakeDAOHQ]

We are aware of the ongoing situation.
Please do not interact with vsdCRV.

[M13 Digital @m13_digital]

According to Squid’s team, the root cause of the exploit was that the module accepted a constant string provided by the caller as proof of security, which allowed arbitrary calls to be executed and funds to be drained.

In total, 86 Gnosis Safes with approvals for the SquidRouterModule were drained in approximately two hours. The victims had added this faulty contract as a trusted Safe Module, granting it unrestricted access to the tokens in their Safes.

[M13 Digital @m13_digital]

🛡️ #SecurityAlert

The Squid team reported today that the incident involving the 'SquidRouterModule', which caused losses of ~$3.2M on the Base and Ethereum chains, is not related to the protocol.

This was a third‑party Gnosis Safe module, a smart‑wallet product that integrated Squid Router without prior contact.

[squid @squidrouter]

This incident is unrelated to Squid’s core protocol and contracts. All Squid users and integrators are unaffected and no action is needed.

A third-party Gnosis Safe module was exploited today across Base and Ethereum, resulting in approximately $3.2M in losses. The vulnerable contract is verified on Basescan under the name “SquidRouterModule” but this contract was not built, deployed, or operated by Squid. It is a third-party smart-wallet product that chose to integrate with Squid, among other protocols, but has not been in contact with us.

The exploit worked because the third-party module accepted a caller-supplied constant string as proof that a message was secure. If you pass in this string (which is publicly available in the verified contract’s code), then you can execute an array of arbitrary calldata, stealing funds at will. The victims’ Safes had added this faulty contract as a trusted Safe Module, which gives the contract the ability to spend any tokens in the Safe without signatures. Squid’s own router (0xce16F69375520ab01377ce7B88f5BA8C48F8D666) is architecturally different and was not touched. Squid user funds, approvals, and integrations are fully secure.

Early public reporting may reference “SquidRouter” due to the contract’s verified name on Basescan. The accurate framing is: a third-party SquidRouterModule was exploited, not Squid’s Router contract. The contract shares our name but is not our code. We are monitoring the situation and will share updates if anything changes materially.

[M13 Digital @m13_digital]

Exploiter address:
0x9BDC730183821b6bb2B51BE30B77C964FA645b91

Consolidated funds:
0xA447F71782135AB96a71374271a749Ff7AA54859

[M13 Digital @m13_digital]

Exploiter address:
0xD4677B5A8B1b97EA213Fdb876b0FcBAB3f9F6CD1

Compromised owner:
0xC73fD562de86d7860EE636C20813Bcb2cF4D550d

$EURR Owner change TxHash:
https://t.co/KiMyEaBDoY

$USDR Owner change TxHash:
https://t.co/CFRbBW4D0m

[M13 Digital @m13_digital]

🛡️ #SecurityAlert

A private key compromise of an owner in a 1/3 Multisig resulted in abusive mints on the $EURR and $USDR token contracts, causing a loss of $2.8M.

The exploiter added themselves as owner, replaced the other two owners, then minted millions of USDR and EURR tokens, and finally swapped them for just ~1.12 $ETH ($2.8M) due to liquidity limitations.

[StablR @StablREuro]

Security update: We have identified an exploit affecting StablR and are actively working to contain it and minimize impact.

Protecting our users and your funds is our top priority.

We'll share verified details and next steps as soon as possible.