Self-hosted Nextcloud, a Collabora flaw already exploited

A critical flaw in Nextcloud's built-in Collabora opens your server without a password. Check, hunt for the intruder, update it or remove it.

In our article on the cloud, we advised you, at level 3 of sovereignty, to self-host your Nextcloud, while warning you that total control means total responsibility. Here is the flaw that shows it.


What is happening


The CVE-2026-110447 record, published on October 14, describes a command injection in a Nextcloud app, “Collabora Online - Built-in CODE Server”, technical name richdocumentscode. We will call it the built-in Collabora here.

It is the all-in-one option, the one that bundles a Collabora office server straight into Nextcloud so you can edit your documents without installing anything else. Handy. Handy enough to catch the attention of attackers, apparently.

The mechanism fits in two lines. One of the built-in Collabora’s scripts, proxy.php, links Nextcloud to the embedded office server. When that office server is not running, after a reboot, an update or a crash, a well-crafted request to that script makes it run commands. No account, no password, and straight from the internet.

Put simply, anyone who finds your Nextcloud at the wrong moment can run their own commands on it. With the rights of your web server.

CVSS score 9.2 out of 10. Every version of the built-in Collabora before 26.4.303 is affected.

Careful, two numbering schemes cross paths in this radar. The built-in Collabora follows Collabora’s own (26.4 for April 2026). Nextcloud has its own, with maintained versions running from 33 to 35. 26.4.303 is a version of the built-in Collabora, not of Nextcloud.


The record reports in-the-wild exploitation in September and October. In the field, administrators have reported webshells, small PHP files that act as a backdoor, dropped into the built-in Collabora folder. On at least one server, the intruder then went looking for password vaults and crypto wallets.

What we don’t know. The flaw is not listed in the known exploited vulnerabilities catalogue of CISA, the US cybersecurity agency. No vendor, no CERT, the national incident response teams, has published any figures. We are talking about a handful of affected administrators, not a documented mass campaign. Which is only reassuring if you are not one of them.


Are you affected?


Yes, if the built-in Collabora is installed (richdocumentscode in your list of apps). That is the typical setup when you wanted office editing without running a separate server.

No, if your Collabora runs separately, in Docker, as a Linux package or at a hosting provider, and Nextcloud connects to it with the Nextcloud Office app alone (richdocuments). The two apps have near-identical names. Check the one you actually have, not the one you think you have.


The old Nextcloud trap. The fixed version of the built-in Collabora, 26.4.303, only works from Nextcloud 30 onwards. If your Nextcloud runs version 29 or older, the App Store does not even offer it and leaves you on a still vulnerable built-in Collabora (26.4.104).

The “Update” button on the apps page will not get you out of it. You first have to update Nextcloud itself or remove the built-in Collabora, see step 3.

The disabling trap. According to Collabora’s advisory, the vulnerable script is called directly by the web server. Disabled or not, the built-in Collabora stays open to attack, you have to update it or remove it.


What you need to do


The commands below apply to a standard installation, from the Nextcloud folder, as the web server user (often www-data). With Nextcloud AIO, prefix every occ command with sudo docker exec --user www-data nextcloud-aio-nextcloud. The built-in Collabora may live in apps or in custom_apps.


1. Check what you have.

cd /var/www/nextcloud
sudo -u www-data php occ status
sudo -u www-data php occ app:list | grep -i richdoc

The first command gives your Nextcloud version, the second that of the built-in Collabora (richdocumentscode) and of Nextcloud Office (richdocuments). No richdocumentscode, you are not affected.


2. Hunt for the intruder before you touch anything. The fix does not throw out an intruder who is already in. The names observed start with shx or shrf, the list is not complete.

sudo find . -path ./data -prune -o \( -name 'shx*.php' -o -name 'shrf*.php' \) -print
sudo find apps/richdocumentscode custom_apps/richdocumentscode -name '*.php' -printf '%TY-%Tm-%Td %p\n' 2>/dev/null | sort

The sudo keeps you from missing files you are not allowed to read, and the first command skips the data folder, the one holding your files. The second lists the built-in Collabora’s PHP files with their date. An update rewrites those dates, so look above all for a name that stands out or a file newer than your last update of the built-in Collabora.

Then your access logs, at least since September 10.

sudo zgrep -iE 'proxy\.php.*(%2e%2e|\.\./|%24%28|%24\(|\$\(|ifs)' /var/log/nginx/access.log* /var/log/apache2/access.log* /var/log/httpd/access_log* 2>/dev/null

The command leaves out Nextcloud’s normal calls to proxy.php and only keeps the suspicious requests (%2e%2e, $(, ${IFS}, often encoded). No lines is a good sign, not a guarantee, old logs may have been wiped. If you log outbound connections, also look for calls to webhook.site, which the intruder uses to check the installation.

Do this step even if your built-in Collabora is already patched, the intruder may have come in before.


3. Update or remove. It all depends on your Nextcloud version, given by the first command in step 1.

Nextcloud 30 or later. Update the built-in Collabora to 26.4.303 or above. If your apps update themselves (Nextcloud AIO does it every Saturday), it is probably already done, check anyway.

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

On Nextcloud 30 to 32, the built-in Collabora is then patched, but Nextcloud itself no longer gets fixes. Plan to move to Nextcloud 33 or later.

Nextcloud 29 or older. No patched version of the built-in Collabora is offered to you, automatic updates or not. Two options. Update Nextcloud itself, one major version at a time, up to Nextcloud 33 or later, then the built-in Collabora. Or remove the built-in Collabora right away.

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

You lose in-browser document editing, until you install Collabora separately, in Docker for instance. That setup is not affected.


4. If you find something. Stop the suspicious processes started by www-data, delete the extra files, then treat as exposed everything your web server can read. Database password, configured mail accounts, app passwords, and any vault or wallet sitting on the machine. You change everything.

And if you have the slightest doubt about how far the damage goes, reinstalling on a clean machine costs less than looking for a needle in a PHP haystack.


A fix without fanfare


Version 26.4.303 of the built-in Collabora has been out since September 11, a month before the CVE record, without a word about security in its changelog. The same day, Nextcloud posts an “Update now for better security” on Bluesky, pointing to a blog post about Landlock, a new sandbox for Collabora, and nothing else. Also on September 11, a first administrator reported a compromise.

As of October 15, no Nextcloud security advisory, nothing on its Mastodon and Bluesky accounts. Collabora’s, according to the security press, sits on its code repository, where few self-hosters go to read.

A coincidence of dates, nothing more proven. Quietly fixing before announcing is common practice, it gives people time to update. The problem is the message. A faster sandbox does not get anyone rushing to update.


Self-hosting is still the right choice to take back control of your files. But a server of your own also means you do the night watch. Nobody will come knocking to tell you your door is open.


Sources