81,570 Nexus Titles Against 33,873 Fingerprints: The Artefact Store Everything Builds From

Every deployment pipeline in an organisation passes through one or two artefact repositories. They hold the internal libraries, container images and release packages that other systems trust without inspection. That makes them a supply chain chokepoint, and it makes their internet exposure a question worth answering with numbers rather than assumptions.

Context and method

Counts from the ZoomEye index, 23 October 2026, sub_type=all, pagesize=1, page 1. Fingerprint matches, not installations.

Query	Total
app="Nexus Repository"	33,873
title="Nexus Repository Manager"	81,570

The title query reports 47,697 more matches, a gap of 141%. Some of that is wording, because the application fingerprint string and the title string are not the same token. Some is structural, because repositories fronted by a proxy may present the product title while failing the stricter fingerprint rule.

That is the first methodological point and it applies every time two numbers are quoted side by side: before comparing them, confirm both queries name the product the same way.

What a repository actually is

A Nexus instance serves three roles at once. It caches upstream registries, it hosts internal releases, and it is an authentication boundary deciding who may publish.

The third role is where risk concentrates. Publishing to an internal repository is a code execution primitive in every organisation that builds from it. An attacker able to push a version of an internal library other projects depend on does not need to compromise a build server; they need to become the build's input.

Read access carries a different risk. A repository that lists its contents tells an attacker the internal package names, the version history, and often the naming convention that reveals which team owns which component. That is reconnaissance no amount of external scanning would otherwise produce.

The version question

Nexus Repository has accumulated authentication and path traversal issues over the years, and the population in this index spans many versions. Here the usual caveat does the most work: a fingerprint match says the product answered, not which release it runs, and not whether anonymous access is permitted.

An instance with anonymous access enabled answers a browse request without authentication. The version may be current. The exposure is a configuration decision rather than a vulnerability, and it is the most common one found on these hosts.

A scoped query plan

1. Query both strings against your own address space and reconcile the difference. If the title count exceeds the fingerprint count, some of your repositories sit behind proxies and the inventory should record it.
2. For every match, establish whether anonymous browse is enabled. That single setting decides whether the index entry is informational or actionable.
3. Enumerate repositories that accept unauthenticated publish. This is rare, it is also catastrophic, and it is worth confirming off rather than assuming.
4. Check whether the host serves the admin interface on the same listener as the proxy endpoint. Separating them is the cheapest available mitigation and it is frequently skipped.
5. Record the version each instance reports, then compare against the vendor's current release rather than against an advisory summary.

Reading the number

81,570 title matches is a population large enough to be a supply chain concern in aggregate and small enough that a single organisation can usually enumerate its own in an afternoon. The gap to the fingerprint count is the reminder that the number you quote depends on the query you ran, and the query you ran depends on knowing how the product renders its identity.

References

• ZoomEye search: https://www.zoomeye.org/
• Sonatype Nexus Repository documentation: https://help.sonatype.com/repomanager3