Papermerge is built around scanned documents, folders, users, groups, and permissions. A public login page is only the first surface. The more useful question is which identities can reach an archive and which API tokens can act on the same documents without a browser session.

Papermerge's documentation describes a multi-user document management system with hierarchical folders, OCR, tags, full-text search, and a REST API. Its team setup guidance says the first account is an administrator who manages users, groups, roles, and permissions. The product also supports user-created API tokens. That combination creates two paths that need a shared authorization model: the web UI and the API.

An exposed deployment may be intentional for a partner or distributed workforce. The review should still identify the tenant boundary, the group membership that grants access to a folder, and the storage location of the original files and OCR text. A disabled user in the UI should not leave an active token that can read the same archive.

What the ZoomEye count measures

On 2026-11-01, a ZoomEye SDK query using title="Papermerge" returned 296 matches at sub_type=all, page 1, and pagesize 1. A companion application-fingerprint query using app="Papermerge" returned 0.

The difference is a measurement limitation and an opportunity. The title may appear on a product-specific login, setup, or information page, while the fingerprint may use a value that was not covered by the exact app query. The count does not prove that 296 systems are vulnerable or that every match is a live Papermerge instance. It is a discovery cue that must be followed by application verification.

Build the review around access paths

Start with the identity source and role mapping. Confirm who can create users and groups, whether an administrator can assign a group across cabinets, and whether a document can be shared with a user who is not a member of its parent folder. Review the token list for every account and revoke credentials that cannot be tied to a current integration.

Check the API prefix, authentication method, and token lifetime. A token is a separate authorization credential even if it was issued from the same user account. Test a token against a document the user cannot view in the UI. Both paths should produce the same denial.

Examine storage and OCR processing. The web application may expose a search result while the underlying file path or OCR text is stored elsewhere. A service that indexes a shared volume can make another tenant's document searchable even when the UI group model is correct.

Operational evidence should include the authenticated principal, the action, the document or folder identifier, and the API-token identity. A title match tells an analyst where to look. The group and token tests determine whether the archive is actually bounded.

References