Solana’s Application Growth Is a Security Stress Test: Where the Real Risks Sit

Solana’s low fees and fast confirmation times have pulled in trading bots, payment apps, NFT marketplaces, memecoin launchpads and a growing number of AI agents that hold their own keys.

Each new application adds code, keys and integrations that attackers can target. This guide breaks Solana security into five layers: on-chain programs, wallets and signing, tokens, off-chain infrastructure, and the developer supply chain.

For each layer you will get the failure modes that have caused real losses, practitioner checks you can run today, and MITRE ATT&CK mappings for the off-chain portions. Hypothetical examples are labelled as illustrative.

Why Solana security differs from other chains

Solana programs (its term for smart contracts) are stateless. All state lives in accounts that the caller passes into each instruction, and the runtime only guarantees a few things about those accounts.

The program itself must check that each account is owned by the expected program, that required parties actually signed, and that a derived address matches the expected seeds.

That design is fast, but it moves a lot of validation work onto developers. On EVM chains, a contract reads its own storage; on Solana, a contract that forgets an owner check may happily read attacker-crafted data from an account the attacker created.

Most high-impact Solana program bugs trace back to this gap between “an account was passed in” and “this is the account I expected”.

Two incidents that show the pattern

• Wormhole, February 2022: an attacker bypassed signature verification in the bridge’s Solana contracts and minted about 120,000 wrapped ETH, worth more than $324 million at the time, according to TRM Labs’ incident analysis (2022). Public post-mortems attribute it to the program accepting a spoofed system account that it did not validate.
• Mango Markets, October 2022: a trader manipulated the price of the platform’s own token and borrowed against the inflated collateral. No code was “broken”; the economic design trusted a thin market price.

On-chain program vulnerabilities

Audits of Solana programs keep finding the same families of bugs. Knowing them helps both developers writing programs and security teams reviewing protocols before treasury funds are deposited.

Bug class	What goes wrong	Typical fix
Missing owner check	Program trusts data in an account owned by another program or by the attacker	Verify account owner; Anchor’s typed Account does this automatically
Missing signer check	An “authority” account is accepted without its signature	Require Signer and compare it with the stored authority
Type confusion (account cosplay)	An account of one type is passed where another is expected	Check an 8-byte discriminator or equivalent type tag
Unvalidated PDA	Program derives or accepts an address without checking seeds and bump	Use canonical bumps and seed constraints
Arbitrary cross-program invocation	Program calls whatever program ID the caller supplied	Hard-code or check the target program ID
Arithmetic errors	Overflow or rounding in fee and share calculations	Checked math; enable overflow checks in release builds
Oracle and price trust	Collateral valued from a manipulable source	Use multiple oracles, confidence intervals, TWAPs and position limits

Example: Anchor constraints that close common gaps

#[derive(Accounts)]
pub struct Withdraw<‘info> {
    // Typed Account checks owner = this program and the discriminator
    #[account(
        mut,
        seeds = [b”vault”, owner.key().as_ref()],
        bump = vault.bump,
        has_one = owner            // vault.owner must equal the signer below
    )]
    pub vault: Account<‘info, Vault>,

    pub owner: Signer<‘info>,   // must have signed the transaction

    #[account(mut, token::authority = vault)]
    pub vault_tokens: Account<‘info, TokenAccount>,

    pub token_program: Program<‘info, Token>,  // pins the CPI target
}

The Anchor account constraints reference documents each of these attributes. Native Rust programs need the same checks written by hand, and reviewers should test each instruction with substituted, unsigned and duplicate accounts.

Upgrade authority is a key-management problem

Most Solana programs are deployed as upgradeable, which means whoever holds the upgrade authority key can replace the code.

Treat that key like a root CA key: hold it in a multisig with hardware signers, publish who the signers are, and consider making stable programs immutable.

Anyone can check the current authority with solana program show <PROGRAM_ID>, and verifiable builds let users confirm the deployed bytecode matches the published source.

Wallet drainers and signing abuse

Most users never lose funds to a program bug. They lose them by signing a transaction they did not understand.

Scam Sniffer’s 2024 report counted $494 million stolen by wallet drainers across chains from more than 300,000 addresses, a 67% rise in losses over 2023 (BleepingComputer summary, 2025).

Drainer kits are sold as a service, with affiliates handling traffic and operators taking a cut.

GBHackers has covered Inferno Drainer’s Discord-based phishing operation and a campaign that bought malicious Google and X ads to push wallet-drainer phishing sites.

Browser extensions are another route, including a Chrome extension that added hidden SOL fees to swap transactions.

Why Solana transactions are attractive to drainers

A single Solana transaction can bundle many instructions. One signature can transfer SOL, empty several SPL token accounts and hand token account authority to the attacker at the same time.

Wallets that simulate transactions and show the net balance change help, but users who click through warnings, or who sign raw messages that a site later replays, remain exposed.

The front end is part of the attack surface

A dApp’s web front end decides what transaction the wallet is asked to sign. Web skimming shows how that layer gets abused: in one campaign, attackers abused Google Tag Manager to inject card-skimming code into checkout pages.

Replace the card form with a “connect wallet” button and the same technique becomes a drainer, so dApp teams should apply Content Security Policy, Subresource Integrity, and change control to every third-party script and tag manager container.

Token and memecoin scams

Launchpads have made token creation nearly free, so scam tokens are common. The technical red flags are visible on-chain if you look.

A mint that still has an active mint authority can be inflated at will, and an active freeze authority lets the issuer freeze holders’ accounts so they cannot sell.

The Token-2022 program adds extensions that are useful for legitimate issuers but dangerous in the wrong hands.

A permanent delegate can move tokens out of any holder’s account, and transfer hooks run custom program logic on every transfer.

Exchanges, treasury teams and analysts should check these settings before listing or accepting a token.

Quick token due-diligence checklist

1. Run spl-token display <MINT> and confirm the mint authority and freeze authority are disabled or held by a known multisig.
2. Check whether the mint uses Token-2022 and list its extensions, especially permanent delegate, transfer hook and transfer fee.
3. Review holder concentration and whether liquidity pool tokens are burned or time-locked.
4. Verify the program behind any transfer hook and whether it is upgradeable.
5. Treat promotions that rely on urgency, airdrops requiring signatures, or “claim” sites with new domains as hostile until proven otherwise.

RPC, bots and off-chain infrastructure

Every Solana application relies on off-chain components: RPC endpoints, indexers, price feeds, keeper bots and backend signers. These are ordinary servers with ordinary weaknesses, and they often hold hot keys.

A paid RPC API key embedded in a public front end can be scraped and abused, and a manipulated or stale RPC response can make a bot act on a false view of chain state.

Endpoints that run trading bots or hold keys are prime targets for commodity malware.

Researchers recently tracked a revived StealC variant repackaged as a RAT to steal passwords and cryptocurrency wallets, and infostealers routinely search for keypair JSON files and browser wallet storage (ATT&CK T1552.001 Credentials in Files, T1555 Credentials from Password Stores).

AI agents with keys

Autonomous agents that trade or pay on a user’s behalf are an emerging risk. In traditional finance, major US banks have reportedly detected third-party AI agents accessing customer accounts using shared login credentials, which makes it hard to separate legitimate automation from account takeover.

On Solana the equivalent is an agent holding a raw keypair, so give agents dedicated wallets with spending limits, program allowlists and, where possible, multisig or session-key schemes rather than the user’s main key.

Developer supply chain attacks

The most direct path to Solana keys is often through the developer’s toolchain. In December 2024, a compromised publish account was used to release malicious versions 1.95.6 and 1.95.7 of @solana/web3.js, which exfiltrated private key material from applications that handled keys directly, such as bots and backends.

The advisory, tracked as CVE-2024-54134, says version 1.95.8 is clean and tells affected teams to rotate any suspect authority keys, including multisig and program authorities.

Copycat packages continue. GBHackers has reported the Solana FakeFix campaign of malicious npm and PyPI packages, an AI-generated npm package designed to drain Solana wallets, and npm packages that exfiltrated Solana private keys through Gmail.

The problem is not unique to crypto tooling: attackers compromised the LiteLLM PyPI package to steal API keys and cloud credentials, which shows how quickly a popular dependency becomes a credential harvester. These map to ATT&CK T1195.001 Compromise Software Dependencies and Development Tools.

Example check: were you exposed to the web3.js compromise?

# Search lockfiles across repositories for the malicious versions
grep -rEn ‘”@solana/web3.js”.*”1\.95\.(6|7)”|web3\.js@1\.95\.(6|7)’ \
  –include=package-lock.json –include=yarn.lock –include=pnpm-lock.yaml .

# Confirm what is actually installed in a build or container
npm ls @solana/web3.js

If either version appears in a lockfile, build log or container image built in that window, treat every key the application could read as compromised. Rotate it, move funds to new addresses, and review on-chain activity from the old keys.

A Solana security program for teams

Protocol teams, exchanges and enterprises adding Solana payments can organise controls with NIST CSF 2.0, using Govern for key custody policy, Protect for code and keys, and Detect and Respond for on-chain monitoring.

The table below is a starting point, not an exhaustive standard.

Layer	Minimum controls	Detection signal
Programs	Independent audit, fuzzing, Anchor constraints, multisig upgrade authority	Alerts on upgrade or SetAuthority instructions for your program IDs
Treasury and keys	Multisig with hardware signers, separate hot and cold wallets, spend limits	Outflows above threshold, new destination addresses
Front end	CSP, SRI, locked tag manager access, DNS and registrar lock	Unexpected script hashes, DNS record changes
Infrastructure	Secrets in a vault or HSM, private RPC keys server-side, EDR on bot hosts	Keypair file access, unusual outbound connections
Supply chain	Pinned lockfiles, package allowlists, delayed adoption of new releases, provenance checks	New dependency versions, install scripts with network calls

Illustrative incident runbook (hypothetical): hot wallet drain

1. Pause affected programs or bots if a pause authority exists, and revoke delegations where possible.
2. Move remaining funds from any wallet whose key may be exposed, using a clean machine and fresh keys.
3. Trace outflows and notify exchanges and stablecoin issuers that may be able to freeze stolen assets.
4. Collect host, CI and dependency evidence to find the key exposure path before redeploying.

Key takeaways

• Solana security depends heavily on account validation; owner, signer, PDA and program ID checks prevent most critical program bugs.
• Upgrade authorities and treasury keys belong in hardware-backed multisigs with published signers.
• Wallet drainers cause more user losses than program exploits, and dApp front ends are part of that attack surface.
• Check mint, freeze and Token-2022 extension authorities before trusting any token.
• The CVE-2024-54134 web3.js compromise shows that developer dependencies can expose production keys; pin, verify and rotate.

FAQ

Is Solana secure?

The core protocol has run for years with public scrutiny, but most losses happen above it: in programs with missing checks, in wallets that sign malicious transactions, and in compromised off-chain systems.

The security of a given Solana application depends on its code, key management and infrastructure.

How do Solana wallet drainers work?

A phishing site or malicious extension asks the user to sign a transaction that looks routine but contains instructions transferring tokens or authority to the attacker. Because one transaction can hold many instructions, a single approval can empty a wallet.

How can I check if a Solana token is a scam?

Inspect the mint for active mint or freeze authorities, check Token-2022 extensions such as permanent delegate or transfer hooks, and look at holder concentration and liquidity locks. Tools like spl-token display or a block explorer show these fields.

What was the Solana web3.js supply chain attack?

In December 2024, malicious versions 1.95.6 and 1.95.7 of the @solana/web3.js npm package were published from a compromised account and stole private keys from apps that handled keys directly. It is tracked as CVE-2024-54134 and fixed in 1.95.8.

What are the most common Solana smart contract vulnerabilities?

Missing owner and signer checks, account type confusion, unvalidated program derived addresses, arbitrary cross-program invocation, arithmetic errors and manipulable price oracles appear most often in audits and incident reviews.