cAdvisor: 134,520 pages name it, 13,948 answer on 8080, and no fingerprint exists to check against

cAdvisor is the container resource monitor that ships next to Kubernetes and gets installed by hand everywhere else. Its README is short and direct: it runs "in the background" with a web interface on port 8080, and it exposes resource usage and performance characteristics for the containers on the host.

The measurements

Four queries on 2026-10-26, one result page each, totals only:

• title="cAdvisor" returned 134,520 matching assets.
• title=="cAdvisor" returned 0 matching assets.
• app="cAdvisor" returned 0 matching assets.
• title="cAdvisor" && port="8080" returned 13,948 matching assets.

The pair of zeros is the finding that shapes everything else. cAdvisor is a service with no navigable product page: it answers an HTTP API and serves a small interface, and its title is not exactly the string a strict comparison expects. A fingerprint database has nothing to classify either, so both the strict title and the application query return nothing while a loose title match finds 134,520 assets.

What the monitor knows

cAdvisor's own documentation describes its data model: for each container it keeps resource isolation parameters, historical resource usage, histograms, and network statistics, exported per container and machine-wide. On a normal host that means container names, image names and digests, mounted volume paths, labels, and the process tree in whatever form it exposes.

None of it is exotic, and all of it is inventory. A list of image names and volume paths on a host is exactly what someone needs in order to know where the data lives, and the labels usually carry the deployment's own naming scheme.

There is a second detail in the runtime options: profiling is available through the web interface at host:port/debug/pprof/, controlled by a flag documented as --profiling=false. A deployment that leaves the default alone is a deployment whose debug endpoint is reachable wherever the monitor is. Debug endpoints have a long history of being more revealing than the service they sit beside.

Why 13,948 is the number to use

The 10 percent intersection matters for a practical reason. A loose title match can pick up documentation pages, dashboards that mention cAdvisor, and monitoring consoles that reference it. The port-scoped query removes most of those, because a documentation page that mentions cAdvisor is not usually served on port 8080 by the same host that runs the monitor.

So 13,948 assets are the ones where a page named the product and the host answered on the port the product uses. That is a smaller and much more defensible population: hosts where a container monitor is listening on a conventional, well-known port.

Whether those listeners are reachable beyond the scanner's vantage point is a separate question, and the index cannot answer it. What the number supports is prevalence and convention, not exploitability.

The operational question

cAdvisor is almost always installed for a legitimate reason: somebody needed container metrics and Prometheus was pointed at the endpoint. That makes it a component with an owner inside the platform team and no owner in the security review, which is the pattern behind most of the exposure in observability tooling.

Four checks belong in the review.

Does the listener bind to a private interface, or to all interfaces? A Prometheus scrape comes from one or two addresses, so an any-address binding buys nothing but exposure.

Is there authentication in front of it? cAdvisor is generally deployed without its own authentication because it is considered internal. Internal means the binding, not the intent.

Is the profiling endpoint enabled on an internal-only port or on the same listener as the metrics? The second arrangement puts a debug interface on the same path space as the scrape endpoint.

Does the monitor see containers it should not? A host that runs both customer workloads and platform services gives one monitor visibility into both, and the metrics carry names.

Detection and inventory

The inventory record should say: host, binding address, port, whether profiling is enabled, and which scrape source is authorised. That is five fields, and it converts the asset from "some monitoring thing" into a component with a policy.

For detection, the useful signals are a new client address hitting the metrics endpoint and a request to the debug path. Both are ordinary HTTP logs on the listener, and both are usually dropped because nobody thought the port was worth logging.

Method and limits

Queries ran on 2026-10-26 with sub_type=all and pagesize=1; only totals were reported. The zero application fingerprint is a statement about classification, not about absence, and this report treats it that way. No attempt was made to infer versions or authentication state from the index, because the index does not carry them.

The one conclusion worth repeating is that an asset can be extremely common and completely unclassified. A tool without a title and without a fingerprint is invisible to a review that only asks what software has a signature.

References

• ZoomEye observation, title="cAdvisor", recorded 2026-10-26: https://www.zoomeye.ai/searchResult?q=dGl0bGU9ImNBZHZpc29yIg%3D%3D
• ZoomEye observation, title="cAdvisor" && port="8080": https://www.zoomeye.ai/searchResult?q=dGl0bGU9ImNBZHZpc29yIiAmJiBwb3J0PSI4MDgwIg%3D%3D
• cAdvisor source repository and README: https://github.com/google/cadvisor
• cAdvisor runtime options, including the profiling flag and default port: https://github.com/google/cadvisor/blob/master/docs/runtime_options.md