Full Report
A consensus method is how a group of entities come to a single source of truth. Bitcoin and Ethereum uses proof of work in order to do this. Newer blockchains are using proof of stake. This means that money is put into the pot to demonstrate that the environment means something to them. These stakers or validators are important to the ecosystem for ensuring everything is done properly. In Polygon, a layer 2 blockchain solution, there is a list of Validators for proving that a transaction was done correctly. In order to become a validator, you must stake or give up your token to the blockchain. There is a limit of 100 validators for this ecosystem at a time though. There is a struct in Solidity for keeping track of this information with two fields: validatorState.amount and validatorState.stakerCount. The amount is the amount of tokens staked, which is the staking power. The stakerCount is the total number of stakers in the contract, which is likely to be 100. When a validator unstakes, the counter of the validatorState.amount updates by subtracting the amount of the user who provided the value. This allows users to stake and unstake as they would like, collecting rewards when they unstake. There is an additional piece of functionality that is important for this vuln: delegation migration. A user can migrate their delegated token amounts from one validator to another. Importantly, this can be done without losing the amount of tokens by the original user; meaning, they can unstake the delegated tokens themselves. The vulnerability arises from a double subtraction error. When migrating from one account to another, the validatorState.amount is updated to subtract the amount of token delegated. Additionally, when the original user wants to retrieve their unstaked token, they still can! This means we can subtract from validatorState.amount multiple times. By doing this double subtraction, over time, we can shrink the validatorState.amount variable to be very small. At this point, we could override updates with the 2/3 rule to control the network. The bug finder only got 75K for this bug instead of the several million they probably deserve. This was explained away by the complexity of time consuming nature of the bug, with very specific network circumstances. However, a bug at the core of the consensus network could have led to a complete take over of the network! Regardless, a fascinating bug.
Analysis Summary
# Vulnerability: Polygon Consensus Bypass via Double Token Subtraction
## CVE Details
- CVE ID: Not explicitly provided in the text (Assumed to be a private/internal finding initially)
- CVSS Score: Not explicitly provided (Assigned **High** severity by the researcher/platform)
- CWE: CWE-191: Integer Underflow/Overflow (Implied by direct subtraction leading to state corruption, specifically double subtraction)
## Affected Systems
- Products: Polygon Proof of Stake (PoS) System Smart Contracts on Ethereum (Layer 2 solution)
- Versions: Specific vulnerable versions are not named, but it affects the mechanism tracking validator staking amounts.
- Configurations: Any configuration where delegation migration and subsequent user unstaking interact, specifically concerning the `validatorState` struct updates.
## Vulnerability Description
The vulnerability lies in incorrect accounting for token amounts within the Polygon PoS staking mechanism, specifically affecting the `validatorState` struct which tracks `amount` (total staked tokens) and `stakerCount`.
The flaw arises from two separate operations that both incorrectly reduce the total staked amount:
1. **Delegation Migration:** When a user migrates delegated tokens from Validator A to Validator B, the original validator's state (`validatorState.amount`) is reduced by the delegated amount.
2. **User Unstaking:** Crucially, the original user retains the ability to unstake their tokens *after* the migration (as if the delegation never fully removed their claim). When the user unstakes, the `validatorState.amount` is reduced again for the same tokens.
This **double subtraction** error allows an attacker to repeatedly decrease the recorded total staked amount (`validatorState.amount`) over time. By artificially lowering this value, an attacker could significantly reduce the actual staking power required to meet the network's 2/3 consensus threshold, potentially leading to a consensus bypass, control over the network state, and the ability to drain associated funds (like from the deposit manager).
## Exploitation
- Status: **PoC available** (A local mainnet fork Proof of Concept was submitted).
- Complexity: **High**. The text notes that exploitation required specific, time-consuming network conditions, including maintaining a validator spot for long periods, coinciding with an open validator spot, and high capital requirements to cover ongoing costs (e.g., flashbots payments).
- Attack Vector: Likely **Smart Contract Interaction Sequence** leading to an eventual consensus-level attack.
## Impact
- Confidentiality: Low (The primary goal appears to be state control, not data theft)
- Integrity: **High**. Potential for consensus bypass, allowing manipulation of network state and fund misappropriation from the deposit manager.
- Availability: Medium/High. Potential for Denial of Service (DoS) if the attacker gains control to halt operations or make invalid state changes.
## Remediation
### Patches
- Patches were developed and implemented following the disclosure. No specific patch version numbers are listed, but the nature of the fix implies correcting the logic around delegation migration and user unstaking to ensure tokens are only subtracted once across all related operations.
### Workarounds
- Due to the complexity and high cost of the required preconditions (time, capital, network timing), no immediate, simple workarounds were explicitly mentioned aside from the implied requirement for the developers to fix the underlying logic.
## Detection
- **Indicators of Compromise (IoCs):** Unusual rapid and sustained decreases in the `validatorState.amount` without corresponding, traceable full unbonding periods. Monitoring transaction sequences involving delegation migration followed immediately by the original staker initiating an unstake call.
- **Detection Methods and Tools:** Requires deep analysis of the staking contract state transitions, specifically watching for discrepancies between the sum of individual stakes and the aggregated `validatorState.amount` after migration/unstaking sequences. Automated monitoring for state drift in critical consensus variables.
## References
- Vendor Advisories: Disclosure made via the Immunefi platform to Polygon.
- Relevant links:
- [https://medium.com/immunefi/polygon-consensus-bypass-bugfix-review-34842132ec6d](https://medium.com/immunefi/polygon-consensus-bypass-bugfix-review-34842132ec6d) (Original source summary)