Wizarr manages invitations for Plex, Jellyfin, Emby, and other media servers. An invitation link is meant to be shared, but it can also create a user, attach permissions, and guide the recipient through steps that expose server details. The exposed object is an onboarding workflow with authority to change a media server's user list.
The project's documentation describes multi-tiered invitations and pre- and post-invite steps. It also documents an SSO mode where built-in authentication can be disabled. In that mode, the documentation warns that /login signs every visitor in as an administrator unless the deployment is correctly protected. This is a clear example of why an application-level feature flag must match the network and proxy policy.
Measure the visible surface
The count-only probes on 2026-11-08 used sub_type=all, page 1, and page size 1. app="Wizarr" returned 0, title="Wizarr" returned 38, and http.body="Wizarr" returned 177.
The application fingerprint query found nothing, while a small title count and a larger body count did. That does not mean the 177 body matches are Wizarr servers. The word can appear in documentation, mirrors, issue pages, and unrelated applications. It does mean that title-only inventory would miss deployments whose page title changes or is localized.
For an owner, the useful comparison is between the public title, the body text, the login and invitation routes, and the organization's own DNS inventory. A count is a lead. It is not proof that an invitation is active, that a library is exposed, or that a default administrator setting is enabled.
Where the authority sits
An invitation can grant library access to a media server account. It can also reveal server names, available libraries, quality options, and the request workflow. If the Wizarr administrator account is reachable, the attacker may be able to create invitations, change their scope, or connect additional media services.
The built-in authentication configuration is therefore part of the external boundary. If SSO is enabled, the proxy must authenticate the user before forwarding the request and must not allow direct access to the backend. The DISABLE_BUILTIN_AUTH setting is safe only when a trusted access layer enforces the intended identity and the application is not reachable around it.
Review checklist
List the external invitation routes separately from administrative routes. Confirm that public invitation pages expose only the information required to accept that invitation and cannot enumerate other invitations or users. Review invite expiration, one-time use, library scope, and whether a recipient can select a server outside the intended tier.
Check the trust boundary for forwarded identity headers. If the application uses an identity proxy, remove client-supplied versions of those headers at the edge and restrict the backend listener to the proxy network. Test /login and /api/docs/ with and without the proxy. The API documentation is not necessary for every public invitation flow.
Defensive baseline
Treat Wizarr as an administrative control plane for media users. Protect the admin path with strong authentication, make invitation links short-lived and narrowly scoped, keep the backend off the public network, and verify SSO mode after every upgrade. Use ZoomEye counts to start an ownership review, then validate the actual routes and invitation settings on systems the organization controls.