Bug Bounty Submission: Same-Nonce Message Replay Vulnerability in Bridged Reputation Root Hash Update

[loopghost]

Bug Bounty Submission: Same-Nonce Message Replay Vulnerability in Bridged Reputation Root Hash Update

Prerequisite

I ensured that this issue, specifically the weak nonce check (>=) in setReputationRootHashFromBridge allowing same-nonce replays, has not already been reported.

Summary

The setReputationRootHashFromBridge function within the ColonyNetworkMining.sol contract utilizes a non-strict nonce check (require(_nonce >= bridgeCurrentRootHashNonces[...])) for processing reputation root hash updates received via the bridge. This implementation flaw allows a message with a specific nonce to be processed multiple times consecutively if it is resubmitted before a message with a strictly higher nonce is processed. This enables a replay attack that forces the contract to re-execute logic, consume gas unnecessarily, and emit duplicate events, violating the integrity of the nonce mechanism and potentially impacting dependent off-chain systems. This constitutes a High Risk vulnerability according to the OWASP Risk Rating methodology.

Steps to Reproduce (Conceptual PoC)

This Proof of Concept demonstrates how a message with the same nonce can be processed multiple times. Let Chain M be the source chain and Chain C be the target chain where this code runs.

• Initial State: Chain C has processed messages from Chain M up to nonce N. The state variable bridgeCurrentRootHashNonces[<Chain_M_ID>] on Chain C holds N. The reputation state is (HASH_OLD, LEAVES_OLD).

• Valid Message Sent: Chain M sends Msg1 = (HASH_A, LEAVES_A, nonce=N+1) via the bridge to Chain C.

• First Successful Processing on Chain C:

  • WormholeBridgeForColony calls ColonyNetworkMining.setReputationRootHashFromBridge(HASH_A, LEAVES_A, N+1).
  • Check: require(N+1 >= N) passes.
  • State updated to (HASH_A, LEAVES_A). Nonce map updated to N+1. Event ReputationRootHashSet(HASH_A, ...) emitted.

• Replay Attempt: Before a message with nonce N+2 is sent/processed, an attacker resubmits the exact same Msg1 (containing nonce=N+1) to Chain C.

• Second (Replay) Processing on Chain C:

  • WormholeBridgeForColony calls ColonyNetworkMining.setReputationRootHashFromBridge(HASH_A, LEAVES_A, N+1) again.
  • Check: require(nonce (N+1) >= bridgeCurrentRootHashNonces[<Chain_M_ID>] (N+1)) passes due to >=. <- Vulnerability.
  • State (HASH_A, LEAVES_A) is reapplied (no change). Nonce map set to N+1 (no change). Event ReputationRootHashSet(HASH_A, ...) is emitted again. Gas is consumed.

Expected Behavior

The nonce mechanism should strictly prevent the same message (identified by its nonce and origin) from being processed more than once. A check like require(_nonce > bridgeCurrentRootHashNonces[...]) should be used to ensure each nonce is processed at most once, rejecting replays of the exact same nonce.

Current Behaviour

The use of >= in the nonce check allows a message with nonce N+1 to be successfully processed even if the current stored nonce is already N+1, permitting consecutive replays.

Possible Solution

Modify the nonce check in ColonyNetworkMining.setReputationRootHashFromBridge to require the incoming nonce to be strictly greater than the last processed nonce:

// Inside setReputationRootHashFromBridge function
// Note: Assuming the map key is correctly representing the source chain ID in the actual implementation.
uint256 sourceChainId = ...; // Determine source chain ID correctly
uint256 lastProcessedNonce = bridgeCurrentRootHashNonces[sourceChainId];
require(_nonce > lastProcessedNonce, "colony-mining-bridge-nonce-must-be-greater");
bridgeCurrentRootHashNonces[sourceChainId] = _nonce;

Context

• OWASP Risk Rating:

  • Likelihood: High. The flawed >= logic is present. Exploitation requires resubmitting a VAA, which is a feasible scenario for relayers or bridge mechanisms.
  • Impact: Medium. The replay does not corrupt the core state values but:
    • Weakens Nonce Integrity: Allows processing the same logical update multiple times.
    • Causes Unnecessary Gas Expenditure: Enables potential gas griefing on the target chain.
    • Generates Duplicate Events: Can disrupt off-chain indexers or systems relying on unique events per state update.
  • Overall OWASP Risk: High (Likelihood) * Medium (Impact) = High Risk.

• Severity Classification: Based strictly on the OWASP Risk Rating methodology, a High Risk corresponds to a High Severity classification for this vulnerability.

Environment

• Operating System: N/A (Blockchain/Solidity bug)
• Ethereum client: N/A (Applies to any EVM chain where deployed)
• solc version: 0.8.28 (as specified in pragmas)

---

Please consider rewarding this submission to your Bug Bounty Program accordingly as a High Severity vulnerability. Kindly issue the bounty to the following address: 0x36c81e0ec22cac063a0588b6165ce3fd022ab5b0

[area]

Hi,

Thanks for this exhaustive explanation of the issue you've found. I agree with nearly everything you've said here. However, I think one element that you have (understandably) overlooked that needs to be considered is that this functionality has never been used, and will never be used; it is being superseded by #1285 (or possibly removed without replacement, depending on other decisions being made). I think that should be incorporated in to the overall Likelihood rating and result in either a Medium or Low, depending on how much that factor is weighted. I also think the impact is clearly Low - while the event can be emitted repeatedly, this is no different from being able to emit a Transfer event on an ERC20 token for 0 tokens repeatedly. It's certainly imperfect behaviour, but I don't believe it has any meaningful consequence.

Nevertheless, I agree with your fundamental point that the nonce check there is wrong, and it is clear that mistake could have had a much worse outcome in another function. I will raise the issue at the next appropriate meeting and see if it is decided as worthy of a bounty - but to manage expectations, if it is, I would certainly not expect it to be assessed as 'High Risk'.

Thanks again,

[loopghost]

Hi area,Thank you for the prompt and detailed response to our submission. I appreciate you taking the time to review it thoroughly.I understand and accept your points regarding the Likelihood assessment. If the `setReputationRootHashFromBridge` functionality has indeed never been used and is slated for removal or replacement (as per #1285), I agree that the practical likelihood of this specific vulnerability being exploited approaches zero. This context significantly lowers the overall practical risk from our initial assessment.Regarding the Impact, I acknowledge your comparison to zero-value transfers and agree that, especially given the function's deprecated status, the practical consequences are likely low. While I initially considered the potential for non-negligible gas griefing (as VAA processing + execution might exceed simple transfer costs) and the theoretical impact of duplicate events on potential off-chain systems, I concede that without evidence of active use or significant real-world consequences, classifying the practical impact as Low is reasonable in this specific instance.I also appreciate the acknowledgement that the `>=` nonce check itself is fundamentally incorrect and represents a pattern that could have led to more severe issues in other contexts. Highlighting such patterns, even in unused code, can sometimes contribute to overall system robustness.Therefore, considering the crucial context you provided, particularly the significantly reduced Likelihood due to the function's status, I concur that reassessing the overall OWASP risk to Low (Low Likelihood * Low Impact) and consequently classifying the severity as Low for this specific report is appropriate.I understand this revised assessment impacts bounty expectations accordingly and appreciate the transparency.Thanks again for your time and consideration, and please let me know when to expect a bounty decision!Best regards,iJNREl 23 abr 2025, a las 12:19, Alex Rea ***@***.***> escribió: Hi, Thanks for this exhaustive explanation of the issue you've found. I agree with nearly everything you've said here. However, I think one element that you have (understandably) overlooked that needs to be considered is that this functionality has never been used, and will never be used; it is being superseded by #1285 (or possibly removed without replacement, depending on other decisions being made). I think that should be incorporated in to the overall Likelihood rating and result in either a Medium or Low, depending on how much that factor is weighted. I also think the impact is clearly Low - while the event can be emitted repeatedly, this is no different from being able to emit a Transfer event on an ERC20 token for 0 tokens repeatedly. It's certainly imperfect behaviour, but I don't believe it has any meaningful consequence. Nevertheless, I agree with your fundamental point that the nonce check there is wrong, and it is clear that mistake could have had a much worse outcome in another function. I will raise the issue at the next appropriate meeting and see if it is decided as worthy of a bounty - but to manage expectations, if it is, I would certainly not expect it to be assessed as 'High Risk'. Thanks again,—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***> area left a comment (JoinColony/colonyNetwork#1325) Hi, Thanks for this exhaustive explanation of the issue you've found. I agree with nearly everything you've said here. However, I think one element that you have (understandably) overlooked that needs to be considered is that this functionality has never been used, and will never be used; it is being superseded by #1285 (or possibly removed without replacement, depending on other decisions being made). I think that should be incorporated in to the overall Likelihood rating and result in either a Medium or Low, depending on how much that factor is weighted. I also think the impact is clearly Low - while the event can be emitted repeatedly, this is no different from being able to emit a Transfer event on an ERC20 token for 0 tokens repeatedly. It's certainly imperfect behaviour, but I don't believe it has any meaningful consequence. Nevertheless, I agree with your fundamental point that the nonce check there is wrong, and it is clear that mistake could have had a much worse outcome in another function. I will raise the issue at the next appropriate meeting and see if it is decided as worthy of a bounty - but to manage expectations, if it is, I would certainly not expect it to be assessed as 'High Risk'. Thanks again, —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[loopghost]

Hi again @area ! Sending this message as a follow-up. Have you already taken a decision regarding the bounty? It’s been 3 weeks since you mentioned:

’I will raise the issue at the next appropriate meeting and see if it is decided as worthy of a bounty’

I still have not received any kind of answer and decision regarding the bounty.

Please provide an update if possible.

Thanks!

[loopghost]

Hi area,

Etienne told me you’d provide the final bounty decision today. Thanks again for the ongoing communication.

Further to our previous exchange where we aligned on a Low practical severity due to the function's specific lifecycle status, I've been reflecting on the value of the finding.

While I fully respect and understand that the non-active status of this particular code path means the immediate risk was minimal, I hope the team might also consider the value in identifying the underlying incorrect pattern (>= for nonces), which you acknowledged could have had more severe consequences elsewhere. The quality and detail of the report were also intended to be as helpful as possible.

With this in mind, and understanding it would fall under a "Low" severity classification, I would be very appreciative if a potential bounty could reflect these aspects, perhaps aligning towards the upper end of the "Low" tier ($2,000, given that figure is consistent with your program's structure for Low findings of this nature).

Of course, I look forward to hearing the team's final decision whenever it's ready. In case of wanting to proceed with the suggested 2,000$ bounty, please issue this bounty to the following ETH address: 0x36c81e0ec22cac063a0588b6165ce3fd022ab5b0

Thanks for your consideration.

Best regards,

iJNR

[area]

Hi,

This issue was discussed at a meeting earlier this week. The consensus was that the bug report was eligible for the bounty, but the fact that the codepath is not exploitable currently, is not expected to be in the future, and has minimal consequences even if it reached that point all weighed against it.

Further to your most recent message, I will draw attention to the fact that the low severity and low likelihood put the overall risk severity as 'note', not 'low' (see the table under "Determining Severity" here).

Unfortunately, there was general agreement that this was only going to be eligible for a reward at the low end of the appropriate range of the bounty program, which is $100 in the case of a 'Note'. A reasonable case was made for this not being an issue at all, but enough voices in the room believed that there should be a payout of some sort. I appreciate this might be disappointing, but I hope you understand the reasoning.

The reward will be sent as USDC on Arbitrum One next week. Please let me know if you have any further questions, and thanks for your patience since reporting the issue.

Thanks,

[loopghost]

Hi area,

Thanks for the update and the detailed explanation regarding the bounty decision. I understand the reasoning behind classifying this specific instance as 'Note' severity, especially given that the codepath is not in use and won't be in the future, which significantly lowers its practical risk.

I appreciate the team's consensus to award a bounty despite these circumstances and accept the $100 offer. I'm glad that the identification of the underlying incorrect nonce pattern (>=) was acknowledged as something that could have been problematic elsewhere.

Thank you for your time and for running the bug bounty program. My USDC address on Arbitrum One is the one mentioned in the above message.

I look forward to future contributions.

Best regards,
iJNR

[loopghost]

Hi! It's been 1 week since your last message, where you mentioned you'd issue the 100$ payment within a week. Could you please provide an update or confirm if it has already been issued? (I have many different transactions in that wallet and for that reason I'd appreciate if you could attach the txn hash).

Thank you very much!!

[area]

Hey,

This is the transaction: https://arbiscan.io/tx/0xf3d3ec3581fae82fc56b415d53fb76e0e1d2beca838973e50e745e68a1c819b9

Cheers,

[loopghost]

Hi! Thank you very much! Appreciate you!