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
- 23
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 23 closed, publicly disclosed Chakra reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Bridge exploit, Logic error, Front-running / MEV, Signature replay, Access control, across EVM-Solidity, Other, Move. 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
- Bridge exploit findings disclosed against Chakra
- Logic error findings disclosed against Chakra
- Front-running / MEV findings disclosed against Chakra
- Signature replay findings disclosed against Chakra
- Access control 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: Invalid token address used in `ChakraSettlementHandler::cross_chain_erc20_settlement(...)` leading to invalid transaction creation and event emission
In Chakra's Solidity settlement handler, the cross_chain_erc20_settlement function records the handler's own contract address (address(this)) as the from_token field both when storing the CreatedCrossChainTx record and when emitting the CrossChainLocked event, instead of using the actual token address. Because the bridge's validators and counterparty contracts consume these emitted events to drive state-changing cross-chain operations, the wrong from_token value corrupts the transaction ledger and event stream. The Cairo reference implementation confirms the intended behavior is to pass the token address, and the sponsor confirmed the bug via a duplicate report with the judge elevating severity to High.
Chakra: SettlementSignatureVerifier's `required_validators` is not updated, resulting in a low or high number of signatures being required
Chakra's BaseSettlement contract exposes an admin function to change the number of required validator signatures for cross-chain settlement. However, set_required_validators_num only updates a local storage variable and emits an event; it never forwards the new threshold to the SettlementSignatureVerifier contract that actually enforces multi-signature validation. As a consequence, any attempt by the manager role to tighten or loosen the signature threshold has no effect on real verification, so the system silently keeps enforcing the previous count. The judge confirmed the missing functionality (medium severity) since no direct attack path was demonstrated, only a divergence between contract-level state and the verifier's enforced threshold.
Chakra: Inconsistent Handler Validation Behavior in Cairo ERC20Handler's Cross-Chain Callback
Chakra's cross-chain bridge ships two implementations of ERC20Handler's receive_cross_chain_callback: a Solidity version that returns a boolean false for unwhitelisted handlers and a Cairo/Starknet version that enforces handler validity with assert statements, which revert the whole call. Because a Cairo revert aborts execution instead of returning false, the settlement logic that would transition a cross-chain message to a terminal Failed state never runs, leaving it stuck in Pending indefinitely. This makes affected cross-chain operations unrecoverable and diverges transaction state between the Starknet and EVM chains for the same message. The report was confirmed by the team and elevated to High by the Code4rena judge.
Chakra: Malicious actors can manipulate the `cross_chain_callback` callback
Chakra's cross-chain settlement contract signed the final callback message hash without the `from_chain` field, even though that field is used downstream to authorize the receiving handler. An attacker who observes a legitimate validator callback in the mempool can front-run it with the same valid signatures but a fabricated `from_chain`, passing signature verification while causing the `is_valid_handler` check to fail. That false return permanently sets the transaction's status to `Failed`, blocking the real callback from ever executing. The judge upheld the finding as high severity because any transaction's final leg can be trivially sabotaged in this way, despite the protocol maintainer disputing the impact on the basis of txid uniqueness.
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: Forcing Starknet handlers to be whitelisted on the same chain allows exploit of `BurnUnlock` mode to drain handler funds
Chakra's Starknet handler validates cross-chain messages by requiring in receive_cross_chain_msg and receive_cross_chain_callback that both the source handler and the destination handler are registered in support_handler. Because a Starknet handler must register itself as its own supported destination, an attacker can direct settlement messages from Starknet back to Starknet and satisfy both checks. In BurnUnlock mode the receiving side unlocks tokens via token.transfer out of the handler's own balance, so the attacker can loop self-messages to repeatedly unlock tokens into their own address, draining the handler's ERC20 balance and starving legitimate cross-chain operations. The judge first invalidated the finding, then after the warden clarified the self-whitelisting constraint reinstated it as high under the audit's face-value node-processing assumption.
All reports in this group
- Chakra: The `receive_cross_chain_msg` function has potential replay attack risksSignature replay$0
- Chakra: The `LockMint` and `BurnUnlock` modes cannot be usedBridge exploit$0
- Chakra: Does not check if `to_chain` and `to_handler` is whitelisted in `cross_chain_erc20_settlement`Bridge exploit$0
- Chakra: In Starknet, already processed messages can be re-submitted and by anyoneBridge exploit$0
- Chakra: `SettlementSignatureVerifier` is missing check for duplicate validator signaturesLogic error$0
- Chakra: Anyone can manipulate user nonce (`nonce_manager`) in settlement contractAccess control$0
- Chakra: Permanent loss of user tokens on both chains if `BurnUnlock` mode fails because of flawed burning patternBridge exploit$0
- Chakra: Excessive Authority Granted to Managers in the `ckr_btc.cairo` Contract Presents Significant Management RisksAccess control$0
- Chakra: Wrong usage of transaction originator address instead of caller addressBridge exploit$0
- Chakra: There is no refund mechanism in `ChakraSettlement.processCrossChainCallback` or `ChakraSettlementHandler.receive_cross_chain_callback` functionAccess control$0
- Chakra: Missing `ERC20Method` validation at destination allows non-transfer tx to be handled as transfersLogic error$0
- Chakra: Inconsistency in sender address when creating cross chain messages on Starknet can lead to loss of fundsBridge exploit$0
- Chakra: In `settlement.cairo::receive_cross_chain_msg` - the message will always be marked with `Status::SUCCESS`Logic error$0
- Chakra: Handler's `receive_cross_chain_callback()` will always set the `tx_status` to `SETTLED` on source chain & burn the tokens (MintBurn Mode) even when the msg fails on destinationBridge exploit$0
- Chakra: Bridging from Starknet to Starknet causes mismatch between minted ckrBTC and BTC transferred to MuSig2Bridge exploit$0
- Chakra: In `settlement.cairo::receive_cross_chain_msg` - the `payload_type` can be passed by the user, confusing offchain systemsBridge exploit$0
- Chakra: A cross-chain message can be initiated with invalid parametersBridge exploit$0