P2P and gossip
Message floods on consensus channels, peer-pool pollution, discovery reflection, gossip control messages that panic the process.
NR-2026-007NR-2026-029NR-2026-062
Penetration testing · Decentralised operators
We publish how validators get taken down.
Let us try it on yours first.
Your contracts get audited. Your cloud gets a compliance scan. The node in between, its P2P port, its RPC, its handshake, its signer, is where an attacker knocks you off consensus, and almost nobody tests it. We do. We attack it with the techniques from our own published advisories, on a node you control, and hand you the fix.
61Public operator advisories, each with source citationsnullrabbit-advisories →121Attack techniques reproduced in our lab, of 523 cataloguedapi.nrdax.com →229Reproduced instances, technique by network stackapi.nrdax.com →39Network stacks with at least one lab reproductionapi.nrdax.com →
Figures as of 8 October 2026. Reproduced means a lab-fidelity, bundle-backed instance, not a citation.
[01]·The gap
The layer nobody audits.
A validator rarely falls over because of a contract bug. It falls over because one cheap, unauthenticated request makes the node do expensive work: decode, verify, scan, allocate. No exploit, no log line, no alert. Just a node that stops voting. Your existing testing was never built to look there.
| Generic infra pentest | Smart contract audit | NullRabbit | |
|---|---|---|---|
| Attacks the P2P and gossip ports | ○ | ○ | ● |
| Measures CPU spent before a peer authenticates | ○ | ○ | ● |
| Prices RPC amplification per request | ○ | ○ | ● |
| Tests your signer, admin and slashing-protection surface | ○ | ○ | ● |
| Maps the routing and hosting you share with other validators | ○ | ○ | ● |
| Reproduces against your exact client versions | ○ | ○ | ● |
| Port scan and TLS configuration | ● | ○ | ● |
| Contract logic and bytecode | ○ | ● | ○ |
[02]·Recent findings
What one request does.
Measured in our lab, published with the reproducer. These are the techniques we bring to your engagement.
7.6 GBin ~10 s, one TCP connectionIOTA's public gRPC server set no HTTP/2 stream cap. About 200 multiplexed calls took a lab node from 472 MB to 7.6 GB, then the kernel OOM-killer.NR-2026-003 →286.3%CPU, before any authenticationCometBFT runs the full SecretConnection handshake before it checks whether the peer is allowlisted. One lab host drove CPU from 2.6% to 286.3%.NR-2026-008 →41,636xresponse to request, by bytesA short multiGetObjects request against an IOTA node returned tens of thousands of times its own size. Aptos modules came in at roughly 10,000x.NR-2026-010 →37 bytesreturned, one pool thread held for the full scanAn Agave getProgramAccounts filter that matches nothing returns an empty array and pegs aggregate throughput flat at ~60 req/s.NR-2026-040 →10,001valid messages to purge everyoneInternet Computer replicas keyed the per-peer ingress quota to their own NodeId, so one sender trips it and every legitimate user's in-flight ingress is dropped.NR-2026-036 →22.21%of Solana stake, one provider's address spaceA single routing fault on 12 August 2026 pushed 30 validators out of consensus together. Independence turned out to be a billing arrangement.Research →
[03]·Scope
Six surfaces. All of them unauthenticated somewhere.
Each area below has at least one published advisory behind it. We test what we have already broken elsewhere.
Pre-auth transport
TLS, Noise, SecretConnection, BIP324 and RLPx handshakes that spend asymmetric crypto on strangers. QUIC and TLS half-open pinning.
NR-2026-008NR-2026-048NR-2026-049NR-2026-047
RPC and APIs
JSON-RPC, gRPC, GraphQL and WebSocket subscriptions. Response amplification, executor saturation, HTTP/2 stream abuse, allowlist bypass.
NR-2026-001NR-2026-023NR-2026-042NR-2026-054
Signer and control plane
Admin interfaces, remote signers, slashing protection, bridge signing ports, unauthenticated write paths into fork choice.
NR-2026-026NR-2026-027NR-2026-051NR-2026-063
State sync and bootstrap
Snapshot parsing, state sync services and chunk handling: the code that runs on untrusted input while you are trying to recover.
NR-2026-002NR-2026-011NR-2026-066
Topology and dependency
Hosting provider and ASN concentration, shared RPC dependencies, and which of your nodes go dark together when one upstream fails.
Solana route leak
[04]·Engagements
Three ways in.
Fleet Exposure Review
10 days · Price on requestThe outside view. What an attacker can reach, and what it costs you.
- →Your fleet mapped against the NRDAX technique registry.
- →Every exposed P2P, RPC and admin surface enumerated.
- →The highest-severity applicable techniques reproduced on a staging node.
- →Kernel-level detection rules you keep.
- →A prioritised remediation list.
Node Penetration Test
Scoped per stack · Price on requestYour client, your build, your config. Attacked properly.
- →Full technique sweep for your client and version.
- →Original research time on its unauthenticated surfaces.
- →Signer, sentry and admin-plane review.
- →Bundle-backed evidence for every finding.
- →Retest once you have remediated.
Correlated Failure Assessment
Scoped per fleet · Price on requestThe failure that takes out thirty validators at once.
- →Provider, ASN and region mapping for every node.
- →Shared dependencies: RPC, DNS, routing, relays.
- →Which single upstream fault takes the most stake offline.
- →Placement changes ranked by stake protected.
[05]·Method
Nothing goes in the report that we have not reproduced.
- 01ScopeClients, versions, topology, providers. We agree the targets and the rules of engagement in writing.
- 02MapYour exposed surface against 523 catalogued techniques. Anything that applies goes on the attack list.
- 03ReproduceOn a staging node or a replica we build from your versions. Never against mainnet without written consent.
- 04ProveResource traces, packet captures and a reproduction bundle for each finding. If it does not reproduce, it is not in the report.
- 05HardenConfig fixes first, then code. Detection rules for what cannot be fixed yet. Then we retest.
[06]·Deliverables
What you walk away with.
- ✓Findings report with severity, affected versions and measured resource impact.
- ✓Reproduction bundles your own team can re-run.
- ✓Kernel-level detection rules you keep.
- ✓Prioritised remediation, configuration before code.
- ✓Executive summary for delegators, customers and your board.
- ✓Upstream bugs taken to the client vendor, with you patched first.
[07]·Who it is for
Anyone whose node is the product.
- Validator operators
- Staking providers
- RPC and infrastructure providers
- Exchanges and custodians running nodes
- Foundations and client teams
[08]·Questions
Before you ask.
Will you take my validator offline?+
No. Reproduction runs on a staging node or a replica built from your versions. Testing against production happens only with written authorisation, rate-limited, in a window you choose.
Why not just run a bug bounty?+
Because most of this class is out of scope. Resource exhaustion on unauthenticated surfaces is routinely vendor-declared out-of-scope for bounty and embargo, which is why our advisories are public. Nobody is paid to find it, so it stays on your node.
Do you publish what you find?+
Your fleet, your configuration and your report stay confidential. If a finding is a bug in the client software itself, we take it to the vendor and agree timing with you so you are patched first.
Which networks do you cover?+
Every stack in the NRDAX registry, 39 with lab reproductions today, from Ethereum execution and beacon nodes to Solana, Cosmos, Sui, IOTA, Cardano, Bitcoin and the Internet Computer. New stacks by arrangement.
How do I know a finding is real?+
Every finding ships with the evidence to re-run it. Our public record includes the misses: three advisories have been withdrawn in the open when they did not hold up. How we verify a finding.
[09]·Contact
Someone is going to test your nodes.
Pick who.
Tell us which networks you run, which clients, and how many nodes. We come back with a scope and a date.
[email protected]