CVE-2026-110447: Why Disabling the Nextcloud Collabora App Is Not a Fix

Disabling a plugin is the first reflex when a vulnerability is reported in a plugin's code. For CVE-2026-110447 in the Nextcloud Collabora integration, reporting on the exploitation suggests that reflex is insufficient, and the reason is architectural.

The reported facts

CVE-2026-110447 is described as an unauthenticated remote code execution issue in the bundled CODE server component of the Nextcloud Collabora integration, rated 9.2 in the reporting reviewed here. The fix is reported in the Collabora CODE Server build 26.4.303.

The exploitation is described as leading to web shell deployment. That detail matters: a web shell implies the attacker achieved persistent code execution, not just a request-level anomaly.

Why the plugin boundary is the wrong boundary

The Collabora integration is not a simple sidebar widget. It includes a document server that converts and renders office formats, and that server typically runs as a separate service — frequently in its own container or process, sometimes on a different host.

Two consequences follow from that separation.

First, the vulnerable code lives in the document server component. Removing the Nextcloud application from the interface does not necessarily remove or update the document server process, particularly where it was deployed separately, launched from a different image, or referenced by other integrations.

Second, a document server that has been compromised remains reachable if its network path persists. An attacker who established a web shell there does not need the Nextcloud integration to continue using it.

This is why the reporting explicitly notes that disabling the app is not sufficient. The component that must be fixed is the document server build, and the component that must be investigated is whatever the attacker did inside it.

The file-conversion problem

Document conversion services are parsing engines. They accept user-supplied files in office formats, PDF and image containers, and they invoke external tools to render them.

That makes them structurally similar to mail gateways: privileged, internet-reachable in many deployments, and required to process hostile input by design. Any parser in that position carries a continuous vulnerability risk, and a document server is a parser with a network API.

The architectural expectation that a document server sits entirely inside a trusted network is often wrong. It usually needs to be reachable from the Nextcloud instance, and frequently from browsers as well, which places it on a network path reachable by users.

What to do

Update the CODE Server build to 26.4.303 or later. Verify by checking the running service version, not the Nextcloud app store listing.
Locate every instance. A single Nextcloud deployment may reference a document server deployed by a different team. Enumerate them from configuration and from network discovery.
Treat web shell indicators as primary. Web-accessible directories in the document server's filesystem, files with unexpected names containing script content, and processes spawning from those paths are the priority indicators.
Review outbound activity. A document server has narrow outbound requirements. Connections to unlisted destinations are a strong signal.
Preserve before rebuild. Container images are convenient to replace and terrible to reconstruct after the fact.
Check for chained access. A compromised document server may have been used to reach the Nextcloud instance rather than the other way around.

Item six is where investigations often stop early. Direction of trust matters, and the document server may hold credentials or session material that permits reaching back.

The pattern to carry forward

Product integrations that bundle their own network services create shadow infrastructure. The Nextcloud instance has a patch cadence; the document server container may not be in anyone's asset inventory.

That gap is what makes bundled components attractive to attackers. They are part of a product from the customer's perspective and separate software from the operator's.

The fix is procedural: any bundled service that runs as its own process, container or host should enter the asset inventory with its own owner, its own update path and its own detection coverage. Otherwise the vulnerability gets patched in the product nobody deployed and survives in the component nobody tracked.