The number
A ZoomEye query for app="Mattermost" returned 756,074 matching hosts, collected on 2 October 2026 with sub_type=all and a page size of one. The count is the fingerprint match total. It is a large figure for a self-hosted collaboration platform, and the size comes from the same pattern that produces large Jupyter and Nextcloud counts: a container image and a documented deployment path that makes a test instance cheap.
What the surface tells an attacker
The login endpoint identifies the platform and typically the version, and some deployments expose metrics or health endpoints that identify the build more precisely. Mattermost supports self-registration unless it has been disabled, and a login page that offers an account creation link tells an observer that anyone who can reach it can create an account.
An account is the interesting unit here, because the platform is where an organisation discusses its operational state. The conversation history contains incident discussions, credentials shared for convenience, file attachments and the names of internal systems.
What the count does not say
756,074 hosts identify as Mattermost. It does not say how many allow self-registration, how many have an accessible metrics endpoint, or how many are development instances. Those are per-deployment facts, and a scan cannot separate a running evaluation from a production collaboration platform.
Why the exposure matters
Collaboration platforms sit outside the perimeter story in most organisations, because they are treated as a productivity tool rather than an infrastructure service. They are frequently deployed by a team rather than by the platform function, which means they may miss the central review that databases and identity services receive.
The credential risk is real and specific. Integrations use bot tokens, incoming webhooks accept data from external systems, and the first instance built to test an integration usually keeps the token that the production instance later uses.
What to do
Disable self-registration unless the instance is intended to serve an open community, and require email domain control where it is not. Review the enabled integrations and the tokens behind them, and rotate any token that was created during an evaluation.
Keep the instance behind authentication that the organisation manages, and separate the network path for the API from the path for administrative interfaces. Where the platform holds operational conversations, include it in the same review cycle as the systems it discusses, because the content is often the more sensitive asset.
References
- Mattermost documentation. https://docs.mattermost.com/
- ZoomEye. https://www.zoomeye.ai/
Top comments (0)