Manticore Search is a search database with SQL and HTTP interfaces. Recent versions include built-in authentication and authorization for SQL over the MySQL protocol, HTTP/HTTPS endpoints, and replication-related operations. The control only helps when the deployment actually enables it and when every exposed endpoint uses it.
ZoomEye returned eight matches for title="Manticore Search" on 2026-11-10 at 00:52 UTC. app="Manticore Search" returned zero, http.body="Manticore Search" returned 81, port="9312" returned 9, and port="9308" returned 3. These are small observations, which makes manual validation practical. They do not establish that the hosts are Manticore, that authentication is disabled, or that the services are reachable beyond the observed banner.
View the title measurement in ZoomEye. The query used page 1, page size 1, and sub_type=all.
HTTP is an application API
The Manticore manual says HTTP and HTTPS listeners can serve API and HTTP protocols. When authentication and authorization are enabled, clients must use Basic authentication or a bearer token. The /sql, /cli, and /cli_json endpoints can run SQL queries, which means a reachable endpoint may expose both search and operational statements, subject to the configured user and grants.
That is a different risk from a search page. A public API may be intended for a front-end search application. If the same listener accepts an administrative token or a broad user, a missing network boundary becomes a database access problem. Review which endpoint is public, which user the frontend uses, and which grants the search service needs.
The manual states that authentication data is stored in auth.json under the data directory. Protect that file as a credential store. Do not include it in backups that are broadly readable, debug bundles, or support uploads. Rotate credentials after a suspected disclosure and review the authentication log for successful and failed attempts.
A small count still needs framing
The title count of eight and the port counts of nine and three are not a global population estimate. A server may not return a title that contains the product name, may use TLS or a non-default port, or may sit behind a proxy. The body count is broader and may include documentation. These numbers are best used to define a validation sample and a query baseline.
Record the query, time, sub_type=all, page, and page size for every observation. If a later scan uses a different port or token, compare only compatible scopes. Do not add title, body, and port counts to claim a larger product population.
Review sequence
Start with the deployment configuration. Confirm whether authentication and authorization are enabled, which users exist, and whether the search service uses a dedicated account. Inspect the listener addresses and restrict HTTP interfaces to the networks that need them. A localhost listener is not public simply because the process contains a web API.
Test Basic authentication and bearer tokens separately. Test a query endpoint with a narrow user and a statement that should require a broader grant. Verify that the denial happens at the server, not only in the client. Check the bootstrap path for the first administrator and remove any temporary setup token after initialization.
Review replication and internal transport separately. The manual describes internal transport authentication as a distinct log category. The backend service should not share credentials with public search clients. Protect replication ports and test what happens when the credential is missing or wrong.
What to conclude
The evidence supports a narrow statement: a few internet-records match the product title or its documented ports under the tested query. It does not support a claim that those hosts are unauthenticated or vulnerable. The useful action is to validate the candidates and compare them with deployments where Manticore listens on an exposed interface.
The security goal is explicit. If the API is public, the user, grant, and endpoint should be intentional. If it is internal, the network and authentication should both reflect that. The storage of authentication data should be protected, and the first administrator should not remain a bootstrap secret after setup.
References
Measurement metadata: 2026-11-10 00:52 UTC, sub_type=all, page 1, pagesize 1; title 8, app 0, body 81, port 9312 nine, port 9308 three.