# bridge exploit — X 热门讨论 (2026-09-30 12:02 UTC)
## @kandleott (NFA and DYOR ofc) · 09-30 08:39 · ♥24 ↻6 💬1 $EGLD exploit was real but MultiversX was SAFE all the time since in practice this particular attack couldnt succeed against the live bridge Later upgrade v2.1.7.0 completely closed the vulnerability so this kind of attack cant work at all anymore regardless of whats in the cache > 引用 @SasuRobert: The attacker account erd1naytrk5945udc956nw84kjjkeht7hldr6rx375qjljwv98pqv2uqfdl45l attempted a Wasmer compiled-code cache poisoning exploit targeting the official MultiversX xBridge (Ad-Astra) Ethereum Safe contract.
The attacker tried to exploit a known VM vulnerability ("Stale code hash after same-transaction upgrade runs wrong code and poisons compiled/warm caches").
The goal was to force validator nodes to associate the codeHash of the legitimate Bridge Safe with an attacker-modified backdoored WASM binary containing drain functions (bridgeOut, drain). If successful, subsequent legitimate calls to the official bridge contract would execute the backdoored code, allowing the attacker to drain the bridge's vault.
After the upgrade: Cache poisoning is impossible: An upgraded contract within the same transaction is compiled and cached strictly under its own hash (HMHM). Victim contracts are safe: The legitimate contract's code hash HH (xBridge: Ethereum Safe) cannot be overwritten or aliased in the warm or compiled code cache. Execution integrity restored: Subsequent calls to the upgraded contract will execute the upgraded bytecode under HMHM, without polluting or reading from HH.
Before the upgrade: In sync, after invoking upgradeContract on child contract B, the contract immediately called ping on child contract B via executeOnDestContext. When the node's VM runtime dispatched the subsequent call on B, it resolved the Wasmer instance. Because the Bridge Safe code is an active, heavily executed mainnet contract, its codeHash H was already resident in the node's warm LRU / compiled-code store. Instead of compiling the newly supplied bytecode M, the node reused the existing compiled instance of the legitimate Bridge Safe code. Because the legitimate Bridge Safe code does not export ping, the VM halted with invalid function (not found) [ping]. The attacker tried 38 times with the first contract (using a minimal WASM stub) and 4 times with the second contract (using the full 28KB bridge WASM), but every attempt hit the same cache behavior and reverted before reaching collect.
This is the unhinged reality. https://x.com/kandleott/status/2105216049842979211