Summary

A critical vulnerability has been identified in the Zaros protocol's Distribution system affecting reward calculations for users who exit and re-enter the staking system. This flaw enables potential exploitation of reward distributions through manipulation of the value-per-share accounting mechanism.

The Distribution library implements a reward tracking system used by VaultRouterBranch for managing staker rewards. The vulnerability exists in the _updateLastValuePerShare function:

When an actor's shares become zero during exit, their lastValuePerShare is reset to 0 instead of maintaining the global valuePerShare value. This creates an accounting discrepancy that can be exploited when users re-enter the system.

Exploitation Path

Consider this sequence:

1. A user enters with globalValuePerShare = 100

   • User's lastValuePerShare is set to 100

   • Normal reward accrual begins

2. Global value increases to 200 through rewards

   • User's reward calculation: 200 - 100 = 100 (correct)

3. User exits the system

   • Instead of maintaining lastValuePerShare = 200

   • System incorrectly sets lastValuePerShare = 0

4. Global value increases to 300

5. User re-enters the system

   • System calculates rewards as: 300 - 0 = 300

   • Correct calculation should be: 300 - 200 = 100

   • User receives 200 extra reward units

Impact

The vulnerability creates a compounding economic drain through reward accounting errors. When users exploit the exit/re-entry pattern, they receive inflated rewards at the expense of legitimate stakers, directly undermining the protocol's incentive structure. This exploitation scales with protocol activity - higher reward frequencies, value volatility, and pool sizes amplify potential gains, while increased user activity masks the manipulation. The resulting feedback loop threatens protocol sustainability as successful exploitation breeds further abuse, creating an exponential drain on resources.

The vulnerability can be further demonstrated through the VaultRouterBranch contract:

Even with the protective check:

The underlying accounting error persists and can be exploited through careful timing of exits and entries.

Example Scenario:

1. User State Before Exit:

1. User Actions:

1. During Unstaked Period:

1. User Re-enters:

The protection only prevents unstaking with unclaimed rewards. It doesn't address the underlying issue of lastValuePerShare being reset to 0. A user can always clear their pending rewards first, then execute the exit/re-entry strategy to exploit the accounting error.

Recommendation

Modify _updateLastValuePerShare: