Mapping Internet-Facing Nextcloud and Built-in CODE Exposure
CVE-2026-110447 gives exposure analysts a concrete string to search and a strict limit on what the result can mean. The affected app is richdocumentscode, the built-in CODE server for Nextcloud. A public query can find pages that mention the application. It cannot determine the installed version, confirm that proxy.php is reachable in the vulnerable state, or identify a compromised host.
The distinction is visible in the query results. On November 5, 2026, ZoomEye returned 122,126 all-asset matches for http.body="richdocumentscode". A combined query for title="Nextcloud" && http.body="richdocumentscode" returned 109,876. A narrower query for http.body="richdocumentscode/proxy.php" returned 20.
The three results are not competing estimates of the same population. They measure different text patterns in indexed web responses. Each can be useful. None should be relabeled as an affected server count.
Separate discovery from validation
The broad product-string query is a discovery layer. It finds public web content containing a distinctive application name. Analysts can use those results to identify organizations, domains, and application owners for follow-up. The combined title and body query narrows the context to pages with a Nextcloud title. The endpoint query is the most specific page-level signal, but its smaller result set shows why a single query is not a complete inventory.
Validation happens elsewhere. The owner confirms that the host runs Nextcloud, that richdocumentscode is installed, and that its version is below 26.4.303. The owner also checks whether the application is internet-facing and whether the local CODE server can enter the stopped state that enables exploitation.
An asset record should carry source and confidence. A public page match is an external observation with an owner to confirm. An authenticated package inventory is host evidence. A log match is request evidence. A file hash is filesystem evidence. Mixing those records without labels makes the report sound more certain than the investigation.
Enrich the external result
Begin with the domain and certificate context returned by the search. Use organizational records to decide who should receive the validation request. Do not assume that a page on a shared hosting domain belongs to the hosting provider's own Nextcloud environment. Do not assume that a third-party documentation page is an affected customer.
Check whether the page is current. A search result can remain indexed after the application is removed or the site changes. Record the query time and the evidence available at that moment. A later recheck can show a change, but a difference does not explain the cause by itself.
Classify the visible surface. A public login page, an application path, a documentation page, and a cached response have different value. The analyst should avoid publishing host-level details that are not necessary for the response. The goal is to route validation to the owner, not to expose a target list.
Prioritize the internal review
The highest-priority host is an internet-facing Nextcloud instance with an affected richdocumentscode version. The next check is whether the built-in CODE server stopped during the reported exploitation period. Restart, crash, upgrade, and deployment records answer that question. Access logs for the proxy path provide request evidence. Filesystem checks for unexpected PHP files provide persistence evidence.
The advisory says standalone Collabora Online servers are not affected. It also says disabling the app is not sufficient and that the app must be upgraded to at least 26.4.303 or removed. These facts should be part of the routing decision, so a team does not send every document-server owner the same remediation request.
When the app is upgraded, verify the version on the host. When it is removed, verify that the application directory and endpoint are no longer present. When a host was exposed before the fix, preserve the evidence and investigate for compromise before considering the asset closed.
Monitor without inflating the count
Recurring monitoring should reproduce the exact query and scope, record the timestamp, and compare results only with the same query. A product-body count should not be compared with an endpoint-body count as if a rise or fall represented patching progress. Keep the three series separate.
Use a review threshold that is appropriate for the organization. A new public page that matches a Nextcloud title and the application string may warrant an ownership check. A large change in a broad body count may reflect indexing. A stable count does not prove that every host is patched. Operational asset data remains the source of truth for remediation.
The ZoomEye link should preserve the exact normalized dork and asset scope. For the selected product-string query, the canonical link is included below. The same discipline applies to any additional query used in an investigation.
A defensible measurement statement
A precise statement is: "ZoomEye indexed 122,126 all-asset responses containing the richdocumentscode string on November 5, 2026. The combined Nextcloud-title query returned 109,876 and the exact endpoint-string query returned 20. These are page-string observations, not confirmed vulnerable installations."
That statement gives readers enough information to understand both the evidence and its boundary. It supports a practical next step: assign public matches to owners, validate versions and deployment type, inspect the vulnerable restart window, and check for web-shell persistence. The incident response decision comes from those checks.
