#0x1B

Integer Overflow in Vesting Period Calculation Enables Premature Full Unlock

@coleflumpussubmitted a report toJupiterApril 7, 2026 at 23:03

Severity	INFORMATIONAL
CVSS	7.5`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N`
Vulnerability Type	Integer Overflow
Asset	LocpQgucEQHbqNABEYvBvwoxCPsSbG91A1QaQhQQqjn - Jupiter Lock
Endpoint	`https://github.com/jup-ag/jup-lock%20(programs/locker/src/state/vesting_escrow.rs,%20lines%20140-150)`

Description

Summary

The get_max_unlocked_amount() function in Jupiter Lock's vesting escrow contains an integer overflow vulnerability that can cause premature full unlock of vesting tokens before the schedule permits, or transaction failure depending on whether the arithmetic is checked or unchecked.

Technical Details

Affected component: programs/locker/src/state/vesting_escrow.rs - get_max_unlocked_amount()
Root cause: The vesting calculation (current_ts - cliff_time) / frequency * amount_per_period does not cap the calculated period count to number_of_period before multiplying. When frequency = 1 (1 second), the division produces an enormous period count. Multiplying that by amount_per_period can exceed u64::MAX.
Note on arithmetic mode: Solana BPF compiles in release mode where Rust integer overflow wraps silently (modular arithmetic). If the program uses checked_mul or similar, the transaction would abort instead. The behavior depends on which arithmetic path is used. Wrapping enables premature unlock, checked arithmetic causes DoS.

The vulnerable math:

rust
(current_ts - cliff_time) / frequency * amount_per_period

When frequency = 1, after even moderate time has passed, the period count becomes very large. For example, 1 year = 31,536,000 periods. Multiply by a non-trivial amount_per_period and the result overflows u64.

Steps to Reproduce

Create a vesting escrow with the following parameters:

frequency = 1 (1 second interval)
amount_per_period = 1000
number_of_period = 1000

Fund the escrow with the appropriate token amount
Wait a significant amount of time (the longer, the more extreme the overflow)
Call claim() on the escrow
Observe that the period count calculation in get_max_unlocked_amount() produces a value far exceeding number_of_period
The multiplication by amount_per_period overflows u64

Expected behavior: The claimable amount should never exceed number_of_period * amount_per_period (the total vesting amount).

Actual behavior: The uncapped period count causes arithmetic overflow, potentially allowing claims beyond the intended vesting amount.

Impact

If wrapping arithmetic is used: the overflow causes get_max_unlocked_amount() to return an incorrect value, enabling the recipient to unlock all tokens in the escrow before the vesting schedule permits. The actual claim is still bounded by the escrow's token balance; the recipient cannot extract more tokens than were deposited, but they can bypass the intended time-lock.

If checked arithmetic is used: the overflow causes the claim transaction to abort, resulting in denial of service for the escrow recipient who cannot claim their tokens.

Affected users/data: Vesting escrows created with small frequency values (especially frequency = 1) where a third party created the escrow for a beneficiary. Self-created escrows are not meaningfully affected since the creator controls their own tokens.

Business impact: Protocols using Jupiter Lock for employee/investor vesting could have their time-lock guarantees bypassed. Undermines trust in Jupiter Lock as a vesting mechanism.

Severity justification: Rated HIGH (CVSS 7.5) because it is network-exploitable, requires no special privileges, and breaks the core vesting time-lock guarantee. The attack requires specific parameter choices at escrow creation time.

Recommended fix: Cap the calculated period count to number_of_period before multiplication, and enforce a minimum frequency value at escrow creation time.

Activity

@raccoonsclosed the report asNot Applicable

Apr 8

Hi @coleflumpus, Thank you for your submission. After reviewing the report against our current codebase, we've determined this is not applicable. The vulnerability described - that the period count is not capped before multiplication - does not exist in the code. The get_max_unlocked_amount() function explicitly caps the computed period count before performing the multiplication: ``` let period = current_ts .safe_sub(self.cliff_time)? .safe_div(self.frequency)?; let period = period.min(self.number_of_period); // capped here ``` Also, all arithmetic in this function uses checked math (safe_mul, safe_add, etc.) which returns an error on overflow rather than wrapping. The wrapping/silent overflow scenario described in the report cannot occur. The recommended fix in the report — "cap the calculated period count to number_of_period before multiplication" - is already implemented. We are closing this report as Not Applicable. Thanks for thinking of our security - we appreciate the effort.

@raccoonschanged the severity fromhightoinformational

6d ago

@raccoonsdisclosed this reportPublic Disclosure

4d ago

Properties

Status

Not Applicable

Severity

INFORMATIONAL

Reporter

@coleflumpus

Program

Jupiter