25 Sep 2026 Demex Exploit Post-Mortem

On 25 September, Demex's bridge was exploited. Roughly $191,929 in ETH and BNB was taken from the contracts holding bridged funds. The admin multisignature account performed an emergency chain halt transaction 52 minutes after the first exploit withdrawal.

The assets taken were the reserves backing bridged ETH and BNB held by Demex users.

Below is the post-mortem analysis of the exploit.

🚨 What Happened

The attacker manipulated Demex's bridge registry, pairing nLEND — an ordinary Demex token worth around twelve cents — with the canonical WETH contract on Ethereum and the canonical WBNB contract on BNB Chain.
They then withdrew 87.27 nLEND, worth about $10. Because the bridge releases assets against that registry unit for unit, it paid out 64.78 WETH on Ethereum (about $174,495) and 22.49 WBNB on BNB Chain (about $17,434) — roughly $191,929 in total.

🔍 How It Was Executed

Demex's bridge consists of two parts:

1. A contract system on each connected network, holding the bridged assets.
2. Demex's bridge module, which keeps a registry pairing each Demex token with its contract on each network.

When you withdraw, the bridge module reads that registry to decide what to release and which network to send it to.

Registry entries are recorded when native tokens are deployed on external networks. The contract system carries out the deployment and reports back to the bridge module to record the new pairing.

The gap was in how the two parts trusted each other. The bridge module trusts these reports because they originate from the contract deployer. The contract system, in turn, trusts instructions that originate from the bridge module. Neither side independently verified what the other reported.

The attacker began preparing at 13:03 UTC. They bought the 95 nLEND they needed on Demex's own order book for about $60, deployed a helper contract on Ethereum, then made four attempts to have a token deployment reported back to Demex — all four failed.

One point to note is that nLEND itself was not the weakness — a number of other Demex tokens would have served just as well. The attacker needed a token that was cheap to buy and that used the same eighteen decimal places as WETH and WBNB, so the amounts would carry across one for one.

The attacker also tried the legitimate route at 18:22 UTC, submitting a direct request to register the pairing themselves. This was rejected by Demex as an unauthorised request, exactly as designed.

At 18:29 UTC, the attacker's fifth attempt succeeded. Through Demex's generic execute flow, they triggered a native token deployment on the contract system. They used their helper contract to falsify a deployment report — one naming the canonical WETH contract as the "newly" deployed nLEND contract. Both the contract system and Demex accepted the false report and registered the pairing of nLEND to the WETH contract.

At 19:09 UTC the ETH withdrawal went through, matching the Ethereum gateway's entire WETH balance.

They then repeated the sequence on BNB Chain against WBNB, where it took four minutes from first request to payout. The stolen WETH was unwrapped to ETH within three minutes and moved on across a series of transfers; the BNB was bridged to Ethereum and joined it.

One further failure let this pass unnoticed. We cap withdrawals at $50,000 in any 24 hours, but the guard priced what was deducted rather than what was released. It valued two withdrawals worth roughly $192,000 at $10.47 and passed them as routine.

No administrator key was stolen, and no validator network was compromised. The attacker did this with an ordinary account, using the bridge's own logic against itself.

🛡️ What the Halt Prevented

The attacker did not stop at two chains. They had a working method and were moving through our connected networks one at a time. At 19:47 UTC, minutes after the BNB Chain payout, they queued the same sequence against Base — but it was stopped by the emergency halt.

An emergency halt is not a single action — it requires a multisignature transaction from Demex's admin account, signed by several team members. The attack appears to have been deliberately executed at a time when most of the team would have been asleep and unable to respond. Even so, the chain was halted within 37 minutes of confirmation, and that swift response protected the $976,000 still held across Demex's bridge reserves.

We would also like to thank the community member who flagged the exploit transaction within minutes of the attack, accelerating our defence even further.

📅 When It Started

While preparing this post-mortem, we searched our history for earlier signs of the attack. The first attempt we can trace was in June, three months earlier, though we cannot confirm it was the same attacker.

Over four days that month, probes were run against Demex's bridge, but every attempt was rejected. Nothing was taken, and nothing in our records looked like damage. The failed transactions those probes produced were indistinguishable from everyday noise and were treated as such.

🛑 Where Our Defences Fell Short

Demex's bridge is two systems: the contracts deployed on Ethereum, BNB Chain, other networks, and the Demex chain itself. They communicate across a boundary, and both were built and audited to trust each other. The attacker exploited that seam.

The contracts were professionally audited in late 2024. The audit surfaced no security flaw that would have allowed this attack.

We also ran AI-assisted reviews over the Demex codebase while preparing it to be open sourced, and those did not flag it either. The large size and complexity of the Demex codebase posed challenges in conducting these reviews. Additionally, the vulnerability only appears when both systems and the exchange that passes between them are reviewed holistically.

Our guards did not trigger. The exploit was caught instead by an alert on suspicious activity, three minutes after the first withdrawal.

Attacks like this on Cosmos chains have increased in recent months. The precision here stands out — the amount taken from Ethereum matched the reserve exactly, down to the smallest unit. The attempts were methodical, probing the two interconnected systems. We were targeted by an experienced operator.

There are things we should have done differently. We should have had both systems audited as a whole. We should have monitored bridge balances independently, rather than relying on a guard only on Demex. And we should have alerted on changes to the bridge registry itself, which would have surfaced this within minutes. These are failures in our engineering and review process, and we take full responsibility for them.

🛠️ What Happens Next

Demex will remain halted until further notice.

Our immediate task is a full accounting of every token the bridge is responsible for — both the balances recorded on Demex and the reserves held in the contracts on each connected network.

Alongside that, we are reviewing Demex for any further gaps and working on the necessary fixes.

We will share updates as that work progresses.

💬 Final Thoughts

We are sorry for this incident. Despite our best efforts, the space has become increasingly adversarial with the advancement of AI agents, and the trust placed in Demex has been damaged as a result. The team is evaluating the best path forward and is optimistic that remediation of the lost funds will be possible.

Demex has been carried by this community for years. We ask you to bear with us while we work through this, and we will keep you updated at each step.

Thank you for your patience,
The Demex Team