Matomo Is the Only Self-Hosted System That Must Accept Traffic From Everyone

Every other service in this series has a reason to be reachable from a limited network. An analytics platform is different by design: to record a visit, the tracker endpoint has to answer a request from a browser it has never met, on a page it does not control. That structural exception is why the measurement here converges and why the security question is not whether it is exposed.

The measurement

Queries against the ZoomEye index on 28 October 2026:

• app="Matomo" returns 30,534 matches.
• title="Matomo" returns 34,631. The two methods agree within about thirteen percent, and the fingerprint count is actually the lower of the pair — an inversion of the pattern seen with most self-hosted products, where titles outrun fingerprints by an order of magnitude. When a product carries a proper application signature and the title count is close to it, the numbers can be treated as a usable inventory of reachable installations rather than as an artefact. For contrast, in the same collection: app="Umami" returns 11,584 against title="Umami" 18,133, and title="Plausible" returns 9,483 with a much smaller fingerprinted subset. The analytics category as a whole is in the tens of thousands, which is a scale where individual misconfigurations are individually uninteresting and collectively significant.

The two endpoints that get confused

Matomo, like every analytics platform, has two distinct surfaces and they have opposite exposure requirements.
The tracker surface — matomo.php, piwik.php, or a JavaScript file served to every visitor — must be reachable from the open internet. It is designed to accept unauthenticated POST requests carrying page URLs, referrers, screen sizes, and depending on configuration a visitor identifier. It is a write endpoint for arbitrary input.
The reporting interface — the dashboard where the data is read, segments are built, users are managed and exports are generated — has no reason to be public. It authenticates against a user table with granular permissions, supports API tokens, and usually holds the site's entire history.
The recurring finding is not that one of these is exposed. It is that both answer on the same hostname and the same port, so a rule that permits the tracker permits the console, and the separation that the architecture allows is not applied.

Why an analytics platform is a privacy system first

This is the part that differs from the rest of the exposure series. A Matomo instance is not only an IT asset; it is a record of processing activity under privacy regimes. Its database contains visitor identifiers, IP addresses unless anonymisation is configured, page paths that may encode user identity in query strings, and campaign parameters.
Three configuration decisions determine what that record actually contains, and each is checkable from the interface:
Whether IP anonymisation is enabled, and at what number of bytes. Whether visitor IDs persist across sessions, which determines whether the data is pseudonymised tracking or aggregate counting. And whether the retention policy deletes raw visit data automatically, because an analytics database that grows forever is a liability with a retention clause nobody enforced.
For an organisation that has published a privacy notice describing aggregate statistics, an instance configured for individual tracking is a documentation mismatch before it is a security problem.

The reporting interface is the real risk

An authenticated Matomo session can export the full visit log for every site it tracks, change user permissions, add new users, and configure outbound reporting to arbitrary endpoints. API tokens issued through the interface inherit those rights and are frequently embedded in dashboards, in CI jobs, and in other people's tools.
The practical controls are ordinary and worth stating precisely because they are skipped:
Restrict the reporting interface to the corporate network or an identity-aware proxy, and leave only the tracker paths open. Matomo's own documentation supports this pattern, and it is the single highest-value change available.
Issue API tokens per consumer with the minimum role, and rotate them. A token created for a reporting script two years ago has never been reviewed.
Enforce MFA on accounts with administrative roles. Matomo supports it; installations with a decade of history frequently have it unset.
Confirm the database is not independently reachable on 3306 or 5432. The analytics tier is a common place to find a MySQL instance published for a colleague's convenience.

The honest limits

The 30,534 figure counts index matches, not organisations, and a single hosting provider can present many installations on one network. Some fraction of matches are staging environments, some are behind authentication, and some are already compromised in ways a scan cannot see.
What the measurement does support is a claim about the category: analytics platforms are numerous, they carry more personal data per installation than most of the infrastructure around them, and they are the one service an organisation cannot simply firewall off from the public. Where a control must stay open, the quality of the split between the open path and the privileged path is the whole security posture.

References

• ZoomEye search, queries executed 28 October 2026: app="Matomo" 30,534; title="Matomo" 34,631; app="Umami" 11,584 against title="Umami" 18,133; title="Plausible" 9,483: https://www.zoomeye.org
• Matomo documentation on tracker versus reporting interface separation and configuration options: https://matomo.org/docs