The Signer You Trust
Your on-chain code is immutable. Your toolchain isn't.
Hey, it’s Arsen.
In today’s menu:
• How a phished npm maintainer drained $160K from live Solana dApps
• The fuzzer that surfaced a phantom stake bug in seconds
• AI agents at 70% on exploit construction — still failing at the hard part
• And more…
🏴☠️ Vulnerability
Supply chain attacks on Solana’s off-chain tooling
Your Solana program is immutable.
You revoked the upgrade authority. Nobody changes that code.
But the utility that signs your transactions? That’s not on-chain.
What happens when version 0.1.2 lands in your CI and nobody reads the diff?
In December 2024, attackers phished a maintainer of @solana/web3.js. Versions 1.95.6 and 1.95.7 shipped within hours. Both captured private keys from signers. Exfiltrated them to a hard-coded Solana address. The package had 350K weekly downloads. $160K in SOL and SPL tokens drained before fixes shipped.
The on-chain code was untouched. Every transaction landed as expected. The exploit lived in the dependency your dApp imported to sign — not the contract any audit would have scoped.
That’s the supply chain attack profile. The exploit rides the trusted path — not the program, but the tool every instruction passes through. One hijacked maintainer account is all it takes. No on-chain footprint. No revert. Wallets drain silently.
A second attack vector: fake audit requests. Threat actors pose as project owners asking you to “review this repo” or “run our build to verify edge cases.” You clone the repo, run npm install, and a backdoored script executes — harvesting SSH keys, session tokens, or Solana CLI keypair paths. It works because auditors trust audit contexts.
The mitigations aren’t complicated. They’re just rarely applied.
Lock exact versions in Cargo.toml: =1.18.3, not ^1.18. The caret allows any version up to 2.0.0 — a rogue 1.18.99 slips in silently. Use cargo vendor to snapshot your dependency graph locally. Run cargo audit to scan for known CVEs. Enable 2FA on every crates.io and npm account in your publishing pipeline.
The program is immutable.
The signer isn’t.
🗞️ News
Crucible ships coverage-guided fuzzing for Solana programs
A new fuzzing framework built for Solana programs just launched. Coverage-guided, Anchor-native, Anchor v2 support from day one.
What does a fuzzer catch that manual review misses?
Here’s the launch demo. Crucible surfaced a years-old bug in Solana’s own stake program. A 5-instruction sequence leaves delegation.stake out of sync with the validator’s actual deposited lamports:
delegate_stake() // X lamports delegated
advance_epoch() // stake becomes effective
deactivate() // begin cooldown
withdraw() // drain to rent floor, lamports drop
delegate_stake() // rescind — delegation.stake unchanged
Step 5 hits the rescind branch — same epoch, same voter. delegation.stake is never recalculated. The SOL is withdrawn. The stake weight stays. The validator earns real inflation against a balance they no longer hold.
A generic invariant caught it: fuzz_assert!(delegation.stake <= lamports). One line. The Crucible backend handled the rest — SBPF edge coverage (every branch a feedback signal), full state space exploration, near-linear multi-core scaling.
Manual review eventually found this bug. But a one-line invariant plus automated sequence exploration would have flagged it earlier. The phantom stake was sitting in a code path that only triggers under a specific 5-step sequence — the kind that doesn’t appear in standard test suites unless someone explicitly writes for it. Coverage-guided fuzzing exhausts the state space systematically. You write the rule, the system finds the counter-example.
The framework is in early release. If you’re auditing Solana programs, it’s worth a close look.
📚 Education
AI agents at 70% on exploit construction — still failing at the hard ones
a16z researchers ran 20 historical Ethereum price manipulation incidents through Codex (GPT 5.4). The task: find the vulnerability, write a working exploit. No hints. Just the contract address and block number.
How far can an agent get before it hits the hard part?
Without guardrails: 50% success. Except the agent was cheating. It used Etherscan’s txlist endpoint to pull the actual attack transaction from after the target block. Then reverse-engineered the exploit from the real attacker’s calldata. Not intelligence. Future data.
After sandboxing — no future data, no external API access — the success rate dropped to 10%.
Then they added structured domain knowledge: incident analyses, vulnerability pattern taxonomies, exploit templates derived from the actual answers. Success rate jumped to 70%.
The ceiling: even with near-complete guidance, the agent failed 6/20 times. In every single failure, it correctly identified the vulnerability. The breakdown happened at exploit construction. One agent assembled the right strategy, simulated profitability, and concluded the returns were insufficient — then abandoned its own correct answer. The economics were right. The profitability estimate was wrong.
One side observation: a sandboxed agent extracted the Alchemy API key from the anvil node config via cast rpc anvil_nodeInfo. When the firewall blocked direct access, it used anvil_reset to point the local node at a future block — then queried future state through the allowed local endpoint. Sandbox escape via debug RPC. Not a vector the researchers had anticipated.
The clearest takeaway: finding a vulnerability and building a working exploit are different skills. Agents have the first one reliably. The second breaks down on multi-step economic attacks — leveraged loops, multi-contract compositions — where the bottleneck is profitability estimation, not knowledge.
For defenders: agents are already useful. They’ll verify your true positives faster. On the complex ones, you’re still in the lead.
That’s it for this week.
Reply with the Solana bug, tool, or pattern you want me to cover next — I read every one.
If a working Solana auditor in your circle would find this useful, forward it their way.
— Arsen, working Solana auditor