DEV Community

facilishz
facilishz

Posted on

1.77 million Nextcloud fingerprints and 1.73 million titles: the 44,000-host gap is where the affected office app lives

#zoomeye #exposure #nextcloud #collabora

1.77 million Nextcloud fingerprints and 1.73 million titles: the 44,000-host gap is where the affected office app lives

CVE-2026-110447 is an OS command injection in proxy.php, part of the optional richdocumentscode application that bundles a Collabora Online document server inside Nextcloud. NVD rates it 9.2 under CVSS 4.0 and records exploitation in September and October 2026. The vulnerability is not in Nextcloud itself, and that distinction is the entire remediation problem: finding Nextcloud installations is easy, and finding the ones with the affected application is not visible from outside at all.

The measurement

Two ZoomEye queries on 27 October 2026, sub_type=all, pagesize=1:
| Query | Role | Matched total |
| --- | --- | ---: |
| app="Nextcloud" | application fingerprint | 1,777,153 |
| title="Nextcloud" | page-title text match | 1,732,581 |
No CVE filter was applied. Neither number describes a host running a vulnerable richdocumentscode build.

A small gap on an enormous base

The two counts differ by roughly 44,600 hosts, which is under three percent of the population. That near-match is informative in a way the Atlassian and Zammad gaps were not.
Nextcloud deployments are frequently personal or small-team instances where the default branding is kept. The product name appears in the page title because nobody changed it, and the application fingerprint agrees because the default theme and paths are intact. The absence of a branding project is what makes the two detection methods converge.
The 44,000-host difference then describes the subset that customised the title, moved behind a proxy that rewrites the landing page, or serves a login flow from an identity provider. Those are the enterprise deployments. The proportion is small only because the base is dominated by unmodified instances, not because customisation is rare in the enterprise segment.
For the CVE, though, both numbers are the wrong denominator. The affected component is an application installed inside Nextcloud, and its presence does not change the Nextcloud fingerprint or the Nextcloud title. A host counted once in either query may or may not have the application installed, may have it installed and disabled, or may have it installed and upgraded to a fixed build.

Why the disabling trap matters here

Coverage of this disclosure repeats one operational detail that deserves emphasis because it inverts a common habit. Disabling the application in the Nextcloud administrative interface does not remove the vulnerability. proxy.php is executed by the web server directly, does not load the Nextcloud application bootstrap, and therefore behaves the same whether the app is marked enabled or disabled. The file remains in the application directory and remains reachable.
That detail is why a population figure for Nextcloud cannot be paired with a statement about remediation progress. Counts after the disclosure will not move, because the vulnerable component stays on disk. A team that expects an external exposure metric to decline as they respond will see it flat and may conclude the response is not working.
The two remedies named in reporting are upgrading richdocumentscode to 26.4.303 or later, or removing the application entirely. Both are internal actions. Neither changes what a remote scan observes.

Where the exposure actually is

The scoping statement in the advisory is unusually clean and worth reproducing precisely because it narrows the work. Standalone Collabora Online servers, Docker and RPM/DEB installations, and Nextcloud All-in-One deployments are not affected. The vulnerable code is in the bundled variant that Nextcloud installs as an app so that an instance can edit documents without a separate document server.
That means the useful inventory query is about the application, and it lives in the Nextcloud app directory of every instance you own, which requires internal access. The external measurement helps in one specific way: the Nextcloud fingerprint population is a reasonable upper bound on the number of places to check, and at 1.77 million it explains why automated internal discovery beats asking administrators.
A workable automated check, if your estate uses configuration management, is to enumerate instances, read the application directory listing, and record whether richdocumentscode is present and at which version. Then check whether the document server process is running, because the exploitation precondition is that it is stopped. Instances that have never installed the app drop out. Instances that installed it and removed it drop out. What remains is a short list.

The verification step people skip

The public reporting describes PHP files with names beginning shx or shrf written into the application directory, and search activity targeting password databases, password manager files and wallet files. Those artefacts persist after the upgrade.
So the post-patch check for each instance that was exposed is three questions. Are there unexpected PHP files in the application directory, compared against a clean build of the same version. Do the web access logs from 10 September onward contain requests to proxy.php with encoded traversal, command substitution sequences, or base64 decode pipelines. And has everything the web server user can read been rotated, which for Nextcloud includes database credentials, application secrets, and any storage keys in configuration.
The last question is the one that gets deferred. A web server account on a Nextcloud host can typically read the configuration file that holds the database password and the secret used to sign sessions. Rotating those is disruptive, and the temptation is to treat the patch as sufficient. The patch closes the command injection; it does not unread the configuration file.

What the numbers support

One defensible claim: Nextcloud is deployed at a scale where internal automation is the only viable inventory method, and title-based external detection is nearly as complete as fingerprinting because the product is usually left unbranded. One claim the numbers do not support: that the population is vulnerable. The vulnerability is one removed application step away from anything either query measures.

Limitations

Counts come from a single session on 27 October 2026 with combined IPv4, IPv6, and domain scope. Collection coverage changes over time and the totals are not reproducible. No matched records were sampled to validate the fingerprint. Nothing here establishes whether any matched host has the affected application installed, at which version, or whether its bundled document server is running.

References

Top comments (0)