Aleo — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Aleo, 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 Aleo 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, across EVM-Solidity, Other. 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 Aleo
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Aleo: Aleo prover/network DOS vector due to invalid `split` proofs being free to abuse
Aleo's snarkVM contains a fee-commitment gap for single-transition split transactions. For deploy and execute transactions, an accompanying fee transaction is consumed when the proof is invalid or finalization fails, which burdens invalid submissions with collateral. A lone split transaction instead burns its fee inside the split function, so when the proof turns out to be invalid there is no separate fee commitment to forfeit. An attacker can therefore mint many private records holding at least one microcredit each, reuse them across blocks, and broadcast split transactions whose invalid proofs pass the fast prechecks yet consume prover CPU during proof verification. Competing provers or a coordinated attacker can exploit this to degrade or halt block production on the Aleo network at near-zero cost.
Aleo: `delegated[]` state is not removed after it reaches zero, potentially leading to higher computational costs and DoS
On the Aleo layer-1 finalize program, the `delegated[]` mapping holds credits delegated to validators, but the `remove_validator` path writes a zero value back to a key instead of deleting it, leaving entries permanently in storage. Because staking-reward computation iterates this whole mapping on essentially every network transaction, an actor who repeatedly bonds and unbonds to arbitrary (even non-existent) addresses can seed unbounded, unremovable entries for only the cost of gas and reclaimable credits. This steadily inflates storage and per-transaction compute, slowing transactions and raising fees, with the demonstrated potential to reach a permanent network-wide DoS since no code path clears the saturated mapping. The judge upheld the finding as a unique Medium.
Aleo: `unbond_public` logic causes issues for some delegators preventing partial withdrawals
Aleo's credits program contains a logic error in `unbond_public` where the condition that detects a validator force-unbonding a delegator (caller equals the staker's withdrawal address) becomes true whenever a delegator shares its withdrawal address with the validator it is bonded to. As a result, a partial unbond request of even a single microcredit is treated as a forced full unbond, sending both the delegator's and validator's entire bonds into the 360-block unbonding period. The sponsor confirmed this self-delegation configuration is a legitimate validator operation, and the fix is to distinguish delegator-initiated partial withdrawals from forced validator unbonds using the r7 caller condition.