Reproduced Exploit

Ajna Protocol — PositionManager's `moveLiquidity` freezes LP via wrong deposit time

1. moveLiquidity copies fromPosition.depositTime onto toPosition. 2. Destination bucket may have bankruptcyTime > from.depositTime. 3. Pool-side LenderActions renews deposit time past bankruptcy; PositionManager does not. 4. redeemPositions then reverts BucketBankrupt — moved funds frozen.

May 2023Otheruntagged2 min read

Chain

Other

Category

untagged

Date

May 2023

Source

AuditVault

EVM Playground

Source-level debugger — step opcodes and Solidity in sync

evm-hack-analyzer

The attack is replayed in an in-browser EVM preloaded with the exact dumped fork state. The execution tree shows every call; step by Solidity line or by opcode across all depths — source, Stack, Memory, Storage, Balances (native / ERC-20 / NFT), Transient storage and Return value stay in sync. Click a tree node, opcode, or source line to jump. No backend, no live RPC.

Loading fork state…

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 20070-h-02-positionmanagers-moveliquidity-can-set-wrong-deposit-ti. Standalone Foundry PoC and full write-up: 20070-h-02-positionmanagers-moveliquidity-can-set-wrong-deposit-ti_exp in the evm-hack-registry mirror.


Vulnerability classes: impact/loss-of-funds/locked-funds · frozen-funds

Reproduction: self-contained Foundry PoC with only forge-std — no fork. Full trace: output.txt.


Key info#

ImpactHIGH — moved LP permanently frozen when destination bucket is bankrupt vs stale depositTime
ProtocolAjna Protocol — PositionManager
Vulnerable codetoPosition.depositTime = vars.depositTime (source copy)
Bug classIncorrect time inheritance across bucket bankruptcy
FindingCode4rena — Ajna, 2023-05 · #20070 · [H-02] · reporter hyh
Reportcode4rena.com/reports/2023-05-ajna
SourceAuditVault
Compiler^0.8.24 (PoC)

TL;DR#

  1. moveLiquidity copies fromPosition.depositTime onto toPosition.
  2. Destination bucket may have bankruptcyTime > from.depositTime.
  3. Pool-side LenderActions renews deposit time past bankruptcy; PositionManager does not.
  4. redeemPositions then reverts BucketBankrupt — moved funds frozen.

The vulnerable code#

SOLIDITY
// update position deposit time to the from bucket deposit time
toPosition.depositTime = vars.depositTime; // @> VULN

Root cause#

Source deposit time is a valid liveness certificate only for the source bucket. Copying it to an arbitrary destination ignores that bucket's bankruptcy clock. LenderActions already computes the correct destination time; PositionManager does not.

Attack walkthrough#

  1. Healthy LP at fromIndex with depositTime=100.
  2. toIndex has bankruptcyTime=500.
  3. After move, PositionManager stamps depositTime=100; pool would use 501.
  4. redeem reverts because 100 <= 500.

Diagrams#

sequenceDiagram participant O as Owner participant PM as PositionManager participant P as Pool O->>PM: moveLiquidity(from healthy, to bankrupt) PM->>P: moveQuoteToken (pool sets depositTime=bankruptcy+1) PM->>PM: toPosition.depositTime = from.depositTime (stale) O->>PM: redeemPositions(toIndex) Note over PM: depositTime <= bankruptcyTime - revert BucketBankrupt

Impact#

Permanent loss of access to moved LP whenever destination bankruptcy exceeds the copied source deposit time — a common operation with no exotic prerequisites.

Sources#

Taxonomy: [[frozen-funds]] · [[locked-funds]] · severity/high · sector/lending


Sources & further analysis#

Reproductions & code

Alerts & third-party analyses

  • 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.