CryptoLegacy: Vesting mixes a live rebasing balance with a stored total, so a rebase makes equal shares pay unequally

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 61287-rebaseable-tokens-cause-unfair-vesting-and-claim-failures-mi. The historical source/toolchain is unavailable; this entry is documentation only and claims no executable Forge PoC.

Vulnerability classes: vuln/rebasing-token · vuln/accounting-drift · vuln/vesting

Reproduction: a faithful minimal reproduction of the vulnerable finding — the vulnerable function is reproduced verbatim (marked @>) with faithful minimal doubles; local deploy, no fork.

Root cause#

amountToDistribute = token.balanceOf(this) + totalClaimedAmount adds a LIVE rebasing balance to a STORED non-rebasing running total. When the token rebases between two beneficiaries' claims, the distribution base shifts, so beneficiaries holding EQUAL shares end with UNEQUAL totals (1,125 vs 875) — a 250-token unfair disparity.

        // total distributable = current live balance + everything already claimed.
        // On a rebasing token balanceOf() shifts while totalClaimedAmount does not,
        // so equal shares yield unequal payouts across claims.
        uint256 amountToDistribute = IRebaseToken(_token).balanceOf(address(this)) + totalClaimedAmount; // @>

Why it's exploitable here#

• The distribution base moves with every rebase because it is derived from balanceOf.
• totalClaimedAmount is a fixed running total, so the two terms are denominated inconsistently after a rebase.
• Two beneficiaries with identical fixed shares end up with different payouts purely from claim timing around a rebase.

Attack path#

Marked-line walkthrough (Playground)#

The EVM Playground pins each step to the exact executed source line in CryptoLegacyVesting:

1. Line 112 — VULN. amountToDistribute adds the rebasing balanceOf(this) to the non-rebasing totalClaimedAmount — the base moves with each rebase.
2. Line 114 — vestedAmount = amountToDistribute * shares / BASE * vesting / BASE uses the distorted base.
3. Line 115 — claimAmount = vestedAmount - claimed; a rebase between two equal-share claims produces a 250-token disparity.

PoC#

Registry (Foundry, local deploy — exploit path + a fixed-variant control):

cd 61287-rebaseable-tokens-cause-unfair-vesting-and-claim-failures-_exp
forge test -vv

Expected: both tests PASS — the exploit test claims around a rebase and asserts a 250-token disparity between equal-share beneficiaries; the fixed accounting keeps them equal. The browser EVM Playground is served at /hacks/61287-rebaseable-tokens-cause-unfair-vesting-and-claim-failures-/.

Remediation#

Track the total distributed amount independently of the live token balance; do not derive amountToDistribute from balanceOf of a rebasing token.

References#

• AuditVault finding: https://github.com/Auditware/AuditVault/blob/main/findings/61287-rebaseable-tokens-cause-unfair-vesting-and-claim-failures-mi.md

Sources & further analysis#

Reproductions & code

• No executable Forge reproduction is claimed; the historical source/toolchain was unavailable for this finding.
• AuditVault finding: 61287-rebaseable-tokens-cause-unfair-vesting-and-claim-failures-mi.
• Upstream DeFiHackLabs PoC directory: src/test.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "CryptoLegacy: Vesting mixes a live rebasing balance with a stored total, so a rebase makes equal shares pay unequally".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.