Kavita is a self-hosted digital library server for books, comics, and reading progress. It can look like a personal media site, but its authentication keys grant access to the user's library account and API. Kavita's documentation describes an Auth Key as a combination of username and password and warns that anyone with the key can act as the user. The key is therefore a user-level credential, not a harmless reader setting.
On 2026-11-04 at 19:38 UTC, a bounded ZoomEye SDK probe used sub_type=all, page 1, and page size one. app="Kavita" returned 0 matches and title="Kavita" returned 11,712. The title result is an inventory lead. It can include a login page, a public library landing page, documentation, or a host that no longer runs the service. It does not prove that an Auth Key is exposed or that a library is publicly readable.
One key inherits the account's library scope
Kavita's user documentation says the Auth Key can be used by third-party clients to act on the user's behalf. OPDS clients, mobile readers, and sync tools may use the key or a URL containing it. The same key can therefore appear in device configuration, backups, support screenshots, or browser history if the OPDS URL is opened directly.
Review which libraries and roles the account can access. Kavita administrators have full server access and can see more than normal users. A key created for a family reading account should not belong to an administrative account. Use separate accounts for administrative console work, ordinary reading, and API or OPDS integrations where the product supports that separation.
The documentation recommends a non-expiring short key for some third-party clients. That convenience increases the importance of handling and revocation. Record the key name, owning account, creation date, intended client, libraries, and any expiration. Do not place the key in a public repository or a URL that is likely to be shared.
Public library versus private account
A Kavita server may intentionally expose a catalog or login page. The review should determine whether unauthenticated users can list libraries, download files, or create accounts. A title match on a public page does not mean the server permits those actions. Test only against an owned instance or with explicit authorization.
If OIDC is enabled, Kavita can use the identity provider for authentication only or delegate user and role management. Group mapping and library access should be tested with a real non-administrator account. A successful OIDC login proves identity, not that the account received the intended libraries.
Review the reverse proxy for URL prefixes, base paths, and support for large downloads. A configuration that rewrites paths can break OPDS or API routes while leaving the main page working. It can also expose internal media paths if another route bypasses the expected access check. Keep the server and its library files under the same documented network boundary.
What to collect from a candidate
For each owned Kavita host, record the base URL, owner, authentication mode, administrator accounts, library roles, OIDC settings, and any public-facing routes. Enumerate Auth Keys by name and owner without displaying the secret. Confirm that a key can be revoked and that the revocation takes effect for the intended client.
Check whether the browser permits linking directly to a URL containing the key. If the product or client requires that flow, document the risk and use a dedicated account with the smallest possible library access. Avoid copying a key-bearing URL into issue trackers or chat logs. A key can survive a password reset if the product does not revoke it automatically, so verify the actual behavior instead of assuming.
A repeatable review
Keep the exact title query, sub_type=all, page and time with the result count. When the host is confirmed, move it into the owned inventory and attach the evidence. A future application query is useful context, but it does not retroactively turn 11,712 title matches into confirmed instances.
The security outcome is a small list of library services with named owners and scoped reading accounts. ZoomEye supplies the external discovery step. Kavita's key model supplies the authorization question: which account does this credential represent, which libraries can it reach, and how quickly can that authority be revoked?