ZoomEye query counts 756,074 internet-reachable Mattermost hosts

A single fingerprint query on the internet scanning service ZoomEye matched 756,074 hosts running Mattermost, according to a measurement published on dev.to. The data was collected on 2 October 2026, and the count represents every server whose responses matched ZoomEye's application fingerprint for the open-source chat platform — a snapshot of how many self-hosted instances are reachable from the public internet.

How the count was taken

As the dev.to post explains, the number came from one ZoomEye query for the Mattermost application signature, run across all sub-types. It is a raw tally of fingerprint matches, so it captures any server that identifies itself as Mattermost, whether it is a large production deployment or a container someone started once and forgot.

The author places the figure alongside similarly large exposure counts for other self-hosted software such as Jupyter and Nextcloud. The shared cause, the post argues, is ease of deployment: an official container image plus straightforward setup documentation makes standing up a trial instance nearly free, and many of those trials remain publicly reachable.

What a reachable instance shows

The login endpoint generally reveals the platform and often the specific version, the post notes, and some deployments also leave metrics or health endpoints accessible, which can pin down the build more precisely. Because Mattermost supports self-registration unless administrators disable it, a login page featuring a sign-up link signals to any observer that they can register an account themselves.

That is significant because of what such servers contain. An organisation's Mattermost instance typically carries its day-to-day operational chatter — incident threads, credentials pasted in for convenience, attachments and references to internal systems.

What the total leaves out

The author is explicit about the limits of the measurement. The 756,074 figure says nothing about how many of those instances permit open registration, how many expose monitoring endpoints, or how many are throwaway development servers rather than live collaboration platforms. A fingerprint scan cannot distinguish an evaluation copy from production; those are properties of individual deployments.

Why these deployments slip through

According to the post, chat platforms occupy an awkward position in most organisations: they are viewed as productivity software rather than infrastructure, and they are frequently set up by an individual team instead of a central platform group. The consequence is that they can bypass the review processes that govern databases and identity services.

The credential exposure is concrete, the post adds. Mattermost integrations rely on bot tokens and incoming webhooks, and an instance originally created to test an integration commonly keeps the same token when it is later used in production, leaving long-lived secrets on a machine that may be less well managed than the systems it connects to.

Recommended hardening

The post closes with practical steps for operators:

• Turn off self-registration unless the instance is deliberately open to a community, and where registration stays on, require verification of an email domain.
• Audit the integrations that are enabled and the tokens behind them, and rotate anything originally created for an evaluation.
• Put the instance behind authentication managed by the organisation, and keep the network path for the API separate from the path to administrative interfaces.
• Where the platform holds operational discussions, fold it into the same security review cycle as the infrastructure those discussions are about.

Why it matters

The measurement puts a number on a structural blind spot. Self-hosted chat servers concentrate precisely the material an intruder wants — credentials, internal system names, incident history — yet, as the dev.to analysis argues, they are often governed like a convenience tool rather than the sensitive data store they effectively are. A six-figure count of reachable instances suggests the pattern is widespread, and the remedy is less about Mattermost itself than about giving self-hosted collaboration platforms the same operational scrutiny as any other service holding secrets.