Blog · 2026-10-26 · Gardience Engineering

Collabora in Nextcloud (CVE-2026-110447): find and fix it

The exploited Collabora built-in CODE server bug lives in a Nextcloud app, not an OS package, so package-based CVE scanners say you are safe. How we found every copy in our lab, checked for planted files, and updated it, with the commands.

CISA added CVE-2026-110447 to its Known Exploited Vulnerabilities list on October 23, which means attackers are already using it. It is a command injection bug, rated 9.8 out of 10, in the Collabora Online built-in CODE server, the Nextcloud app that lets people edit Office documents without running a separate Collabora server. Reports say attackers have been dropping web shells through it and then hunting for passwords and crypto wallets.

So we did what we always do: we looked it up in our own CVE scanner. It said none of our machines were exposed.

That answer was wrong, and it is wrong in every package-based scanner, not just ours. Here is why, and what we did instead.

What is affected

The advisory is GHSA-f97p-r72q-64h2.

Why our scanner said we were safe

Gardience's CVE lookup for CVE-2026-110447: 0 exposed machines

Gardience checks every machine against each vendor's own security data: Debian, Ubuntu, Red Hat, and Microsoft. Those lists cover packages the operating system installed. A Nextcloud app is not one of those. Nextcloud downloads it from its own app store into its own folder, and no distribution's security tracker knows it is there.

So the honest answer from a package scanner is "none of your packages are affected," which is true and useless. That is the same blind spot we wrote about for Node.js on Windows: if something did not come from the OS package manager, an OS CVE check cannot see it.

You have to ask the servers directly.

The lab test

Our test lab has eight Linux machines. Two of them run Nextcloud on Debian 13:

To test the "were we already hit?" step without running a real exploit, we put a harmless stand-in file, cache-helper.php, inside the vulnerable app's folder on linux-web-01. It contains only a comment. It stands in for the kind of file an attacker would leave behind.

Everything below ran as one command at a time on all eight Linux machines from Gardience's Run a command runbook. The same commands work over SSH on a single server.

1. Find every copy and its version

find /var/www /srv /opt -path "*/apps/richdocumentscode*/appinfo/info.xml" \
  -exec grep -H "<version>" {} + 2>/dev/null | grep . || echo "no Collabora built-in CODE server here"

If your Nextcloud lives somewhere else, add that folder to the list.

The find command on 8 machines: linux-web-01 on 26.4.302, linux-sts-3007 on 26.4.502, the rest have none

Six machines had no Nextcloud. linux-sts-3007 was on 26.4.502. linux-web-01 was on 26.4.302: vulnerable. That took a few seconds, for eight machines or eight hundred.

2. Look for planted files before you update

This is the step people skip, and the order matters. Nextcloud can compare an app's files with the signed list the developer published:

cd /var/www/nextcloud
sudo -u www-data php occ integrity:check-app richdocumentscode      # or richdocumentscode_arm64

occ integrity:check-app finds EXTRA_FILE cache-helper.php on linux-web-01

It found our stand-in right away: EXTRA_FILE: cache-helper.php, a file the real app does not have.

Two things we learned here:

find /var/www/nextcloud -path /var/www/nextcloud/data -prune -o -name "*.php" -mtime -60 -print | head -50
grep -h "richdocumentscode.*proxy.php" /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null | tail -50

If you find something you did not put there, treat the server as compromised: take it off the network, change every password and key that was on it, and rebuild it rather than cleaning it.

3. Update

cd /var/www/nextcloud
sudo -u www-data php occ app:update richdocumentscode      # or richdocumentscode_arm64

app:update on all 8: linux-web-01 updated to 26.4.502, linux-sts-3007 already up to date

linux-web-01 went to 26.4.502. linux-sts-3007 said it was already up to date, and the other six had nothing to do.

If you cannot update today, turn the app off until you can:

sudo -u www-data php occ app:disable richdocumentscode

Document editing stops working while it is off. That is a fair trade for a bug that is being exploited.

4. Prove it

Run the same find again:

The find command after the update: both Nextcloud servers on 26.4.502

Both Nextcloud servers report 26.4.502. Every run above, with who ran it and each machine's output, is in Gardience's audit log, which is the record you want when someone asks "did we patch that?"

What we are taking away from this

Our CVE scanner did its job and still gave us the wrong answer for this bug. The fix is not a better scanner. It is knowing what each check can see:

Where the software came fromDoes an OS package CVE check see it?How to check
The OS package manager (apt, dnf, Windows Update)YesYour CVE scanner
An app's own store (Nextcloud apps, WordPress plugins)NoAsk the app: occ app:list, wp plugin list
ContainersNoScan the image, rebuild on a fixed base
Installed by hand (Node.js on Windows, compiled PHP)NoLook for the file and its version

For the second, third, and fourth rows, the answer is the same: ask every server directly, at once, and keep the record.

Questions

Which version fixes CVE-2026-110447?

Collabora Online built-in CODE server 26.4.303 and later. The current release is 26.4.502.

Is standalone Collabora Online affected?

No. Only the built-in CODE server app that runs inside Nextcloud (richdocumentscode and richdocumentscode_arm64).

Why does my vulnerability scanner say I am not exposed?

Most server CVE scanners compare OS packages with the vendor's security data. The built-in CODE server is a Nextcloud app, not an OS package, so those scanners do not see it. Check the app version in Nextcloud or with the find command above.

Does updating remove a web shell?

Only one inside the app's own folder, because the update replaces that folder. An attacker can put files anywhere the web server can write. Check before you update, and rebuild the server if you find anything.

Try Gardience on your own machines

One supported console for Windows and Linux on open-source Salt: patching, a scored STIG/CIS-aligned baseline, drift repair, event-driven automation, two-person approval and a tamper-evident audit log. Flat yearly pricing, not per node.

Free 90-day trial (25 nodes)See it work Compare

Salt is a trademark of its owner, Ansible is a trademark of Red Hat, Inc., and other names are trademarks of their owners. Gardience is independent and not affiliated with any of them.