NullRabbit
cohort.v1
← Back to Research
Research · May 21, 2026

Expensive work before authentication: the RPC pattern we keep finding

Simon Morley·2 min read

In December, Solana shrugged off a multi-terabit DDoS and kept making blocks. The big chains have learned to defend volume. What they haven't learned to defend is the opposite shape, and it's the one we keep finding.

A validator's RPC layer exists to be helpful to strangers. It parses, simulates, allocates, and serialises for anonymous callers before it has decided whether they were entitled to ask. The moment the cost of serving a request decouples from the cost of sending one, you have a problem that has nothing to do with bandwidth. One request that costs an attacker a fraction of a millisecond can cost the node hundreds. A handful per second, all valid-looking, sails under every rate limit and scrubbing rule you own, because those are tuned for packets per second. The traffic looks like a quiet client. The node falls over anyway.

It shows up in a few consistent forms. Compute amplification: a tiny request runs attacker-controlled work on a synchronous executor (simulateTransaction, devInspect and their equivalents), and one packet eats a core. Response amplification: no size cap, so "give me everything" returns everything, repeatedly. Auth bypass: a privileged route assumed to be bound to localhost, reachable from the internet. Our first public advisory, NR-2026-001, documents this pattern in the Agave RPC layer; it's a structural property of where the expensive work sits relative to the trust boundary, not a single bad line.

When we assess a client, the question we're actually asking is narrow: what work does this node do for a caller it has not yet authenticated, and is that work bounded? Everything in the class lives in the gap between "cheap to reject" and "expensive to evaluate."

The fix travels with the pattern because the pattern is architectural. Authenticate or authorise before the expensive work, not after. Put a hard wall-clock budget on each request that the caller cannot set, gas and self-reported limits don't count. Cap response size at the serialiser, not in business logic a code path will route around. Isolate the simulate path from block production so answering a stranger's hypothetical can't steal cycles from consensus.

If you operate a validator and you can't see per-request cost on your RPC surface, you can't defend this class, because you can't see it happening.

Simon Morley researches validator infrastructure security and is the founder of NullRabbit. About / contact.

validator-securityrpcdossolanaagaveeBPF

Related Posts