Zipkin at 40 Titles and 562 Fingerprints: When the Signature Finds More Than the Name

Distributed tracing backends are usually described by what they help you debug. As an exposure subject they are interesting for a different reason: they receive a structured record of every request that flows through an instrumented system, which is a map of the application's internal calls.
Zipkin provides a compact illustration of a signature-versus-name divergence, in the direction where the signature finds more.

What was measured

Collected from ZoomEye AI on 2026-10-02:

• title="Zipkin" with sub_type="all": 40 matches.
• app="Zipkin" with sub_type="all": 562 matches.
• title="Zipkin" && port="9411" with sub_type="all": 0 matches. Counts are indexed-service observations at collection time and describe reachable assets rather than vulnerabilities.

Reading the divergence

The fingerprint finds fourteen times as many services as the title query, and the direction is the reverse of what a branded web application would produce.
Two factors explain it. First, Zipkin's user interface is a single-page application, and the page that a scanner retrieves on the query port is often not the page that carries the product name in its title; the title may be generic or may be set by the browser after the application loads. A response-body fingerprint does not depend on a title being present in the initial HTML.
Second, the tracing collector is commonly exposed as an ingestion endpoint rather than as a browsable interface. An ingestion endpoint receives spans over HTTP and returns a minimal acknowledgement. A scanner that fingerprints the response will match it; a scanner looking for a title will find nothing to match.
The zero on the intersection is consistent with both readings and should be treated as a query limitation rather than as a statement about the deployment of the query port. As with the other cases in this series, a zero on a port-intersection query does not establish that no service uses that port.

What a tracing backend holds

Zipkin stores spans. A span records a unit of work: the service that handled it, the operation name, the timing, and, depending on instrumentation, the tags and annotations attached to it.
The tags are the part that matters for a security assessment. Instrumentation is frequently configured to record HTTP headers, database statements, or the parameters of an outgoing call, because those are exactly the values an engineer needs when a request is slow or failing. In some configurations that means a tracing backend contains fragments of request data, including identifiers and, occasionally, credentials that were passed as parameters.
That is a description of what an instrumented deployment can record, not a claim about any of the counted instances. Whether a specific deployment records sensitive tags is a configuration decision that the measurement cannot see.

Why tracing backends get exposed

Tracing infrastructure is deployed by engineers for engineers, and it is often brought up quickly during an incident-response or performance exercise. The pattern that follows is familiar from other observability tools: the service is bound to all interfaces because that is the default, the query interface is left open because the team that uses it is small and trusted, and the exposure is never revisited because nothing broke.
The measurement's contribution is to turn that informal state into a number that can be compared against an inventory.

What operators should check

Is the tracing query interface reachable from outside the internal network, and if so, is it behind authentication?
Is the collector's ingestion endpoint reachable, and is it write-protected or rate-limited?
Which spans are recorded with tag data that could include request parameters or headers, and is the sampling configuration the one that was intended?
What is the retention period, since a tracing backend accumulates a detailed request history over time?

The method point

This case completes a set of examples in which a product's measurability depends on what it puts in its responses. A branded web interface is measurable by title. A middleware component with no page of its own is measurable by fingerprint and not by title. A tracing backend whose interface is a single-page application is measurable by fingerprint more reliably than by title, because the fingerprint does not require a name in the initial response.
The consistent practice across all of them is to state which field produced the number and what scope it was run in. A count without that context is not a measurement; it is a number that happens to be reproducible.

Where ZoomEye fits

The fingerprint field is the useful signal here, and the query is reproducible. Running it over time shows whether the tracing population is changing, and running it against an organisation's own address space answers the direct question of whether its own backend is indexed. Both are legitimate uses that do not require treating 562 as an exposure estimate.

What to take away

40 titles, 562 fingerprints and a zero on the port intersection. The fingerprint is the more reliable field because a single-page interface does not always put the product name in the initial HTML. Report the field with the number, and check the tag configuration on your own deployment rather than inferring it from a public count.

References

• ZoomEye AI, cyberspace search - counts collected 2026-10-02 with the queries stated above
• Zipkin, Zipkin documentation
• OpenTelemetry, OpenTelemetry documentation
• ZoomEye, search syntax reference