Bridge Incident Post-Mortem

On January 16, 2026, an attacker gained unauthorized access to a signing wallet used by the Dusk to EVM bridge service.

This was not a consensus failure nor was it a protocol exploit in Dusk itself. It was a bridge wallet compromise. We filed a police report after the incident, preserved the transaction and server access trail across Dusk and BNB Smart Chain, and informed relevant exchanges.

The bridge service sits on top of the protocol and inherits real economic trust, so we took the time to harden it heavily. This post-mortem covers what happened, what caused the incident, and what has changed since.

What Happened

The bridge relied on a Dusk signing wallet to fulfill EVM migration events. On January 16, an unauthorized actor gained access to that wallet and began draining funds directly on Dusk. The same actor then used the bridge path to move part of those funds onto BNB Smart Chain.

The on-chain sequence:

• 21:28:45 UTC: 9,000 DUSK stolen [1]
• 21:36:15 UTC: 7,880 DUSK bridged [2]
• 21:43:45 UTC: 89,700 DUSK stolen [3]
• 22:09:05 UTC: 2,743,310 DUSK stolen [4]
• 22:35:45 UTC: 1,911,180 DUSK bridged [5]
• 23:24:15 UTC: 8,068,000 DUSK stolen [6]
• 23:27:55 UTC: 8,910,000 DUSK bridge attempt failed after mitigation [7]

On BSC, the bridged DUSK landed on 0x068532fa71338409408d85e29284ca99c016729e, moved through 0x4775523CB09B817f829CAa383EEb79b5aF483b03, and into Binance 51 at 0x8894E0a0c962CB723c1976a4421c95949bE2D4E3. The attacker's BSC address had been funded with gas from an HTX-labeled wallet three days earlier.

We shut the bridge down at 23:12 UTC after an internal compromise report came in. That shutdown is what caused the final 8.91M DUSK bridge attempt to fail.

The Cause

The direct cause was key compromise. A Dusk signing wallet used by the bridge became accessible to an unauthorized party, and that was enough to move funds.

The bridge at the time was designed as a lightweight integration service built for speed and operational simplicity. It was a practical choice for an early-stage bridge serving a specific migration use case, and it operated without security incident from launch until this event.

The limitation of that design was that the signing wallet, event handling, and network connectivity all operated within a single path. This worked reliably under normal conditions, but once the signing wallet was compromised, it gave the attacker access to more than a segmented architecture would have.

Following the incident, the bridge was fully redesigned with stronger isolation between every component.

What Changed

Remediation started immediately and expanded into a full bridge redesign. These were not  simple patches but a complete change to the operating model.

1. Signing separated from event handling

Signing now lives in a dedicated wallet path with clearer process boundaries and more deliberate secret handling. The risk surface is narrower and the service is easier to reason about.

2. Event ingestion and fund release decoupled

Confirmed EVM events are ingested and checkpointed, migration events are persisted as jobs, and a dedicated worker processes pending jobs under an explicit state machine. Ingestion is no longer equivalent to spending.

3. Explicit transaction lifecycle

The bridge runtime uses a clear lifecycle: seen, submitted, completed, failed, stuck. It persists the raw Dusk transaction before broadcast and re-propagates the same transaction if needed instead of rebuilding a new one. That closes a whole class of correctness failures around duplicate sends, lost sends, and ambiguous recovery.

4. Hot-wallet exposure reduced

The redesign keeps minimal bridge-operational balance available to the signer, pauses when funds are low, and requires manual top-ups from a cold wallet. The hardened service uses explicit balance thresholds so it stops early instead of running the wallet down to zero, and only resumes after an intentional top-up.

5. Host hardening formalized

The incident forced a stronger deployment model: strict service isolation, tighter secret handling, a locked-down runtime, and less ambient access on the bridge host. The bridge now runs as a completely isolated service.

What We Learned

The original design accepted a speed-versus-isolation tradeoff that was reasonable only if the probability of compromise stayed low. That assumption turned out to be too optimistic.

The original bridge was the fastest way to ship something functional, operate it with a small team, and keep the integration surface manageable. That tradeoff bought speed but concentrated too much trust in one operational path. Once that path was compromised, the attacker did not need a protocol exploit or a consensus break.

In the logs and host-level evidence we reviewed, we did not find signs of a broader machine compromise, unauthorized system access, or filesystem tampering that would point to a confirmed host intrusion. The confirmed finding is narrower: the bridge signing path was compromised, and the old bridge design gave that compromise too much reach.

The engineering conclusions are:

• Bridge release authority, event ingestion, and recovery logic should not collapse into one thin operational path
• The signer should have access only to the balance needed for near-term flow
• Deployment hardening is part of bridge design, not something you deal with later
• Recovery semantics matter because once something goes wrong the system has to fail closed and stay easy to reason about
• Fast shutdown paths matter because the first hours of an incident are about containment, not elegant fixes

A bridge sits inside the asset's real security perimeter as soon as users treat it as a liquidity venue. That makes operational design choices part of the security model, even when the protocol itself is working correctly.

The redesigned bridge reflects every one of these conclusions. The architecture is fundamentally different and the hardened design has been stable since release.

Transaction references:

[1] d1e23f3a1c141b2318acbe0f58970ccf109cc10107b29eec27acf4f96b082318
[2] 87f4a2b6edeffd2a93759f93b45af5ad8eb9325b209ff457f8c3916520f96c47
[3] 0cff1c96cd98bb438e68e9d68f5eca14509b395b303ef47b157fc37b2a8a981e
[4] e300197ab7cdf7d8062e8c0decff58c7b1d985dab6c568195178e2d94d827221
[5] da2b72d929bc92af654f8732216b4f0ff3557de00850ac5fa142a6794f61a24e
[6] 11615e2c81f6fecacd06a8bee867882a830e60956b89cc6942c0a16efeb87b4e
[7] 97509fa15da2b5b5fb0e7f4ef1945272528923b92ac94c119df43e41bb3ed444