Hubble answers 1,103 times by title, five times as an application, and 37,258 times in page bodies
A product name that also belongs to a telescope creates a measurement problem no query can fix. Hubble is the observability layer that ships with Cilium, and it is also the name of a space telescope, a film, and several unrelated services. A set of ZoomEye measurements taken on 26 October 2026 shows how far apart the three standard counts can land, and why the smallest number here is the one that describes the software.
The three counts
Each query ran against ZoomEye with sub_type="all" and pagesize=1, so every total describes matched assets rather than retrieved records.
| Query | Matches |
| --- | ---: |
| app="Hubble" | 5 |
| title="Hubble" | 1,103 |
| http.body="Hubble" | 37,258 |
| port=12000 | 2,681,323 |
The ordering is inverted from the usual pattern. Normally the fingerprint outnumbers the title, and the title outnumbers nothing in particular. Here the fingerprint is essentially empty at five, while the body count runs to five digits.
Why the fingerprint is nearly empty
An application fingerprint is not a string match. It is a rule that recognises a product from characteristics of its response, and a rule has to be written before it can match. Cilium's Hubble exposes a gRPC service and, in its UI form, a small web interface that a cluster operator enables deliberately. Neither surface is common on the public internet, and neither has the stable response shape that fingerprint authors tend to target.
Five matches is therefore a statement about the fingerprint set and about the population, in that order. It is not a count of Hubble deployments, which are mostly internal to Kubernetes clusters and reachable through port forwarding or an internal service address rather than a public one.
What the 37,258 body matches actually contain
The body count is where naming ambiguity dominates. The string "Hubble" appears in documentation about Cilium, in astronomy sites, in marketing pages, in blog indexes, and in any response that mentions the telescope. A body match records that the word was present; it records nothing about the responding system.
port=12000 illustrates the same trap in numeric form. The port is used by Hubble's UI in some configurations and by a long list of unrelated services in others. A count of 2.68 million for a bare port query is a measurement of the port's popularity, not of the product. Any published number derived from it would be indefensible, and that is the reason the query is listed here next to its true meaning rather than used as a headline.
What Hubble is worth measuring
The value of the tool is in what it sees. Hubble collects flow-level data between workloads: source and destination identity, verdicts from network policy, DNS queries, and HTTP status codes for the requests it can parse. That dataset answers the question an incident responder asks first — which workload talked to which other workload, and was it allowed.
The dataset is also a map of internal topology. Service names, namespaces, pod identities, and the destinations that workloads actually reach appear in flow records. A reachable Hubble interface is not a metrics endpoint; it is a live view of cluster east-west traffic.
Cilium's documentation positions Hubble as an observability component with its own UI and CLI, and the security-relevant detail is that the flow data is only as sensitive as the cluster is interesting. In a cluster that holds customer data, a readable flow record describes where that data lives and how it moves.
The realistic exposure and the controls
The realistic exposure for Hubble is not a public port. It is an operator who enabled the UI and exposed it through the same ingress as application traffic, or a debugging session that left a port forward running on a jump host. Both are configuration decisions with short-term convenience and no obvious failure signal.
The controls are correspondingly mundane. Keep the UI on an internal service address and reach it through an authenticated proxy. Treat the flow data as production telemetry with the retention and access rules that implies. And check the network policy verdicts that Hubble reports, because a cluster where every flow is allowed has an observability tool that documents its own lack of segmentation.
What these numbers support
The honest statement is narrow. On 26 October 2026, ZoomEye matched five assets against its Hubble application fingerprint, 1,103 pages with the product name in the title, and 37,258 responses containing the string somewhere in the body. The first number reflects a small public population and an even smaller fingerprint set. The last two reflect a word that many unrelated systems use.
That distinction is the whole methodological point. A count is only useful when the reader knows what the query tested, and a product with a common name produces the widest gap between a number and its meaning.
References
- Cilium documentation, Hubble observability: https://docs.cilium.io/en/stable/observability/hubble/
- Hubble source repository: https://github.com/cilium/hubble
- ZoomEye search platform: https://www.zoomeye.ai/
Measurement note
Queries: app="Hubble", title="Hubble", http.body="Hubble", port=12000. Executed 26 October 2026, sub_type="all", pagesize=1, global scope. Counts describe matching assets, not confirmed vulnerabilities or exploitation.
