Docspell discovery starts with the account and share boundary
An internet-facing document organizer is usually more valuable for the records it can retrieve than for the page it displays. Docspell stores documents in a collective, lets accounts share access to items, and separates protected API routes from share routes. Those relationships are the useful starting point for an exposure review.
Docspell's API documentation describes authenticated /sec/* routes and /share/* routes that use a share identifier and possibly a password. Its authentication configuration supports local accounts or an OpenID Connect provider. A single login page therefore says little about which documents are reachable. The review needs to establish the account source, the collective membership, and whether a share is still valid.
The product also has an administrator-controlled upload integration endpoint. According to the documentation, the endpoint is disabled by default and must be enabled in configuration. If an organization turned it on for inbound scanning or a partner workflow, that URL belongs in the inventory even when the main login is restricted.
A measured title signal
A ZoomEye SDK query for title="Docspell" on 2026-11-01 returned 40 matching assets. The companion app="Docspell" query returned 0. This is a title-only observation, not evidence that all 40 instances are vulnerable or that the title is always the login page. The value of the count is that it provides a bounded discovery cue for a product that may not have a stable ZoomEye application fingerprint.
The exact scope was sub_type=all, page 1, and pagesize 1. ZoomEye returns a total match count even when the response contains one record. That count describes matching internet assets in the selected scope; it does not measure document sensitivity, authentication strength, or exploitation.
Checks that produce a decision
Inventory every DNS name and reverse proxy that presents the Docspell UI. Map it to a collective, identity provider, and document-processing connector. Verify that local accounts are intentional if OIDC is primary, and that an account name cannot cross collective boundaries. Review active share identifiers, their password requirement, and their expiry or deletion process.
Inspect the upload integration setting and the REST server's external URL. A public upload endpoint may be narrow by design, but it still belongs to the attack surface. Confirm that the endpoint cannot select another collective by changing an identifier. Test with a disposable account and a non-sensitive test document.
Logging should connect an authenticated account to the share or document action that followed. A reverse-proxy access log with only a path is weak evidence when a share URL is opaque. Keep the server secret, identity-provider configuration, and storage credentials out of the public management path.
The title count gives the reviewer a place to start. The authorization model gives the reviewer a reason to stop or continue.