ONLYOFFICE: 86,750 fingerprints beside 86,744 titles, a near-exact match

A difference of six between two counts in the tens of thousands is small enough to treat as agreement, and it is the cleanest example of field consistency in this series. It is also a useful case for explaining what agreement does not prove.

Context and method

Queries ran through the ZoomEye SDK on 2026-10-05 with sub_type=all, page=1 and pagesize=1. Page size limits returned records, not matched totals.

• Search: app="ONLYOFFICE" returned 86,750.
• Comparison: title="ONLYOFFICE" returned 86,744.
• Comparison: product="ONLYOFFICE" returned 3. The two large figures differ by six, or roughly 0.007 percent. The product field returned three, which follows the coverage limitation described for other products in this series.

What a near-exact match indicates

Both fields are seeing the same population, which suggests that the default title is commonly retained and that the application's recognisable behaviour is stable across deployments. When a fingerprint and a title agree at this scale, the pair functions as a consistency check on the measurement method rather than as two independent estimates.
It does not follow that the number is a precise count of installations. Both fields can match assets that are not serving an active instance, and both depend on the same underlying index. Agreement between two fields that share a collection method reduces the chance of a field-specific artefact; it does not eliminate index-level ones.

Community and enterprise editions

The distinction that matters for risk assessment is not visible from outside. A deployment may run a community edition or an enterprise edition with different integration surfaces, and it may be embedded inside another application. Document servers are frequently deployed as a component behind a collaboration platform, which means the externally visible endpoint may be an integration rather than a standalone service.
The consequence for interpretation is that a count of document-server assets is a count of endpoints, not of organisations. A single large deployment can account for many matched assets across its document conversion services, and a single organisation may operate several such deployments.

The data underneath

A document server processes user-supplied files, converts formats and stores the results, and frequently holds the connection details for the storage layer it reads from. Document parsing code has a long history of memory-safety and resource-exhaustion problems across every platform that implements it, which places the format-conversion path among the more consistently attacked components in any stack.
The defensible operational questions are whether the document server is reachable from untrusted networks, whether it is integrated with a storage backend using a broadly privileged account, and whether the conversion service runs with the privileges it needs rather than with more.

Reporting agreement honestly

Where two fields agree, report both and state that they are consistent, then state the shared limitation. Presenting a match as confirmation that the number is exact would overstate what a single collection can support, and presenting the small discrepancy as a meaningful finding would overstate the significance of six records.

Limitations

The counts were collected once and no change over time is claimed. The comparison fields share a collection method and an index, so agreement does not provide independent corroboration. Nothing in these figures establishes that any endpoint is misconfigured or vulnerable.

References

• ZoomEye, app="ONLYOFFICE" (86,750), title="ONLYOFFICE" (86,744) and product="ONLYOFFICE" (3), sub_type=all, collected 2026-10-05.
• ONLYOFFICE documentation, document server and integration configuration.