Liquid Unstaker - The Vault

The liquid_unstake_lst function is designed to allow users to burn Liquid Staking Tokens (LST) and unstake SOL from a stake pool without waiting for the corresponding locking period of the staking account.

In order to do this, the liquid_unstake_lst entry point requires the user to first approve the pool to burn their LST tokens via the SPL Token approve instruction. This approval is currently being executed and granted on the client side (The Vault Web App) and persists until manually revoked or fully used.

However, the liquid_unstake_lst function does not verify on chain that the caller is the owner of the user_lst_account, meaning that as long as an approval exists, anyone can execute the function on behalf of the user, burn their LST tokens, and withdraw unstaked SOL to an attacker-controlled address.

Since the function does not require a signer for user_lst_account, an attacker can construct a transaction referencing a victim’s token account, and as long as the pool has an active approval, the attacker can unstake and redirect the SOL withdrawal without the victim’s consent. This issue arises due to the permissionless nature of the entry point, combined with the persistence of SPL Token approvals, which remain valid until explicitly revoked. While the impact is mitigated by the requirement for prior user approval, many users may unknowingly leave approvals active, exposing them to unauthorized unstaking and loss of funds.

The lack of checking of the signature of the owner of the user_lst_account account can be seen in the snippet below:

src/instructions/liquid_unstake_lst.rs:

pub struct LiquidUnstakeLst<'info> {
    #[account(
        mut,
        seeds = [b"pool", pool.authority.key().as_ref()],
        bump = pool.bump,
        has_one = sol_vault,
        has_one = manager_fee_account
    )]
    pub pool: Account<'info, Pool>,
    pub payer: Signer<'info>,
    #[account(mut)]
    pub user_lst_account: Account<'info, TokenAccount>,
    /// CHECK: The account containing the naked SOL managed by the liquid unstake pool
    #[account(mut,
        seeds = [b"sol_vault", pool.key().as_ref()],
        bump = pool.sol_vault_bump
    )]
    pub sol_vault: AccountInfo<'info>,
    /// CHECK: The user's SOL account to receive the unstaked SOL
    #[account(mut)]
    pub user_sol_account: AccountInfo<'info>,
    /// CHECK: The liquid unstake pool manager fee account that will receive the manager fee
    #[account(mut)]
    pub manager_fee_account: AccountInfo<'info>,

The permissionless nature of the liquid_unstake_lst function, combined with the need for users to grant token approval to the pool, allows any caller to execute the unstake process on behalf of any user, provided an active approval exists. Since the function does not enforce a signer check on user_lst_account, an attacker can submit a transaction specifying a victim’s LST token account for unstaking while redirecting the unstaked SOL to their own controlled account by supplying a user_sol_account they own. The attacker effectively exploits the lack of ownership verification in the unstake process, leveraging the SPL Token approval mechanism to burn the victim’s LST tokens and withdraw the corresponding SOL to an address under their control, enabling unauthorized asset extraction without requiring access to the victim’s private key.

To prevent unauthorized unstaking, the function should introduce an unstaker_user account as a signer and enforce that:

• user_lst_account is owned by unstaker_user

• user_sol_account is owned by unstaker_user

This ensures that only the rightful owner of the LST tokens can initiate the unstake process, as shown in the snippet below:

src/instructions/liquid_unstake_lst.rs

pub struct LiquidUnstakeLst<'info> {
    #[account(
        mut,
        seeds = [b"pool", pool.authority.key().as_ref()],
        bump = pool.bump,
        has_one = sol_vault,
        has_one = manager_fee_account
    )]
    pub pool: Account<'info, Pool>,

    #[account(signer)]
    pub unstaker_user: Signer<'info>,

    #[account(mut,
        constraint = user_lst_account.owner == unstaker_user.key() @ LiquidUnstakerErrorCode::InvalidUserLstOwner
    )]
    pub user_lst_account: Account<'info, TokenAccount>,

    /// CHECK: The account containing the naked SOL managed by the liquid unstake pool
    #[account(mut,
        seeds = [b"sol_vault", pool.key().as_ref()],
        bump = pool.sol_vault_bump
    )]
    pub sol_vault: AccountInfo<'info>,

    /// CHECK: The user's SOL account to receive the unstaked SOL
    #[account(mut,
        constraint = user_sol_account.owner == unstaker_user.key() @ LiquidUnstakerErrorCode::InvalidUserSolOwner
    )]
    pub user_sol_account: AccountInfo<'info>,

    /// CHECK: The liquid unstake pool manager fee account that will receive the manager fee
    #[account(mut)]
    pub manager_fee_account: AccountInfo<'info>,
}

SOLVED: The The Vault team solved the issue by requiring the owner of he usr_lst_account to be a signer of the instruction, and passing it as a user_transfer_authority for the withdraw_stake instruction.

The deposit_sol entry point is responsible for allowing users to deposit SOL into the liquidity pool. In return, users receive LP tokens proportional to their deposit based on the current pool exchange rate.

This liquidity pool is designed to allow liquidity providers to supply SOL so that other users can unstake their Solana staking positions instantly without waiting for the normal unlock period, in exchange for a fee.

The function includes a validation to ensure that deposits do not exceed the vault’s SOL cap:

programs/liquid-unstaker/src/instructions/deposit_sol.rs

    pub fn deposit(ctx: Context<DepositSol>, amount: u64) -> Result<()> {

        let total_sol_in_vault_plus_pending = 
            ctx.accounts.pool.sol_vault_lamports
            + ctx.accounts.pool.total_deactivating_stake;

        if total_sol_in_vault_plus_pending + amount >= ctx.accounts.pool.sol_vault_lamports_cap {
            return Err(LiquidUnstakerErrorCode::SolVaultLamportsCapReached.into());
        }

        // Mint LP tokens to the user according to the current "exchange rate"
        let lp_tokens_to_mint = lp_math::calculate_tokens_to_mint(
            ctx.accounts.pool.total_lp_tokens,
            amount,
            total_sol_in_vault_plus_pending,
        )?;

        if lp_tokens_to_mint == 0 {
            return Err(LiquidUnstakerErrorCode::LpTokensToMintIsZero.into());
        }

        // Transfer SOL from user to sol_vault
        invoke(
            &system_instruction::transfer(
                &ctx.accounts.user.key(),
                &ctx.accounts.sol_vault.key(),
                amount,
            ),
            &[
                ctx.accounts.user.to_account_info(),
                ctx.accounts.sol_vault.clone(),
                ctx.accounts.system_program.to_account_info(),
            ],
        )?;

        // Mint LP tokens to user
        let cpi_accounts = MintTo {
            mint: ctx.accounts.lp_mint.to_account_info(),
            to: ctx.accounts.user_lp_account.to_account_info(),
            authority: ctx.accounts.pool.to_account_info(),
        };
        let cpi_program = ctx.accounts.token_program.to_account_info();

        token::mint_to(
            CpiContext::new_with_signer(cpi_program, cpi_accounts, pool_seeds!(ctx.accounts.pool.authority, ctx.accounts.pool.bump)),
            lp_tokens_to_mint,
        )?;

        let pool = &mut ctx.accounts.pool;
    
        // Update pool state
        pool.deposit_liquidity_provider(amount)?;

        pool.total_lp_tokens = pool
            .total_lp_tokens
            .checked_add(lp_tokens_to_mint)
            .ok_or(LiquidUnstakerErrorCode::MathOverflow)?;
   
        Ok(())

    }

However, since the validation uses greater than or equal to (>=), the cap can never be fully reached, as any deposit that would bring the total exactly to the cap will be rejected.

Consider changing the validation to be strictly greater than, as shown in the snippet below:

if total_sol_in_vault_plus_pending + amount > ctx.accounts.pool.sol_vault_lamports_cap {
    return Err(LiquidUnstakerErrorCode::SolVaultLamportsCapReached.into());
}

SOLVED: The The Vault team solved the issue by correcting the inequality to be strictly bigger than.

The StakeAccountInfo struct, which is used to store information about unstaked staking accounts, and it includes a boolean field is_active, as shown in the snippet below:

programs/liquid-unstaker/src/state.rs

#[account]
pub struct StakeAccountInfo {
    // The stake account that has been unstaked and is now owned by the pool
    pub stake_account: Pubkey,
    // The pool that manages the stake account
    pub pool: Pubkey,
    // The amount of lamports in the stake account when it was unstaked
    pub stake_lamports: u64,
    // If the stake account is active or not
    pub is_active: bool,
}

This boolean is never used in the program:

• When a StakeAccountInfo account is created, is_active is always set to true.

• When the update function withdraws the stake, both the stake account and StakeAccountInfo are closed, making the boolean unnecessary.

• The update function includes a check for is_active, but since the account is always closed after unstaking, this check has no effect.

Consider removing the is_active field from the StakeAccountInfo, along with any references to it in the program to reduce unnecessary state tracking and code complexity.

SOLVED: The The Vault team solved the issue by deleting the mentioned code and references to the is_active field.