Kleidi — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Kleidi, 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 Kleidi 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. 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 Kleidi
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Kleidi: Wrong handling of call data check indices, forcing it sometimes to revert
Kleidi's whitelisted-calldata mechanism lets cold signers define byte-indexed slices that hot signers can submit without a timelock. Two code paths — BytesHelper.sliceBytes and Timelock._addCalldataCheck — derive a slice length as endIndex minus startIndex rather than adding one, an off-by-one that only surfaces when a checked parameter fills its full encoded width, such as a uint256 equal to type(uint256).max. The PoC whitelisting an infinite ERC20 approval forces the end index one byte past the 68-byte data string, so executeWhitelisted always reverts and the legitimate whitelisted call is bricked. The sponsor confirmed the finding as a valid medium and resolved it together with the related index-handling duplicates in PR #54.
Kleidi: `UpdateExpirattionPeriod()` cannot be executed when the `newExpirationPeriod` is less than `currentExpirationPeriod`
Kleidi's Safe timelock has a redundant readiness check in `_afterCall()` that runs at the end of every `execute()`. When the Safe schedules a proposal to lower `expirationPeriod`, `isOperationReady()` evaluates readiness using the newly-set shorter expiration instead of the period that was in effect when the operation became executable. If the operator executes the change after the new shorter window has lapsed but before the original longer window, the call reverts with "operation is not ready" even though the update is legally due. The sponsor and judge confirmed the mechanism, and the finding was finalized as Medium after initially being debated as QA. Crucially, this is a self-inflicted/operator-timing condition, not an external attacker exploit.
Kleidi: Gas griefing/attack via creating the proposals
Kleidi's timelock stores every scheduled proposal as a distinct operation that must be individually cancelled or executed, and both defensive paths — the pause guardian calling pause() or cold signers iterating cancel() — cost gas that scales linearly with the number of queued proposals and must be paid from victim accounts that cannot draw on vault funds. If an attacker obtains threshold-quorum keys of the gnosis safe, they can flood the timelock with schedule() calls that share a payload but differ only in salt, each receiving a unique operation ID, forcing a gas war that victims are heavily disadvantaged in. The judge reproduced the economics with a Foundry PoC consuming 30 million gas in scheduling, measured the defense as roughly 7x to 22x more expensive per gas depending on execution mode, and (also weighing real signature generation, nonce increments and base transaction costs) ruled the finding valid at Medium severity. The agreed mitigation is an epoch mechanism that advances on pause and is embedded in operation hashes, letting all pre-pause proposals be bulk-invalidated in O(1).