Fingerprinting the MCP Ecosystem: 311,846 Indexed Assets and the Problem of Unmanaged Tool Endpoints

The Model Context Protocol gave AI agents a standard way to call external tools. It also created a new class of network endpoint that most organizations have not added to their asset inventory. Measuring how many of these endpoints are visible from the internet is a first step toward managing them.

Why MCP endpoints are different

An MCP server is not a passive API. It is a process that holds credentials for the systems it reaches, exposes a set of callable operations to a model, and accepts instructions that may originate outside the trust boundary. When it is reachable over the network, three properties combine: it can act, it holds secrets, and it can be addressed by something other than its owner.

Two September 2026 developments illustrate the consequences. CVE-2026-59822 in LiteLLM allowed an unauthenticated caller to reach MCP tools through a gateway, and CISA added it to the Known Exploited Vulnerabilities catalog on 2 September 2026. Separately, security researchers published an analysis of 23 MCP ecosystem vulnerabilities disclosed over a 30-day window, identifying recurring root causes that included missing authentication on transport layers and absent Origin and Host validation.

What the measurement shows

A ZoomEye query for the MCP application fingerprint returns 311,846 indexed assets. This figure measures internet-visible assets identified by the fingerprint. It should be read with care for several reasons.

First, MCP is a protocol rather than a single product, so a fingerprint count aggregates many different implementations with very different security properties. Second, the figure does not distinguish between a development instance on a laptop and a production server holding cloud credentials. Third, an indexed asset is not necessarily an exposed one in the sense that matters; some may sit behind authentication that the fingerprint does not evaluate.

What the number does establish is that MCP endpoints are numerous and visible. A protocol that reached widespread adoption in roughly two years has produced a population of network services that is large enough to be found by automated scanning.

The recurring root causes

Published analysis of the September 2026 MCP vulnerability cluster identified four patterns.

Transport layers without authentication. Several implementations shipped with authentication disabled by default, on the assumption that the server would only ever be reached locally.

Missing Origin and Host validation. The MCP specification marks Origin validation as a requirement to prevent DNS rebinding, but implementations frequently omit it. A malicious web page can then use a victim's browser to reach a service listening on the local machine.

Tool parameters that reach host resources. Because invoking tools with model-supplied arguments is the intended function, an unvalidated parameter is equivalent to exposing a host resource to untrusted natural-language input.

Custom URL validators that can be bypassed. Hand-written validation logic frequently misses encodings or redirect behavior that the underlying library would have handled.

A management checklist

1. Inventory MCP servers the organization runs, including those started by individual developers on shared infrastructure.
2. Determine which are reachable from outside the host or the local network.
3. Confirm that authentication is enabled and that it fails closed.
4. Verify that Origin and Host validation is enabled where the transport supports it.
5. Review the tool set each server exposes and remove tools that are not needed.
6. Treat the credentials an MCP server can read as production credentials, and scope them accordingly.

Where ZoomEye fits

The measurement is useful precisely because MCP servers are often deployed outside formal change management. An external view answers whether a service that was intended to be local is in fact reachable. Repeating the query over time shows whether the exposed population is growing, which is a reasonable proxy for whether MCP deployments are being governed or simply accumulating.

References

• LiteLLM, GitHub Security Advisory GHSA-7488-6r32-c95q (CVE-2026-59822).
• CISA, Known Exploited Vulnerabilities Catalog, 2 September 2026 update.
• Published analysis of MCP ecosystem vulnerabilities disclosed between 25 August and 15 September 2026.
• ZoomEye measurement of the MCP application fingerprint, collected 20 September 2026.

Limitations

The exposure figure is a ZoomEye index count collected on 20 September 2026 using the app="MCP" fingerprint. MCP is a protocol implemented by many products, so this count aggregates heterogeneous implementations and does not indicate authentication state, exposure to a specific network, or whether any asset holds production credentials. It measures internet-visible, fingerprinted assets only. Index counts change over time.