Most Aleph Zero Bridge — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Most Aleph Zero Bridge, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 3
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 3 closed, publicly disclosed Most Aleph Zero Bridge reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Bridge exploit, Integer overflow / underflow, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Most Aleph Zero Bridge
- Bridge exploit findings disclosed against Most Aleph Zero Bridge
- Integer overflow / underflow findings disclosed against Most Aleph Zero Bridge
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Most Aleph Zero Bridge: Changing committee to a higher signature threshold will render a request from the previous committee un-processable
In the Most Aleph Zero bridge's ink! (Rust) implementation, receive_request validates an incoming bridge request against the signature threshold stored for the current committee rather than the threshold of the committee_id the request was actually created under. Since the function looks up signature_thresholds using the live committee state while the request itself carries its original committee_id, any committee rotation that raises the signature threshold makes pending requests from the older, lower-threshold committee unprocessable. The signatures of the original members no longer satisfy the new threshold, so the request can never complete and the funds bundled with it remain stuck unless an identical committee is recreated. The reporter provides an ink_e2e PoC proving the final signature emits RequestSigned but never RequestProcessed, and notes the Solidity (EVM) counterpart already implements the correct committee_id-keyed lookup, confining the bug to the Aleph Zero side.
Most Aleph Zero Bridge: Inconsistency in Handling WETH in `eth::most::receiveRequest`
The Most/Aleph Zero bridge's receiveRequest distinguishes native ETH from ERC-20 tokens by comparing the destination token address to the configured WETH address, unwrapping WETH to native ETH whenever it matches. Because bridge-ins via sendRequest never re-wrap, this makes the send/receive path asymmetric: a contract that sends WETH to the bridge intending to retrieve WETH instead receives native ETH on the way back. Receivers that only accept WETH revert on the native transfer, the EthTransferFailed event fires, and the funds become recoverable only through owner intervention. The report ships a working Foundry PoC and proposes replacing the WETH sentinel with a dedicated ETH flag.
Most Aleph Zero Bridge: Most will not work with tokens with high decimals due to overflow
The Most EVM-to-Aleph Zero bridge holds a type-mismatch between its two sides: sendRequest computes transfer amounts as uint256 on the EVM side, while the AZ PSP22 wrapper stores total supply and balances as u128. Bridging an amount above the u128 ceiling causes an integer overflow during mint on Aleph Zero, resetting the user's wrapped balance to zero while the source tokens remain locked, producing a permanent loss. The scenario is most plausible for high-decimal tokens where raw amounts readily exceed u128. The recommended fix is to align the numeric type across both chains.