Paperless-ngx is a self-hosted document management system with a web interface, a REST API and workflow automation. A product inventory is the first step toward understanding where document content and permissions may be exposed.
The November 5, 2026 count comparison was more consistent than many self-hosted products. The app query returned 3,962, the exact title returned 3,973 and the body query returned 5,692. All observations used sub_type="all", page 1 and pagesize 1.
The measurements
app="Paperless-ngx": 3,962 at 2026-11-05T17:49:49Z.title="Paperless-ngx": 3,973 at 2026-11-05T17:49:51Z.http.body="Paperless-ngx": 5,692 at 2026-11-05T17:49:52Z.
The near-match between app and title is useful. It suggests that the exact product label is represented in both the scanner's application fingerprint and visible page titles. The difference of 11 may reflect indexing timing, customization or pages that the classifier recognized without a matching title.
The body count is 1,719 higher. That extra set may include documentation, comparison pages or assets whose HTML mentions Paperless without carrying the app fingerprint. It should not be added to the app total without checking overlap.
What the count does not show
Paperless documentation describes token authentication through /api/token/, global permissions and object-level permissions. A token belongs to a user and inherits that user's access. Workflows can assign metadata, tags and permissions as documents move through the processing pipeline.
An external product fingerprint cannot show whether the token belongs to an administrator, whether object permissions are correct or whether a workflow grants too much access. It also cannot show whether the document store is encrypted, backed up or reachable through another path.
The count is a candidate set for ownership and policy review. It is not a count of exposed documents.
A triage path for document systems
Start with assets owned by the organization and confirm the product and version. Check whether the web interface and API are intended to be reachable from the observed network.
Review token creation and ownership. Look for tokens shared across multiple integrations, tokens with administrator roles and tokens that have no recent use. Test a representative integration against allowed and denied objects.
Review workflow permissions next. A rule that assigns document permissions can change access for many records at once. Keep workflow configuration under change control and record the permission effect of each rule.
Finally, inspect document-store and database exposure. A public Paperless interface is only one path to the content. Backups, object stores and shared filesystems can create separate access paths that the product query cannot see.
Reporting the evidence
Report the app and title counts as closely aligned product observations. Report the body count as a broader text-level set. Use the timestamp and query links because the counts can move as pages are indexed.
Avoid saying that 3,962 systems are vulnerable or that 5,692 documents are exposed. The correct statement is that these indexed assets matched a product query at a specific time. The next sentence should describe what validation was performed.
A useful ZoomEye view
ZoomEye helps an organization find self-hosted document systems outside the CMDB. The app fingerprint gives a clear starting population and the title query provides a corroborating view. The body query can reveal naming coverage that the exact fields miss.
Paperless-ngx is a good example of why the inventory should lead to a permission review. The product is designed to hold sensitive documents. A stable external fingerprint is useful, but the operational question is who can read each object and which workflow decides that access.