Karak — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Karak, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 8
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 8 closed, publicly disclosed Karak 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 Logic error, Integer overflow / underflow, 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 Karak
- Integer overflow / underflow findings disclosed against Karak
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Karak: Slashings will always fail in some cases
Karak's slashing flow lets a DSS queue a slash request that remains pending through a two-day veto window before it can be finalized. Because a vault's balance can drop to zero during that window — whether from completed withdrawals or from a prior slash by another DSS — the min() logic in Vault.slashAssets computes a zero transferAmount. SlashingHandler.handleSlashing reverts on zero amounts, so finalizeSlashing reverts for the entire request, blocking slashes against all other vaults in the same request. The finding was confirmed and mitigated by guarding the handleSlashing call so a zero transferAmount is skipped rather than reverting.
Karak: Changing the `slashingHandler` for `NativeVaults` will DoS slashing
Karak's Core maintains a whitelist mapping of assets to authorized slashingHandlers, but each deployed NativeVault independently stores its own slashStore reference at deployment time and its slashAssets function rejects any caller whose handler differs from that stored value. If the protocol ever updates the slashing handler for a whitelisted asset after NativeVaults have been deployed, every previously deployed vault permanently reverts on slash attempts. Restoring the old handler only shifts the DoS onto vaults deployed under the new handler, leaving a per-vault implementation upgrade as the only clean fix. The sponsor confirmed the finding, and the impact is that slashing as the protocol's punitive mechanism becomes unavailable for a whole class of vaults.
Karak: When malicious behavior occurs and DSS requests slashing against vault during 2 day period after `SLASHING_WINDOW` of 7 days is passed after staker initiates a withdrawal, token amount to be slashed is calculated to be higher than what it s…
A Karak slashing-accounting flaw lets a DSS over-slash a vault because the earmarked stake is computed from the vault's live totalAssets(), which still includes underlying tokens backing a staker withdrawal that has already passed the 7-day SLASHING_WINDOW and should no longer be slashable. Requesting slashing during the 2-day gap between the 7-day slashing window and the 9-day MIN_WITHDRAW_DELAY therefore lets the DSS seize a larger effective share of the remaining balance, and a miner ordering race can cause even a nominally safe withdrawal to be slashed. The judge upheld the core calculation flaw as Medium while treating the miner-ordering scenario as user responsibility, and the protocol mitigated by computing earmarkedStakes at finalizeSlashing time.
Karak: The operator can create a `NativeVault` that can be silently unslashable
In Karak's native restaking module, `Core.deployVaults()` reads the `slashStore` address directly from the operator-supplied `extraData` without any validation. `NativeVault.slashAssets()` hard-reverts with `NotSlashStore` whenever the whitelisted ETH slashing handler passed during a slash does not equal the stored `slashStore`. An operator can therefore deploy a `NativeVault` with an arbitrary `slashStore` and permanently disable slashing on their own vault. Since slashing is the protocol's core mechanism for penalizing misbehavior, this lets a malicious operator act with no financial downside. The judge confirmed high severity, rejecting the sponsor's medium downgrade, and Karak's subsequent mitigation (removing SlashStore and burning in-vault) was found unmitigated in the follow-up review.
Karak: A snapshot may face a permanent DoS if both a slashing event occurs in the `NativeVault` and the staker's validator is penalized
Karak's NativeVault burns a node owner's shares during snapshot validation using the shares converted from the full validator asset balance, even when a prior Karak slashing already reduced that owner's share holdings. If a subsequent beacon-chain slashing pushes the combined loss above the owner's entire restaked balance, _decreaseBalance() computes a burn amount that exceeds the shares the owner still holds, so _burn() reverts. That revert permanently freezes both validateSnapshotProofs() and validateExpiredSnapshot() for the user, allowing a deliberately misbehaving validator to keep accruing restaking rewards after its stake is gone. Karak confirmed the finding, mitigated it by accounting for the decreased share balance before burning, and the judge upheld Medium severity under C4 criteria.
Karak: Delayed slashing window and lack of transparency for pending slashes could lead to loss of funds
Karak's restaking vaults let DSS operators queue a slash on a vault, but the two-day veto window delays finalization while the slash amount is already locked in from the vault's total assets at confirmation time. Because deposits remain open during that window, users who deposit after a slash is queued hold shares that are retroactively cut when the slash finalizes, losing value they never accrued. In the fully-slashed extreme, total assets reach zero while the share supply stays non-zero, so any new deposit is instantly diluted and partly credited to legacy holders. The sponsor first disputed the report as a frontend/indexer concern, but the judge upheld it as medium severity and Karak later mitigated it by pausing deposits during queued slashes, exposing an override method, and adding a queued-slash status getter.