Rigor Protocol — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Rigor Protocol, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 19
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 19 closed, publicly disclosed Rigor Protocol 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, Reentrancy, Access control, Integer overflow / underflow, 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 Rigor Protocol
- Reentrancy findings disclosed against Rigor Protocol
- Access control findings disclosed against Rigor Protocol
- Integer overflow / underflow findings disclosed against Rigor Protocol
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
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 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 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 Protocol: Wrong APR can be used when project is unpublished and published again
Rigor Protocol's Community contract lazily accrues interest, only updating lastTimestamp when repayLender, reduceDebt, or escrow is called. An admin can change a project's APR when it is republished into a community. If a project is unpublished while still owing debt, sits idle for a period during which no interest accrual call occurs, and is then republished with a higher APR, the new rate is applied retroactively to the entire idle window. In the documented scenario a 1,000,000 USD loan at 3% APR accrues a full year at the overwritten 5% rate, producing 50,000 USD of interest instead of the correct 30,000 USD — an inflated obligation on the borrowing project.
Rigor Protocol: Incorrect initialization of smart contracts with Access Control issue
Rigor Protocol's upgradeable contracts ship with initialize() functions that lack any caller authorization, and its proxy deployments pass an empty data field so initialization is deferred until after deployment. In the intervening window, a mempool-watching attacker can front-run the deployment and invoke an initializer first with arbitrary arguments, planting harmful contract addresses or settings. This can lead to loss of funds, loss of control over protocol components, contract/setting replacement, or forced redeployment. The sponsor confirmed the issue while disagreeing on severity, and the Code4rena judge upheld it as valid but downgraded it to Medium because the practical impact is limited and failed deployment transactions typically halt the script anyway.
Rigor Protocol: `changeOrder` requires subcontractor signature when the subcontractor address is 0
Rigor Protocol's Project contract treats contractor and subcontractor reassignments asymmetrically in its changeOrder path. Reassigning a task's contractor only demands a signature when a contractor is actually set, but the subcontractor branch always requires a signature from the current subcontractor — even after that address has been cleared to the zero address, which is the default state when no subcontractor is invited. Since the signature decoder returns address(0) for any malformed signature, a user in this state can only complete the intended operation by deliberately submitting an invalid signature, leaving a broken and confusing workflow with no direct financial impact. The Rigor team acknowledged the finding and agreed the subcontractor path should skip validation when the address is zero, mirroring the contractor logic.
All reports in this group
- Rigor Protocol: `Project.changeOrder()` would work unexpectedly for non SCConfirmed tasks.Logic error$0
- Rigor Protocol: Attacker can drain all the projects within minutes, if admin account has been exposedAccess control$0
- Rigor Protocol: `Project.raiseDispute()` doesn't use approvedHashes - meaning users who use contracts can't raise disputesLogic error$0
- Rigor Protocol: Builder can halve the interest paid to a community owner due to arithmetic roundingLogic error$0
- Rigor Protocol: In `Project.setComplete()`, the signature can be reused when the first call is reverted for some reasonLogic error$0
- Rigor Protocol: Untyped data signingLogic error$0
- Rigor Protocol: Possible DOS in `lendToProject()` and `toggleLendingNeeded()` function because unbounded loop can run out of gasLogic error$0
- Rigor Protocol: Missing upper limit definition in `replaceLenderFee()` of `HomeFi.sol`Integer overflow/underflow$0
- Rigor Protocol: Task Functionality completely sidestepped via `autoWithdraw`Logic error$0
- Rigor Protocol: Add members to the not yet created communityAccess control$0
- Rigor Protocol: Builders must pay more interest when the system is paused.Logic error$0
- Rigor Protocol: Owner of project NFT has no purposeLogic error$0
- Rigor Protocol: Builder can call `Community.escrow` again to reduce debt further using same signaturesLogic error$0