How Cashio Lost $48M to a Fake Account Chain: The Infinite Mint Dissected

Cashio was a Solana-based protocol that let users deposit Saber LP tokens as collateral and mint CASH, a dollar-pegged stablecoin. The design was straightforward: lock real collateral (USDC-USDT LP tokens, for example), mint synthetic dollars against it. The collateral accounting ran through a hierarchy of on-chain accounts - a root 'glow' account, a 'bsaber_swap' account representing the Saber pool, an 'arrow' account representing the LP position, and a 'bank' account holding the deposited tokens.

The attacker's insight was that Cashio never verified who actually owned the top of that chain. They created a fake root account - a fresh keypair with data structured to look like a valid Cashio glow account - and then built a full chain of fake accounts beneath it, each one pointing to the next. When the mint instruction ran its validation, it walked down the chain comparing each account to the one above it. Every comparison checked out, because all the accounts were the attacker's own, crafted to reference each other correctly.

The mint logic then accepted the attacker-supplied token account as valid collateral and minted 2 billion CASH. The attacker sold into Saber pools, extracted 10.8M UST and 16.4M USDC directly, then swapped the remaining CASH for another 8.6M UST and 17M USDC. The full haul was bridged to Ethereum and converted to over 16,000 ETH - roughly $48M at the time. The attacker left an on-chain message claiming accounts with less than $100k had been refunded and the rest would go to charity. Whether that was true or a distraction, most of the funds were never recovered.

The technical root cause is a failure to verify that key accounts are owned by the expected on-chain programs. On Solana, every account has an owner field set by the runtime - it is the program ID of whichever program created and manages that account. When your program receives an account as an instruction argument, the account's owner field tells you who controls its data. If you do not check it, anyone can pass you an account with arbitrary data that merely looks like the right shape.

Cashio's mint instruction accepted a saber_swap account (representing the Saber AMM pool) and an arrow account (representing the LP position). It validated that the arrow's fields referenced the saber_swap account, and that the saber_swap's fields referenced the top-level glow account. But it never checked that saber_swap.owner == saber_program_id or that arrow.owner == cashio_program_id. It also never verified the .mint field on the LP token account - the field that identifies which token type you are actually depositing.

The result: a chain of locally-consistent but globally-rootless account relationships. The attacker created accounts where every cross-reference was internally valid - each fake account pointed at the fake account above it - but none of them were owned by the expected programs. Cashio's validator walked the chain, saw consistent references, and gave the green light.

Step 1: The attacker generated a fresh keypair and wrote data into it shaped like a valid Cashio glow account. Because this was a new account with no program owner enforced, they could write whatever bytes they wanted.

Step 2: They created a fake saber_swap account with its authority field set to the fake glow account's public key, and a fake arrow account with its saber_swap field set to the fake saber_swap's public key.

Step 3: They created a fake bank account pointing at the fake arrow, and a real (or throwaway) token account for their deposit.

Step 4: They called Cashio's mint instruction, passing the entire fake chain. The contract's validation walked from arrow -> saber_swap -> glow, confirming each account referenced the previous one. All references matched. The .mint field on the LP token account was never read.

Step 5: The mint instruction credited 2 billion CASH to the attacker's token account.

Step 6: The attacker swapped CASH across Saber pools over multiple transactions, extracting real stablecoins. They bridged via Wormhole to Ethereum and sold into ETH.

Total elapsed time from first exploit transaction to exit: under two hours. The entire attack required no flash loans, no price manipulation, and no MEV - just a chain of hand-crafted accounts and one program that trusted the data it was given.

Anchor's account types enforce ownership and structural constraints at deserialization time, before your instruction handler runs a single line of business logic. When you declare an account as Account<T>, Anchor checks two things automatically: (1) the account is owned by the current program (or the program you specify), and (2) the account's data can be deserialized into type T. If either check fails, the transaction is rejected before your code executes.

For cross-program accounts - like Saber's pool state - you use Program<T> or a CPI account wrapper that verifies the owner matches the expected program ID. For relationships between accounts (e.g., an arrow must belong to a specific saber_swap), you use has_one constraints or explicit constraint expressions.

The corrected pattern for Cashio's account validation would look something like the code block below. The critical additions are: verifying saber_swap is owned by the Saber program ID, verifying arrow is owned by the Cashio program, and enforcing that arrow.saber_swap == saber_swap.key() and arrow.mint == collateral_mint.key() via has_one and constraint attributes. These are not optional hygiene checks - they are the security model.

The Cashio hack distills into a single lesson: local consistency is not global validity. A chain of accounts that all reference each other correctly means nothing if the chain's root is not anchored to a trusted authority. Every account in an instruction must be verified against a known, trusted reference - not just against the other accounts you were handed in the same call.

Four concrete things to apply in every Solana program you write:

1. Owner checks are mandatory, not optional. If an account is supposed to be a Saber pool, verify its owner is the Saber program ID. If it is supposed to be your own state account, verify owner == program_id. Use Anchor's Account<T> and Program<T> wrappers - they do this automatically.

2. Validate every field that feeds into a security decision. Cashio did not check the .mint field of the LP token account. That missing check was enough. If a field determines whether a deposit is valid, that field must be verified against an on-chain authority, not just read and trusted.

3. Trace every account chain to a verified root. Draw the dependency graph of your accounts. Follow each chain until you reach an account whose authority you can verify independently - typically a program-derived address (PDA) that only your program can create, or an account whose owner is a known program ID. If any chain terminates in an attacker-supplied account, you have a problem.

4. Use PDAs for protocol state where possible. Program-derived addresses cannot be spoofed because their derivation requires your program ID. An attacker cannot create a valid PDA for your program without executing your program's PDA creation logic. For core protocol accounts (the glow account in Cashio's case), PDA derivation would have made spoofing structurally impossible.

The cost of adding these checks is a few extra Anchor attributes and a constraints block. The cost of skipping them can be eight figures.