Other protocol vulnerabilities in disclosed bug bounty reports

Staking, derivatives, insurance, identity, gaming and infrastructure findings that do not fit the primary protocol categories.

Reports indexed
708
Total paid
$352k
Critical
2
Largest payout
$350k

This group holds everything with a distinct economic design that the main categories do not cover: liquid staking and validator accounting, perpetuals and options with their own margin engines, insurance and coverage pools, identity and attestation systems, and on-chain games.

The findings are heterogeneous but the review discipline is the same — reconstruct the invariant, then find the input that breaks it — and several of the most instructive write-ups on the platform sit in this bucket precisely because the designs are unusual.

Filtering by vulnerability category is generally the better lens here than protocol type.

What reviewers look for

  • Custom margin or collateral engines with untested boundary behaviour
  • Staking and reward accounting under partial withdrawal or slashing
  • Coverage and claims logic reachable outside the intended lifecycle
  • Cross-protocol integrations trusting an external accounting value
  • Novel mechanisms without an established review checklist

Curated highlights

The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.

highGovernance attackEVM-Solidity$350k

Governance proposal executes arbitrary call via delegatecall module

A severe vulnerability in the governance timelock contract enabled proposal execution using DELEGATECALL without restricting the target address to a verified allowlist. Because the delegatecall target contract operated within the context of the timelock's storage without layout restrictions, a malicious proposal could overwrite key storage slots. An attacker leveraging flash loans or governance weight could pass a proposal that delegated to a custom contract, overwriting the timelock admin address in slot 0 to hijack governance authority and drain treasury funds.

DAO Treasurycode4renaJun 19, 2023Open
highLogic errorOther$2k

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.

hyperledgerhackeroneApr 20, 2024Open
mediumLogic errorOther$100

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.

coinbasehackeroneNov 28, 2016Open
mediumLogic errorEVM-Solidity$0

Rigor Protocol: `updateProjectHash` does not check project address

Rigor Protocol's Project.sol has an asymmetry in its signature-verification paths: every external function except `updateProjectHash` binds the signed `_data` payload to the project contract via `require(_data.projectAddress == address(this))`, but L162 omits this binding. Because the signed message does not commit to the specific project, a `_data`/`_signature`/`_nonce` tuple produced by a shared builder or contractor for one project can be replayed on a different project once its nonce counter reaches the same value. In practice this lets an observer reuse an older task-hash update signature to change a task hash in a newly opened project that shares the same signer group, bypassing authorization. The Rigor developer confirmed the finding during the Code4rena contest.

Rigor Protocolcode4renaAug 7, 2026Open
mediumLogic errorEVM-Solidity$0

Rigor Protocol: `Project.addTasks()` wouldn't work properly when it's called from disputes contract.

A stale task-count consistency check in Rigor's Project.addTasks() causes task additions to revert when a dispute is pending. Because disputes take days to resolve while builders/contractors may legitimately add tasks in the interim, the project becomes unable to add new tasks (beyond the count snapshot at raiseDispute time) until the dispute is settled. The report proposes skipping the taskCount equality check when addTasks is invoked from the disputes contract, and the developer confirmed the issue.

Rigor Protocolcode4renaAug 7, 2026Open
mediumReentrancyEVM-Solidity$0

Rigor Protocol: New subcontractor can be set for a SCConfirmed task without current subcontractor consent

Rigor Protocol's subcontractor management lets a builder or contractor reassign a task's subcontractor through inviteSC() without any signature check, whereas changing terms mid-task normally requires consent from all parties via checkSignatureTask(). Although the direct path (replacing a subcontractor on an already-confirmed, active task) is blocked by inviteSubcontractor()'s onlyInactive modifier, the warden showed the check is bypassed in changeOrder() budget-increase flows: when added funds are not yet lent, the task is unapproved and reset to inactive, after which a dishonest contractor can invite their own subcontractor who then collects the full task budget on completion, divesting the subcontractor who actually performed the work of their payment.

Rigor Protocolcode4renaAug 7, 2026Open

All reports in this group

Vulnerability classes seen in this protocol type

Related protocol type pages