What We Found Scanning the Sui Validator Network

We've been scanning blockchain validator networks for a while now. Today we're publishing the first version of our public exposure dashboard, starting with Sui. This post explains what we found, how we found it, and why it matters.

How TRS Works

Most network scanners do the same thing: connect to a port, read what the service announces about itself, and move on. Banner grabs. It's fine for discovery but it tells you what a service wants you to know, not what it actually is.

Temporal Resonance Scanning works differently. TRS probes services and measures how they respond over time — sub-millisecond response signatures collected via XDP at the kernel level. The timing patterns are distinctive. A PostgreSQL instance running on port 5432 responds differently from a honeypot on port 5432, even if the banner says the same thing. A misconfigured Redis behaves differently from a properly firewalled one. Services leave fingerprints in time, not just in banners.

This matters because validators frequently run non-standard configurations. Services get moved to non-default ports. Firewalls block banner connections but leave timing responses intact. TRS finds things that conventional scanners miss, and it classifies them without relying on the service to cooperate.

The result is a behavioural fingerprint of each host — a timing signature we can compare across the network, cluster by similarity, and use to identify anomalies. It's not what the host says it is. It's what it does.

What We Found on Sui

We scanned 138 validators across 20 countries. Here's what came back.

41% of the network has SSH exposed. 57 validators are reachable on port 22 from the public internet. That's not necessarily a misconfiguration on its own — operators need remote access — but it's worth knowing, and it's worth knowing what version they're running. Of those 57, we identified version strings on 49. OpenSSH 8.0p1 is the most common.

57 validators have unexpected services. These are services that have no business being internet-facing on a validator node. The list includes things you'd expect to find on a misconfigured server: Redis with no authentication, PostgreSQL exposed to the internet, Elasticsearch without a firewall rule, Grafana on port 3000, Docker API on 2375, Memcached, MongoDB, kubelet. These aren't edge cases — they're spread across a meaningful fraction of the network.

9 CVEs confirmed across 4 hosts, including 2 rated critical at CVSS 9.8. We're not publishing the specific host identifiers or IP addresses — we're working through responsible disclosure first. But the vulnerabilities exist, they're confirmed, and they're on validator infrastructure.

21 distinct infrastructure stacks. This is the fingerprint diversity figure — the number of unique service signature clusters we identified. Validators running the same software tend to cluster together. The outliers are often the most interesting: unusual port combinations, unexpected latency profiles, timing anomalies that suggest something non-standard is running.

The headline finding is the one we expected but hoped wouldn't be as pronounced: a substantial portion of the Sui validator network has exposed services that operators either don't know about or haven't prioritised. This isn't a Sui-specific problem. We expect similar numbers when we scan Ethereum, Solana, and Cosmos. Validators are running production infrastructure under significant operational pressure, and security hygiene is often the thing that slips.

Why This Matters for DeFi

Validator nodes are the infrastructure that DeFi runs on. If a validator is compromised — through an exposed Redis instance, an unpatched SSH daemon, an unauthenticated Docker API — the consequences extend beyond that operator. Validators sign blocks. They participate in consensus. At sufficient scale, compromised validators affect the integrity of the network itself.

This isn't a theoretical concern. The Byzantine fault tolerance thresholds that blockchains rely on assume that a certain proportion of validators are behaving honestly. If a subset of validators are running exposed infrastructure, the attack surface for reaching those thresholds is larger than it should be.

The exposure data is the first part of the problem. The second part is the response time.

When a novel attack is in progress — a zero-day being exploited against an exposed service, a connection pattern that doesn't match any known signature — the current defensive posture for most operators is: receive an alert, triage it, escalate, approve a response, execute. That process takes minutes to hours. The attack takes seconds.

This is why we're building Guard.

Guard and Earned Autonomy

Guard is NullRabbit's kernel-level enforcement layer, built on XDP/eBPF. It operates at the same layer as the network stack — microsecond response times, no userspace round-trip, no queue. When something needs blocking, it gets blocked before it completes.

But Guard without judgment is just a system waiting to cause an outage. The governance framework matters as much as the technology.

We've published a paper on what we call earned autonomy — the framework for determining when a defensive system has demonstrated sufficient competence to act without human approval. The core idea is that authority should be granted based on evidence, not asserted by vendors or assumed by default. A system operates in shadow mode first, logging what it would have blocked. That counterfactual record is reviewed. Accuracy thresholds are set. Only when those thresholds are consistently met does the system receive enforcement authority.

Trust by evidence, not trust by assertion.

The exposure dashboard is the first public-facing part of this work. It shows the scale of the problem. Guard and the earned autonomy framework are how we propose to address it.

What's Next

The dashboard is live at nullrabbit.ai/exposure. We're updating it as new scan data comes in. Sui is first; Ethereum, Solana, and Cosmos are next — each with their own threat profiles and validator populations.

If you operate a validator and want to know your specific exposure, get in touch. If you want to be excluded from future scans, there's a link at the bottom of the dashboard.

The data exists. The infrastructure to act on it is being built. The machines are already at war — the question is whether we give our side permission to fight.

---

NullRabbit Labs — nullrabbit.ai Limpet TRS — github.com/nullrabbitlabs