Nibiru — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Nibiru, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 13
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 13 closed, publicly disclosed Nibiru 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, Oracle manipulation, across Cosmos-SDK, 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 Nibiru
- Oracle manipulation findings disclosed against Nibiru
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Nibiru: Non-deterministic gas consumption due to shared `StateDB` pointer in bank keeper affecting consensus
Nibiru's EVM bank keeper stored a pointer to the EVM StateDB as a struct field, and that pointer could be reassigned by read-only RPC operations such as eth_estimateGas. Because SyncStateDBWithAccount's nil check diverts program flow in native bank transactions, a node that had served such a query computed a different gas amount for an identical bank send than a node that had not. Since validators must agree on gas consumption to reach consensus, this nondeterminism can stall the chain. The judge dismissed the finding initially but upheld it as High after a second review, and the sponsor confirmed and mitigated it in PR-2165/2173.
Nibiru: Vesting account preemption attack preventing future contract deployment
On Nibiru, EVM addresses and Cosmos addresses map to the same bytes, so the chain's auth/vesting module can create a permanent locked account at an EVM address that a factory contract is about to CREATE-deploy to. When the later deployment runs, the EVM writes the contract bytecode into state but never sets a codeHash because the account type is a vesting account rather than EthAccountI, orphaning the bytecode and permanently locking any funds sent with the deployment. The attack targets deterministic deployer addresses (CREATE-derived child contracts), which the maintainers judged an edge case but "a nice finding." Nibiru confirmed it and disabled the unused built-in auth/vesting module in PR-2127, since vesting is already handled by Wasm contracts.
Nibiru: `IOracle.queryExchangeRate` returns incorrect `blockTimeMs`
Nibiru's EVM oracle precompile implements IOracle.queryExchangeRate, which returns price, blockTimeMs and blockHeight for a given asset pair and is documented to return the time the price was last updated. The implementation forwards the call to OracleKeeper.GetDatedExchangeRate, but that keeper returns the timestamp of the current block rather than the block time recorded at the last price update. As a result, the returned timestamp always reflects "now," so downstream contracts that validate price freshness against blockTimeMs will always see the price as freshly set even when it is extremely old, defeating staleness checks. Nibiru confirmed and fixed the issue in PR-2117 by adding an explicit timestamp field to the stored price/block data structure, and the judge decreed Medium severity since the stale-price scenario is an external requirement rather than a direct in-protocol loss.
Nibiru: Nonce can be manipulated by inserting a contract creation `EthereumTx` message first in an SDK TX with multiple `EthereumTX` messages
Nibiru's x/evm module fails to persist the sender account sequence correctly when multiple MsgEthereumTx messages are batched in one Cosmos-SDK transaction. The Ante handler advances the sequence once per message, but the ApplyEvmMsg execution path only writes the sender nonce for contract-creation transactions (setting it to msg.Nonce()+1); ordinary call/transfer messages leave the nonce untouched. Because a contract-creation transaction placed first rewinds the committed sequence, the nonces actually consumed by subsequent call/transfer messages are not persisted, leaving those messages replayable with identical nonces. The finding was upheld by the judge and confirmed by the sponsor after a dispute, downgraded to Medium for lack of direct asset or liveness impact, and mitigated in PR-2130 with proper nonce management in the statedb.
Nibiru: Gas refunds use block gas instead of transaction gas, leading to incorrect refund amounts
In the Nibiru EVM module, transaction gas fees are deducted upfront against each EVM message's own gas limit, but the refund computed in the message server compares that limit against a counter (named BlockGasUsed) that accumulates gas across all EVM messages bundled inside a single Cosmos SDK transaction. As a result, when several EVM messages are batched into one transaction, each subsequent message is refunded far less than the amount actually unused, letting the chain keep more gas fee than it consumed and silently costing users funds. The protocol disputed the premise, noting the counter is reset between transactions and thus represents cumulative per-transaction gas, yet it still shipped PR-2132 to move the refund out of CallContract, and the mitigation was confirmed by the judge at Medium severity.
Nibiru: Double fee application breaks supply invariant for fee-on-transfer ERC20s
Nibiru's EVM module bridges ERC20 tokens and their Cosmos bank-coin representations through two conversions, sendToBank and convertCoinToEvmBornERC20. The forward conversion correctly mints only the net amount actually received after a fee-on-transfer charge, but the reverse conversion burns only the post-fee transferred amount instead of the full bank-coin input. That burns the transfer fee on both legs of the round trip, leaving a residue of unbacked bank coins in circulation that breaks the protocol's intended 1:1 supply-tracking invariant between the ERC20 and its bank-coin twin. The maintainers confirmed the bug, noted the leaked coins accumulate at an inaccessible EVM-module address (functionally burned but still distorting total-supply accounting), and fixed it in PR-2139 by burning the full input amount.
All reports in this group
- Nibiru: The `bankBalance` function failed to handle errors correctlyLogic error$0
- Nibiru: Gas used mismatch in failed contract calls can lead to wrong gas deductionsLogic error$0
- Nibiru: Inconsistent fee denomination handling in transaction validation and buildingLogic error$0
- Nibiru: Hardcoded gas used in ERC20 queries allows for block production halt from infinite recursionLogic error$0
- Nibiru: ERC20 transfer fails with non-compliant tokens missing return valuesLogic error$0
- Nibiru: Unlimited Nibi could be minted because evm and bank balance are not synced when stakingLogic error$0
- Nibiru: Gas is not consumed when precompile method fail, allowing resource consumption related DOSLogic error$0