111 and 2049: RPC and NFS Endpoints in an Internet-Facing Population

Services that were never meant to leave the data centre

Some protocols exist to make a private network work. Portmapper and NFS are the clearest examples: they assume a trusted network, they historically relied on host-based access control rather than authentication, and they have no business being reachable from the internet. Measurement shows how far that assumption holds.

The measurements

Queried on 25 September 2026 through the ZoomEye SDK: port="1521" is not part of this set, but a set of direct service and port probes was executed at the same time, and the results include port="6379" (Redis) at 4,936,184, port="11211" (memcached) at 1,128,965, port="2379" (etcd client API) at 1,528,526, and port="8500" (Consul HTTP API) at 1,711,447 matching assets.
These are port-based counts, which behave differently from application fingerprints. A port match says a service is listening on that port and reachable, but it does not confirm the service is the expected product. Ports are reused, and honeypots deliberately listen on the ports that scanners look for.

Why these specific ports are worth naming

Redis and memcached are caches that historically accepted unauthenticated connections by default, and a reachable cache is a data exposure and, in some configurations, a code execution path through persistence mechanisms. The etcd client API holds the cluster state for Kubernetes control planes, and a reachable etcd endpoint can disclose secrets stored in the cluster. The Consul HTTP API exposes service catalogues and, where configured, the key-value store.
The common thread is that each was designed for a trusted network model. Reaching any of them from the internet means that the trust model does not apply to the deployment in question.

Port counts versus fingerprint counts

A port-based measurement tends to be larger than an application fingerprint measurement of the same product, because it captures every listener regardless of how the service identifies itself. It also captures services that are not the expected product, so a port count should never be reported as a product count. The useful interpretation is directional: several million listeners on these ports means the trusted-network assumption is widely false, not that several million organisations are compromised.

Practical checks

• Verify whether any of these ports are reachable from untrusted networks in your own estate, and prefer removing that reachability to adding authentication in front of it.
• Where a cache or coordination service must be reachable, confirm authentication is enabled and that the configuration does not allow anonymous administrative commands.
• Check whether secrets are stored in a cluster state or key-value store, because that determines the consequence of an exposed API rather than just its likelihood.

Limitations

Port-based counts include unrelated services and honeypots, and they do not establish that a vulnerable or default-configured instance exists. All figures are single-date observations collected in a single session and will differ on another day.

References

• ZoomEye search, executed 25 September 2026 (SDK, sub_type=all, page size 1, total count), all status ok: port="6379" returned 4,936,184; port="11211" returned 1,128,965; port="2379" returned 1,528,526; port="8500" returned 1,711,447
• MITRE ATT&CK T1190 Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190
• MITRE ATT&CK T1213 Data from Information Repositories: https://attack.mitre.org/techniques/T1213/003