Chakra — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Chakra, 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 Chakra 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 Signature replay, Access control, Bridge exploit, 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
- Signature replay findings disclosed against Chakra
- Access control findings disclosed against Chakra
- Bridge exploit findings disclosed against Chakra
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Chakra: `ChakraSettlement.receive_cross_chain_msg` and `ChakraSettlement.receive_cross_chain_callback` functions do not ensure that receiving `ChakraSettlement` contract's `contract_chain_name` must match `to_chain` corresponding to respective `txi…
Chakra's cross-chain settlement functions sign and verify messages that do not bind the signed payload to the receiving chain's identity. Because validators and handlers can be deterministically deployed to the same address on multiple chains and can share identical whitelist configurations, a message and its validator signatures intended for one destination chain can be replayed on another. An attacker can therefore trigger `receive_cross_chain_msg` or `receive_cross_chain_callback` on the wrong chain, producing incorrect token mints, unlocks, or burns. The impact is incorrect token accounting across chains, which the judge escalated to high severity as a replay vulnerability on received funds.
Chakra: There is no refund mechanism in `ChakraSettlement.processCrossChainCallback` or `ChakraSettlementHandler.receive_cross_chain_callback` function
ChakraSettlementHandler's cross-chain ERC20 settlement can strand user funds because there is no refund path when a settlement fails. If the source chain's handler is removed from the destination chain's whitelist after a message is initiated, the destination-side receive handler rejects the message and the cross-chain callback only marks the transaction Failed — it never returns the caller's locked or burned tokens. The judge confirmed the missing refund mechanism as a high-severity design flaw affecting a large class of related duplicates.
Chakra: The `LockMint` and `BurnUnlock` modes cannot be used
Chakra's cross-chain settlement handler implements LockMint and BurnUnlock modes with inverted receive-side logic. Since a single handler that processes both outgoing and incoming cross-chain messages uses one mode setting, the mapping between source-chain lock/burn and destination-chain mint/unlock is broken: LockMint should unlock on the receiving side but instead mints, and BurnUnlock should mint but instead unlocks. This makes those two configurations permanently non-functional on both the Solidity and Cairo implementations. A confirmed high-severity design flaw acknowledged by the sponsor and judge.