Cowrie Research

alephium-bridge-fake-log7-event-forged-guardian-vaa-drain-2026-05-30

15 min read

Alephium Bridge Fake LOG7 Event / Forged Guardian VAA Drain (2026-05-30)

  • Name: Alephium Bridge fake LOG7 event / forged guardian VAA drain
  • Date: 2026-05-30
  • Protocol: Alephium Bridge / Wormhole fork
  • Chain: Alephium + Ethereum + BNB Chain
  • Category: bridge verification failure / forged guardian-message acceptance / offchain observation-path compromise / fallback validation abuse / unbacked wrapped-asset mint
  • Loss: roughly $305K of backed collateral was drained from Ethereum- and BNB-side bridge custody, while 13,757,076.37 wALPH was minted without backing; Alephium later noted that the oft-cited $815K headline counted the counterfeit wALPH at pre-crash prices rather than only the actually realized backing loss
  • Summary: Alephium’s bridge was a Wormhole-derived lock-and-mint system whose four-guardian network watched core-contract logs and produced signed VAAs. On 2026-05-30, the attacker first acquired native ALPH, deployed an Alephium contract whose only purpose was to execute LOG7 and emit a forged bridge message, then disrupted bridge-node connectivity so the guardian backend fell onto a weaker fallback validation path. Public on-chain reporting says legitimate guardians then signed VAAs over the fabricated message stream without realizing the event came from the fake contract rather than from the real bridge flow. Those forged-but-validly signed VAAs were redeemed on Ethereum and BNB Chain, draining real USDT, USDC, WBTC, WETH, and WBNB from bridge custody and minting unbacked wALPH on Ethereum.
  • Trigger / entry point:
    • Alephium’s bridge architecture was explicitly a Wormhole fork with a small guardian network watching chain-specific transaction logs and issuing VAAs once a quorum agreed.
    • The attacker needed native ALPH on Alephium to deploy a fake-event contract, so they first bought 485.19 wALPH on Ethereum, bridged it to Alephium, and received 485.19 ALPH on the Alephium side.
    • At 06:30:47 UTC, they deployed a contract at 24ZjqcvV8vVCn29zd1TThqAtaS8pMvJ4Co1MK5zncPcAB whose only publicized role was to execute LOG7 and emit forged Wormhole-style message data.
    • Alephium’s on-chain report says the attacker then disrupted bridge-node connectivity between 07:00 and 09:00 UTC, forcing the backend onto a fallback validation path before the actual drain began.
  • Root cause:
    • The bridge’s authenticity boundary did not fail because guardian private keys were stolen. It failed because legitimate guardians were induced to sign false bridge messages.
    • Public materials available at review time stop short of a full technical postmortem, but the team stated that forged data from the fake LOG7 contract reached the bridge’s legitimate guardians after backend connectivity disruption forced use of a fallback validation path.
    • In other words, Alephium’s bridge could no longer reliably distinguish message emitted by the real core bridge contracts from message emitted by attacker-controlled code that looked acceptable to the offchain guardian stack.
    • Once the guardians produced valid signatures over that false message body, the downstream token-bridge contracts on Ethereum and BNB Chain behaved exactly as designed and released custody / minted wrapped assets against fiction.
  • Exploit path:
    1. The attacker bought 485.19 wALPH on Ethereum in transaction 0xdebbeddc6958e25f8eda1d0d22360fa3818cc0a36cc770efe19fd62eab98a2c0, approved the bridge, and bridged the full amount to Alephium in transaction 0xb44c2d786cb47c53e034ec8dbb7b26ed74fb7c46996e4dd7d17bfa1e8ec70a5d.
    2. Alephium minted 485.19 ALPH to the attacker’s receiving wallet, giving them native gas and deployment capital on Alephium.
    3. The attacker consolidated that ALPH into deployer wallet 14etamDofb3XmupQyuFQN6c1szQYAduqxjzPq4YjwnPPv and deployed the fake-event contract in Alephium transaction d89bbcd333de6f7fec4efeb618d9e144d5529f3405a0e5b8b9f7d0a6eaab239e.
    4. According to Alephium’s on-chain report, the attacker then degraded bridge-node connectivity so the guardian backend relied on a fallback validation path.
    5. The fake contract emitted forged Wormhole-style message data via LOG7, and the legitimate guardian process signed the resulting VAAs without recognizing that the underlying event was fabricated.
    6. Starting at 09:16:59 UTC, those forged VAAs were redeemed against real bridge custody on Ethereum: 200,967.31 USDT (0x928e369e6e857c93f237356b201c97ddac31ba777e2a942928272f962c02bc40), 0.33531483 WBTC (0x293c3062a133b089bc31eba910daeb6b2d508ad26e045e439b1339793f51237e), 17,594.63 USDC (0x8a719311d4304ea3d1c1235eece0cf9591c2a43864ce8aa70e9ea9443aff6c37), 5.18192421 WETH (0xb5b3f089a745394d736615e9a11ea40a1ad020678e466a6f95b3a9f4d321a98f), and 13,757,076.37 wALPH minted (0x06cc0f36159d7094359d88fe1d43cda601e8644282ba305c5ffbd013b524c6b4).
    7. Three seconds later, equivalent forged redemptions on BNB Chain drained 36,750.106 USDT (0xa3e8572fe524b28bce9765fcbd0b737cd6289c692970b5a1a1289b6edf95d06f) and 24.38620961 WBNB (0xe38e870a3aceb8e1189d21e0734170a69fe9bfd7355d0ccb4209588ab77f0b1e).
    8. The attacker swapped the backed assets into WETH / BNB, bridged BNB-side proceeds to Ethereum through deBridge, dumped a portion of the counterfeit wALPH into Uniswap liquidity, parked another large portion in a secondary EOA, consolidated ETH, and sent 50 ETH through Tornado Cash.
  • What the attacker needed to be true:
    • The guardian network had to accept offchain observation data that could be confused by a fake Alephium-side event source once the backend entered fallback mode.
    • The bridge had to trust signed VAAs from that guardian stack as sufficient proof for Ethereum- and BNB-side release / mint operations.
    • Bridge custody on Ethereum and BNB Chain had to contain enough real assets to satisfy the forged messages.
    • The attacker needed enough native ALPH to deploy and operate the fake-event contract on Alephium before the guardian pipeline was exploited.
  • Technical anatomy worth remembering:
    • This was a forged-message bridge failure, but not the classic stolen validator key version. The guardians were apparently genuine; the message they authenticated was not.
    • The bridge’s public architecture emphasized that guardians watched transaction logs from the core contracts and then derived a one-to-one VAA body from those messages. The exploit matters because it broke that assumption at the observation layer before the signature set was ever assembled.
    • Alephium’s own report explicitly separates the two phases that mattered: first the fake LOG7 contract that produced forged message material, then the forced fallback validation path that let the backend treat that material as signable bridge truth.
    • This makes Alephium a useful cousin to Wormhole. Wormhole’s 2022 exploit forged the verifier result inside an onchain Solana program; Alephium’s 2026 exploit appears to have forged the message earlier, inside the offchain guardian-observation and validation pipeline.
    • The response also shows the governance power embedded in bridge operators: after the exploit, guardians used the bridge’s upgrade(bytes encodedVM) path to burn most of the unbacked wALPH still held by attacker wallets.

Three bridge-truth promotions this incident collapsed

  1. A bridge-shaped message artifact existed at all
    • The attacker could make Alephium emit Wormhole-looking message material via a fake contract whose only publicized purpose was to execute LOG7 and feed payload data into the guardian pipeline.
    • At this stage the strongest true fact was only some bridge-looking payload exists and can be parsed, not the canonical Alephium bridge core emitted a real cross-chain message.
  2. That artifact was promoted into canonical guardian-authenticated bridge truth
    • This was the decisive collapse. Alephium’s own bridge explainer said guardians watched the core contracts and derived a one-to-one VAA body from those core-contract messages, but the exploit report says backend connectivity disruption forced the system onto a fallback validation path that still let the fake-contract LOG7 output become signable.
    • The bridge therefore confused a guardian-observable Wormhole-shaped event exists with the canonical bridge emitter really authored this exact message, so legitimate guardian signatures were minted over attacker-authored fiction.
  3. That accepted truth still deserved immediate custody-release and mint authority
    • Once the forged VAAs were signed, Ethereum and BNB token-bridge contracts treated them as ordinary bridge truth and immediately released real USDT, USDC, WBTC, WETH, and WBNB while also minting 13,757,076.37 wALPH.
    • The route preserved very little separation between one observation-path failure produced one accepted VAA and multi-asset custody plus large wrapped-asset mint authority can now move, which is why the exploit could drain backed collateral and print counterfeit inventory in roughly one minute.

The practical review habit is the one this incident punishes: do not stop at the guardians signed. First ask whether the bridge confused a bridge-looking artifact exists with the core route emitted canonical bridge truth, then ask whether even that accepted truth should have carried full-size release and mint authority under degraded-mode conditions.

  • Representative transactions and contracts:
    • Ethereum TokenBridge (drained): 0x579a3bDE631c3d8068CbFE3dc45B0F14EC18dD43
    • BNB Chain TokenBridge (drained): 0x2971F580C34d3D584e0342741c6a622f69424dD8
    • Ethereum wALPH token: 0x590f820444fa3638e022776752c5eef34e2f89a6
    • Alephium bridge custody contract: 226T1XspViny5o6Ce1jQR6UCGrDXuq5NBVoCFNufMEWBZ
    • Attacker EOA on Ethereum + BNB Chain: 0x6681ebC82551fE52fDB48E65872e85a3ae06921d
    • Attacker consolidation EOA: 0xb80a7d612480d121696be6dfe062f5e6d984bfd4
    • Attacker wALPH parking EOA: 0x0baD8f95a996DeADe828d21DAd765b60c2b2509c
    • Attacker fake-event contract on Alephium: 24ZjqcvV8vVCn29zd1TThqAtaS8pMvJ4Co1MK5zncPcAB
    • Fake-contract deployment transaction on Alephium: d89bbcd333de6f7fec4efeb618d9e144d5529f3405a0e5b8b9f7d0a6eaab239e
    • Recovery / burn transaction for unbacked wALPH: 0xade2846a20169aa23d53203e1c3c509474694710a9f4674307c220528d27a4b1
  • Response / mitigation:
    • Alephium shut the bridge down immediately after the drain and publicly framed the exploit as an offchain bridge vulnerability rather than an Alephium L1 consensus failure.
    • The team published a detailed on-chain movement report, including attacker addresses, exact drain transactions, and downstream cashout paths, while promising a fuller technical postmortem later.
    • On 2026-06-02, bridge guardians used the bridge’s upgrade(bytes encodedVM) governance path to invalidate attacker-held unbacked wALPH, burning 13,257,077.37 wALPH — about 96.4% of the counterfeit amount.
    • About 500,000 wALPH had already escaped through Uniswap liquidity before the bridge pause and burn response landed.
  • Comparable exploit pattern:

Pattern tags

  • bridge-verification-failure
  • message-source-authentication-failure
  • degraded-mode-authenticity-failure
  • A Wormhole-style guardian signature set stayed cryptographically genuine while the signed message became fake earlier in the observation pipeline, so guardian signed no longer implied core bridge emitted this
  • The fake LOG7 contract and the forced fallback path were one joined failure, not two independent curiosities: the forged event only became bridge-truth material because outage handling widened who or what could author guardian-signable messages
  • One forged Alephium-side message stream still had immediate line-of-sight to multi-asset custody on Ethereum and BNB plus large counterfeit wALPH mint authority, so observation-layer failure and blast-radius failure compounded each other

Why the exploit worked

  • Alephium’s bridge trust story still collapsed onto one question: what exact Alephium-side artifact may guardians sign as bridge truth? The attacker answered that question with a fake LOG7 contract before the bridge answered it with a fail-closed source-authentication rule.
  • Public reporting says the attacker first created forged Wormhole-style message material on Alephium and then degraded bridge-node connectivity so the backend entered a weaker fallback validation mode. That matters because the exploit did not need guardian-key theft; it only needed the fallback path to treat attacker-authored data as signable.
  • The guardian signatures were therefore honest signatures over a dishonest message. Once that happened, Ethereum and BNB token-bridge contracts behaved as designed because the bridge had no second independent authenticity lane or source-side custody check after VAA acceptance.
  • Public bridge docs and launch materials emphasized the normal flow as guardians watching core-contract logs and deriving one VAA from those messages. The exploit worked because the production observation stack could be made to confuse bridge-core event with bridge-looking event from attacker code under failure pressure.
  • Blast radius stayed large because one forged guardian-authenticated message could immediately drain several real custody assets and mint large counterfeit wALPH before route-local throttles, destination quarantine, or narrower per-asset brakes cut the path down.

Detection and audit pivots

  • Reconstruct the exact bridge-message authoring surface: which Alephium contracts, event opcodes, topics, emitters, and execution contexts are actually allowed to become guardian-observed message truth, and what explicitly rejects every other speaker?
  • Ask the degraded-mode question directly: when bridge nodes lose connectivity or the preferred validation path fails, does the route halt, or does fallback silently weaken emitter authentication, event-source checks, or observation provenance?
  • Audit whether guardians, relayers, and dashboards are observing the same security object. If one path can be shown a bridge-looking log stream that another path never canonically ties back to the core bridge contract, external monitoring may overstate safety.
  • Test bridge forks and custom chain integrations for Wormhole-shaped but chain-specific observation bugs. A correct downstream VAA parser does not help if the upstream emitter filter, log parser, or fallback validator can be widened by local chain quirks or outage handling.
  • Review post-authenticity blast radius beside source authentication. If one forged VAA can still unlock multiple destination assets or large wrapped-token mints in one window, the bridge needs tighter per-route caps, staged release, or faster counterfeit-asset quarantine.

Failure-prevention checklist

  • Keep the guardian-authored message surface mechanically narrow: one canonical Alephium core-contract emitter set, one canonical message-publication path, and one explicit proof that the observed log came from that path rather than from arbitrary contracts able to execute LOG7.
  • Make primary and fallback validation prove the same authenticity object. If degraded mode cannot still show real bridge core emitted this exact message, the route should halt instead of widening who may author guardian-signable truth.
  • Have guardians or the backend derive signable VAA bodies only from artifacts that already carry canonical source-contract identity, canonical emitter address, and the expected state-transition context, not merely from bridge-looking payload shape.
  • Treat offchain observation, RPC selection, and node-connectivity failover as bridge-security code subject to the same review bar as onchain verifier changes.
  • Add route-local bounded-release controls so one forged guardian-approved message cannot immediately drain several destination assets and mint large counterfeit inventory before operators respond.
  • Separate counterfeit wrapped-asset containment from healthy-route redemption so emergency burns, freezes, or deny-lists can quarantine forged inventory faster without needing a full cross-route shutdown.
  • Continuously inventory which contracts, topics, log opcodes, and parser branches can ever become guardian-observed bridge truth, and regression-test that non-core contracts cannot manufacture signable message bodies.

Audit prompts

  • What exact Alephium-side contracts and execution contexts are allowed to author a guardian-signable message, and where is that allowlist enforced in the live observation pipeline?
  • Can any attacker-controlled contract emit a bridge-looking LOG7 payload that the guardian stack would still parse into a VAA body if connectivity is degraded or one backend component is unavailable?
  • Does fallback validation prove the same core contract -> canonical message -> one-to-one VAA body relation that Alephium’s own bridge documentation describes for the happy path, or does failover silently weaken source-authentication guarantees?
  • Are guardians checking only that a log matches Wormhole-style structure, or also that the emitter address, source contract, and call-path provenance match the canonical bridge-core path?
  • If one forged message is signed, what per-route or per-asset controls stop immediate multi-asset custody release on Ethereum and BNB before operators can intervene?
  • Which backend dependencies can currently redefine bridge truth under outage pressure: RPC providers, indexers, message parsers, guardian APIs, manual replay tools, or alternate observation nodes?
  • Could a recovery or upgrade path such as upgrade(bytes encodedVM) safely quarantine counterfeit wrapped inventory without also giving operators a dangerously broad residual authority surface in normal times?

Lessons that should already be standard

  • Legitimate guardian signatures are not the same thing as legitimate bridge truth. If the observation path can be tricked, honest multisig only certifies the wrong story faster.
  • A bridge’s source-authentication boundary includes the offchain watcher stack, parser logic, and failover rules, not just the destination-chain verifier contract.
  • If project docs say guardians watch the core contracts and derive a one-to-one VAA body from those messages, then degraded mode must preserve that exact property or fail closed.
  • Event shape is not provenance. A bridge-looking LOG7 payload emitted by attacker code is still counterfeit even if every downstream parser can decode it cleanly.
  • Fallback validation is verifier code. Under stress is exactly when the bridge must be least willing to broaden who may author a redeemable message.
  • Bounded release matters even after authentication fails. One forged message should not still have straight-line access to several real custody assets plus large wrapped-token mint authority.
  • Post-incident emergency powers can reduce losses, but they also prove how much authority the bridge retained all along; those rails need the same scrutiny as the signing path they are rescuing.

Why this incident matters

  • It preserves a bridge-verification failure mode that sits between classic smart-contract verifier bugs and classic signer-key compromise: the signatures were real, but the guardian backend was tricked into signing a fake event stream.
  • It also sharpens an uncomfortable operational lesson: once bridges depend on offchain watcher stacks, failover logic, and message-source filtering, those components are custody code whether or not they live onchain.
  • Finally, Alephium is a useful post-Wormhole comparison case because it shows that Wormhole-style guardian signatures remain a live attack surface even when the failure is no longer the onchain signature parser itself.
  • It also preserves the separate bounded-release lesson: once one forged guardian-truth event was accepted, the route still had immediate line-of-sight to meaningful Ethereum and BNB custody plus large unbacked wALPH mint authority instead of first hitting tighter lane-local release caps, destination-side throttles, or a narrower fake-asset quarantine boundary.

Internal linkages

Control surface

Graph View

Backlinks