Jackett's indexer console carries API keys as well as query results
Jackett translates search requests from media applications into tracker-specific HTTP queries. Its dashboard exposes indexer configuration and an API key used by Sonarr, Radarr, and other clients. That makes a publicly reachable Jackett instance more than a search endpoint. It is a credential-bearing integration point between a home network, third-party services, and the applications that consume its results.
The project's README describes the API key at the dashboard and documents Torznab requests such as apikey=YOUR_API_KEY&t=search&q=ubuntu. The key is intended for authorized clients. A dashboard that is reachable without an administrator login, or a backend path that bypasses a reverse proxy, can expose the same key and the configured tracker credentials.
What the counts show
The 2026-11-08 count-only probe used sub_type=all, page 1, and page size 1. app="Jackett" returned 0, title="Jackett" returned 2,621, and port="9117" && title="Jackett" returned 0. The title signal is much larger than the application and default-port signals.
That pattern is useful but limited. A title can appear on a login page, a reverse-proxy error page, or a documentation mirror. A zero on port 9117 does not prove there are no Jackett services, because operators routinely change the port or place the service behind a different hostname. The query result is a candidate inventory, not a vulnerability population.
Review the integration boundary
Inventory every Jackett listener and every downstream app that uses its API key. Confirm that the dashboard requires authentication and that the reverse proxy does not pass an unauthenticated path to /UI/Dashboard or the API. Keep the listener on a management network or a loopback interface when remote clients connect through a proxy.
Rotate the Jackett API key after any suspected exposure. Update every configured client at the same time so a stale key does not remain in logs or backup configuration. Review the indexer definitions for embedded usernames, passwords, cookies, and tracker API keys. A compromised Jackett instance can reveal credentials that are independent of the Jackett API key.
Check TLS verification when Jackett calls Brave, FlareSolverr, or tracker services. An integration that disables certificate checks can turn a proxy or DNS problem into credential exposure. Record the destination, timeout, and redirect policy for outbound requests.
Defensive baseline
Put Jackett behind an authenticated proxy, remove direct access to its port, rotate its API key on exposure, and inventory every client that consumes the key. Treat indexer configuration as secret material. Use the ZoomEye title count as a prompt to check owned hosts and certificates, then confirm the real integration path rather than inferring it from a fingerprint.
Top comments (0)