Other chain and infrastructure vulnerabilities in disclosed reports
Wallets, node software, exchange infrastructure and chains outside the four major virtual machine families.
- Reports indexed
- 57
- Total paid
- $2k
- Critical
- 0
- Largest payout
- $2k
Not every crypto disclosure is a contract bug. Wallet key handling, transaction-signing UX that misrepresents what is being approved, node RPC exposure, and exchange-side account and withdrawal logic all sit here — and the payouts are frequently larger than contract findings because the blast radius is custodial.
This bucket also holds chains and runtimes outside the main four: UTXO chains, privacy chains, and purpose-built L1s whose failure modes do not map onto the EVM vocabulary.
Because the surface is heterogeneous, the vulnerability category filter is the more useful lens on these reports than the chain filter alone.
What reviewers look for
- Key material reachable from a lower-trust process or an unencrypted store
- Signing prompts that misrepresent the transaction being authorised
- Node RPC methods exposed without authentication
- Withdrawal and account-recovery logic on custodial infrastructure
- Consensus or mempool behaviour specific to a non-EVM runtime
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Docker Secret Disclosure via GitHub Actions Cache Poisoning
A GitHub Actions cache poisoning vulnerability was identified in the Hyperledger repository infrastructure. The flaw allowed unauthorized actors to modify shared build cache keys and execute arbitrary code within CI/CD pipeline steps. When downstream workflows restored the manipulated cache, sensitive Docker credentials stored in environment variables were exposed. This allowed attackers to extract critical pipeline secrets without requiring write permissions to the underlying repository.
Window.opener bug at www.coinbase.com
A web application link on www.coinbase.com opened external URLs using target="_blank" without setting the rel="noopener" or rel="noreferrer" security attributes. This allowed the newly opened destination window to access and manipulate the parent tab through the JavaScript window.opener reference. An attacker controlling the external target site could leverage this access to redirect the user's active Coinbase tab to a malicious external URL or phishing page. Coinbase rewarded the finding with a $100 bounty.
Metric: A permissionless swapper will extract principal from exact-share liquidity providers
Metric's exact-input in-bin swap functions (buyToken0InBinSpecifiedIn and buyToken1InBinSpecifiedIn) round a small expected output to zero while still advancing the active-bin cursor to the attacker-chosen target position, leaving both bin reserves and fee accumulators unchanged. A permissionless attacker can batch hundreds of these zero-input, zero-output swaps to desynchronize the cursor from reserves, let an exact-share LP deposit at a reserve-based price, and then trade back through the artificially created interval at the real oracle midpoint to extract the victim's principal. The PoC demonstrates a LP principal loss of roughly $33 (3.31 bps on a ~$99,900 deposit) with a matching attacker profit, all at an unchanged honest oracle quote.
Brevis Pico ZKVM: Malicious verifier will recover private witness values breaking zero-knowledge property
Brevis Pico, a privacy-preserving zkVM, relies on a fork of the gnark proving library (v0.1.0) that carries CVE-2024-45040: the Groth16 proving system emits Pedersen commitments without blinding factors. Because the BabyBear, KoalaBear, and verifier circuits invoke RangeChecker.Check() (which internally uses these unblinded commitments) whenever the GROTH16 environment variable is not set to 1 — the production default — a verifier who holds a proof can brute-force low-entropy private witnesses by regenerating commitments over candidate values and matching them. The accompanying Go PoC demonstrates recovery of a 10-bit secret from a proof commitment. This directly violates the zero-knowledge privacy guarantee the zkVM advertises, exposing program traces, memory access patterns, and confidential inputs such as keys or merkle leaves. The protocol team acknowledged the finding and fixed it in pull request #61, with the recommended mitigation being an upgrade to gnark 0.11.0.
Brevis Pico ZKVM: Missing `offset` check will cause integer overflow violating ELF specification
The Brevis Pico ZKVM's ELF disassembler, in the `Elf::new()` constructor, computed file offsets for segment loading with an unchecked u32 addition (`offset + i + j`) before casting to usize. Because the addition happens in u32 space, a crafted RISC-V ELF carrying a PT_LOAD segment whose p_offset sits near u32::MAX and whose mem_size drives the loop counters can make the sum wrap around to a small value. The wrapping neither panics nor returns an error, so the code proceeds to read `source_code` at the wrong offset, either out of bounds or from an unintended location. This breaks the guarantee that `Elf::new()` only accepts well-formed ELF binaries, corrupting downstream prover behavior. The protocol team fixed it by switching to checked arithmetic that surfaces an error on overflow, acknowledged in pull request 61.
Brevis Pico ZKVM: `operand_to_check` is not constrained to be a valid word in `eval_ecall`
Brevis Pico, a ZKVM that executes RISC-V guest programs, has a soundness gap in its environment-call path. The FieldWordRangeChecker assumes the argument `operand_to_check` is a valid word, but the `eval_ecall` constraints never constrain that operand to be well-formed, and unlike other chips it is not routed through the ALU lookup that would validate it. A malicious prover can witness invalid limbs — top limb equal to `most_sig_byte_decomp` and limb sum zero — and pass them to any non-halt, non-commit ecall. This lets ecalls accept words that are not genuine u8 words and, because host programs may use ecalls to call SP1 precompiles, the prover can shape ecall behavior and break the ZKVM's soundness guarantees.
All reports in this group
- Brevis Pico ZKVM: read_write chip does not enforce constraints on opcode selectorsLogic error$0
- Brevis Pico ZKVM: First chunk having cpu chip is incorrectly checked in convert circuitLogic error$0
- Brevis Pico ZKVM: wrong sign handling when x == 0 produces non-canonical / out-of-range x = pLogic error$0
- Brevis Pico ZKVM: Quotient domain is completely controlled by proverLogic error$0
- ZetaChain Cross-Chain: A Malicious Observer can use TON's Outbound Tracker to steal funds from ZetachainLogic error$0
- ZetaChain Cross-Chain: V1 ZEVM logs incorrectly use the `emittingContract` address as the CCTX `sender` addressLogic error$0
- ZetaChain Cross-Chain: Bitcoin Observers' signed transactions will be rejected due to invalid sighashesLogic error$0
- ZetaChain Cross-Chain: TON transactions risk being lost due to flawed transaction handlingLogic error$0
- ZetaChain Cross-Chain: ZETA coin type outbound CCTXs can be sent to unsupported external chains, which results in a DoS of the outbound queueLogic error$0
- ZetaChain Cross-Chain: Restricted addresses are still able to use Zetachain due to faulty updateAccess control$0
- SEDA Protocol: Malicious contracts can force excessive memory usage at minimal gas cost, threatening node stability and economic securityLogic error$0
- SEDA Protocol: Tally VM startup costs not charged early enoughLogic error$0
- SEDA Protocol: WASI imports can be exploited for unmetered execution or unbounded memory growthLogic error$0
- Babylon Chain Launch (Phase-2): maybeResendFromStore may wrongly submit a checkpoint transaction twiceLogic error$0
- Chakra: Inconsistent Handler Validation Behavior in Cairo ERC20Handler's Cross-Chain CallbackLogic error$0
- Chakra: Forcing Starknet handlers to be whitelisted on the same chain allows exploit of `BurnUnlock` mode to drain handler fundsBridge exploit$0
- Chakra: The `receive_cross_chain_msg` function has potential replay attack risksSignature replay$0
- Chakra: In Starknet, already processed messages can be re-submitted and by anyoneBridge 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: 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
- Axelar Network: Bridge requests to remote chains where interchain tokens are not deployed can result in DoS attacksLogic error$0
- Kakarot: Reentrancy check in `account_contract` can be easily circumventedReentrancy$0
- Kakarot: `RIPEMD160` precompile crashes with a Cairo exception for some input lengthsLogic error$0
- Kakarot: Prover can cheat in `felt_to_bytes_little` due to value underflowInteger overflow/underflow$0
- Kakarot: Missing constraint in `default_dict_copy`Logic error$0
- Kakarot: `ExponentiationImpl::pow()` returns `0` for `0^0`Logic error$0
- Kakarot: `decode_legacy_tx` allows validation of signatures with `chain_id` that are larger than felt, and overflowsInteger overflow/underflow$0
- Kakarot: Non-finalized dictionary in RIPEMD160 allows forging of outputLogic error$0
- 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…Logic error$0
- Velar Artha PerpDEX: User can sandwich their own position close to get back all of their position feesLogic error$0
- ZetaChain: Inbound Tx Confirmation Bypass via Malicious ObserverLogic error$0
- Aleo: `delegated[]` state is not removed after it reaches zero, potentially leading to higher computational costs and DoSLogic error$0
- Andromeda – Validator Staking ADO and Vesting ADO: Lockup of vestings or completion time can be bypassed due to missing check for staked tokensLogic error$0
- Phala Network: Limited availability of `balance_of(...)` methodLogic error$0
- Phala Network: An attacker can crash the cluster system by sending an HTTP request with a huge timeoutLogic error$0
- HydraDX: Users can MAKE EMA-Oracle price outdated with direct transfers to StableSwapOracle manipulation$0
- HydraDX: An attacker possesses the capability to exhaust the entirety of liquidity within the stable swap pools by manipulating the buy function, specifically by setting the `asset_in` parameter equal to the `asset_out` parameterLogic error$0
- HydraDX: No `safe_withdrawal` option in `withdraw_protocol_liquidity` function in omnipool can be abused by frontrunners to cause losses to the admin when removing liquidityFront-running / MEV$0
- Opus: Multiplier is incorrectly calculated in `Controller`Logic error$0
- Opus: Neglect of exceptional redistribution amounts in `withdraw_helper` functionLogic error$0
- Opus: `convert_to_yang_helper()` loss precisionLogic error$0
- Opus: An attacker could manipulate debt exceptional redistribution because it is allowed to deposit into any troveLogic error$0
- Opus: Shrine's recovery mode can be weaponized as leverage to liquidate healthy trovesLogic error$0
- Opus: Unhealthy troves with LTV > 90% cannot always be absorbed as intendedLogic error$0
- Opus: Collateral cannot be withdrawn from trove once yang is suspendedLogic error$0