Address Lookup Table Poisoning Remediation
How to fix unsafe Address Lookup Table usage by validating table authority and loaded addresses.
Remediating Address Lookup Table Poisoning
Overview
Related Detector: Address Lookup Table Poisoning
Address Lookup Table (ALT) poisoning occurs when a program uses addresses loaded from an ALT without verifying that the table was created by a trusted authority or that loaded addresses match expected values. The fix is to validate the ALT authority and verify every address loaded from the table before using it in critical operations.
Recommended Fix
Before (Vulnerable)
use solana_program::{account_info::AccountInfo, entrypoint::ProgramResult};
pub fn process_with_alt(accounts: &[AccountInfo]) -> ProgramResult {
let target = &accounts[0]; // Loaded from ALT -- no validation
// Uses unvalidated address in CPI
solana_program::program::invoke(
&build_instruction(target.key),
&[target.clone()],
)?;
Ok(())
}
After (Fixed)
use solana_program::{account_info::AccountInfo, entrypoint::ProgramResult, pubkey::Pubkey};
const EXPECTED_TARGET: Pubkey = /* known target address */;
pub fn process_with_alt(accounts: &[AccountInfo]) -> ProgramResult {
let target = &accounts[0];
// Validate loaded address matches expected value
if target.key != &EXPECTED_TARGET {
return Err(ProgramError::InvalidArgument);
}
solana_program::program::invoke(
&build_instruction(target.key),
&[target.clone()],
)?;
Ok(())
}
Alternative Mitigations
-
Whitelist approach: Maintain an on-chain whitelist of trusted ALT addresses. Validate the lookup table account key against this whitelist before processing.
-
PDA-based validation: Derive expected addresses using PDAs. Since PDA addresses are deterministic, compare ALT-loaded addresses against PDA derivations to confirm authenticity.
-
Owner-based validation: If the loaded accounts should be owned by a specific program, validate the owner field in addition to the address.
if target.owner != &expected_program_id {
return Err(ProgramError::IncorrectProgramId);
}
Common Mistakes
- Validating only the ALT account but not loaded addresses: Even if the ALT itself is trusted, an attacker who gains authority over the table can modify its contents. Always validate loaded addresses independently.
- Checking ALT authority without checking ALT ownership: The ALT account must be owned by the Address Lookup Table program. An attacker can create a fake account with a matching authority field.
- Assuming ALT immutability: ALTs can be extended (new addresses added) and deactivated. A trusted ALT today may contain attacker-injected addresses tomorrow if the authority key is compromised.
- Relying solely on transaction simulation: Off-chain simulation may pass with the correct ALT, but a front-running attacker can modify the table between simulation and execution.